1、為什麼要構建微服務
所有架構方案的提出都是根據應用場景進行優化的，想一下5年前，當時springmvc大行其道，使用ssm 構建應用基本上是當時開發界的標準。當時的資料量還沒有進行服務拆分，所有服務構建在乙個單體應 用中，所有服務間呼叫是通過http請求實現的。
但是這種方式構建的應用有幾個最主要的缺點：
1、當請求量和併發量上來後，服務擴充套件比較困難，單體應用可以實現集群化提供服務，但需要配置前 端**伺服器，如果併發量降下來後又要**服務資源修改配置
2、所有服務共用乙個後端資料庫資源，這樣資料庫就成為了效能瓶頸
3、單體應用一旦掛掉，整個服務將不能提**用，比如乙個服務中提供了下單、瀏覽、註冊服務，如 果所有介面構建在乙個服務中，那麼當出現問題時所有功能都不可用。
以上只是列舉了幾個單體應用可能遇見的問題，微服務提出就可以解決以上出現的問題，將大的服務拆 分成多個小應用提供服務，每個服務單獨使用各自的資料庫資源，這樣就實現了「不把雞蛋放在乙個籃 子裡」，當某個服務宕機後，最多那個服務不可用，其他資源還可繼續使用。
2、微服務的優勢與劣勢
微服務拆分最大程度上解耦了應用，但是也一樣帶來了服務的複雜度，比如要查詢使用者的訂單資訊，在 早期的架構方案中，這兩個資料是儲存在一起的，通過乙個表關聯查詢出資料；但是在微服務下這樣就 實現不了了，因為這兩個資料是儲存在不同位置，如果要查詢這兩個資料，需要到兩個服務中分別取出 來然後再組裝起來返回給客戶。
微服務優點：
1、服務解耦：不同的服務拆分成不同的應用對外提供服務
2、方便擴充套件：如果某個應用併發量很大，對單個應用進行擴容，當請求量將下來後再**資源
3、資料解耦：將不同的應用資料儲存在不同的資料庫中，這樣就實現了資料的水平拆分 微服務的缺點：
1、增加了服務的複雜性，原來乙個請求就能獲取到的資料，微服務化後可能需要多次請求才能獲取到 結果
2、維護成本增加了，不同的應用需要不同的人員進行維護
3、架構複雜，增加了問題排查和定位的難度
3、docker容器化實現動態伸縮
如果只是對服務進行拆分，並沒有體現出微服務的優勢，對於動態擴容和伸縮還是需要人員來參與，所 以雲平台在構建的時候考慮到了這些，在服務拆分同時，使用的k8s進行服務治理，實現動態擴容和伸 縮，同時使用elk進行日誌收集和分析，這種架構基本實現了我們的業務需求：
1、服務和資料拆分，不同服務的資料儲存在不同的資料庫，對資料庫進行水平擴充套件
2、日誌統一收集處理，排查和定位問題方便
3、使用k8s進行服務編排和治理，可以實現資源動態伸縮，方便管理
4、雲平台整體架構
雲平台整體使用的springcloud構建微服務，微服務構建使用docker部署在k8s中，對外通過統一的
nginx做請求**，應用服務和資料儲存之間使用redis快取。
雲平台集群擴充套件限制 通過微服務構建易擴充套件雲平台
當前各種雲平台 開放平台滿天飛，大到網際網路巨頭小到垂直行業頭部有野心的企業，都會有搭建雲平台的衝動。技術上也有各種高大上滿天飛的，但是最終落地還是需要結合自身實際情況和業務需求，考慮價效比來執行。往往是從豐滿到骨感，引無數大牛盡折腰。好了，不多說了，找個合適的給大家看看 1 為什麼要構建微服務 所...
微服務之構建服務映象
from gradle 3.5 jre8 copy build libs goods service 0.0 1 snapshot 0.0 1 snapshot jar cmd jar goods service 0.0.1 snapshot.jar 指令碼名為build.sh usr bin en...
微服務 雲計算 微服務和雲計算的狀態
微服務 雲計算 根據o reilly最近對雲計算增長進行的雷達調查 一項更有趣的指標表明，在1,283個響應中，有52 的受訪者表示他們使用微服務概念，工具或方法進行軟體開發。其中，一小部分人 超過28 使用微服務超過三年。這是微服務使用者中的第二大集群。最大的群體 超過55 使用微服務的時間為一到...