一、傳統單體架構的缺陷

傳統的單體應用，將所有功能的表示層、業務邏輯層，資料訪問層，包括靜態資源等等全部糅合在一個工程裡面，編譯，打包，部署在單臺伺服器上上線，比如打成war包放在Tomcat的webapp目錄中部署專案。這樣的專案開發部署適合小型專案，系統功能不復雜，訪問量不大的情況下有絕對的優勢。開發速度快，運維方便。但是當業務越來越複雜，功能越來越多，參與的開發人員越來越多，就暴露出問題了：

• 業務變複雜，程式碼量增大，程式碼可讀性，可維護性，可擴充套件性下降。萬一要新同事接手程式碼，理解起來花很多時間
• 測試難度增大
• 單體應用併發能力有限，訪問量高了使用者體驗差
• 單體應用容錯率低，萬一哪裡出錯，可能導致整個專案就崩了

將單體應用做叢集部署，新增負載均衡伺服器（例如Nginx反向代理轉發請求）可稍微緩解以上3，4條缺點，但是還是不能完美解決問題。

二、何為微服務

微服務架構：就是將原來的單體應用按義務範圍來進行劃分，劃分為多個小model，每個微服務執行在自己的程序中，不相互影響，通過完全自動化部署來獨立部署。並使用輕量級機制通訊，通常是HTTP RESTUFUL API。可對各個微服務進行集中管理。這些小model可以使用不同的程式語言，以及不同的儲存技術。微服務架構是分散式架構。

微服務架構的優點：
- 按業務劃分的微服務單元獨立部署，執行在獨立的程序中，服務與服務之間沒有任何耦合，有很好的擴充套件性和複用性
- 服務與服務之間通常採用HTTP通訊，這種通訊機制與平臺和語言無關(可以使用不同的程式語言和儲存方法)。也可以採用輕量級的訊息匯流排來通訊，如RabbitMQ、Kafaka訊息佇列等等，資料格式一般都採用JSON
- 每個微服務有自己的資料庫，服務之間資料庫是獨立的
- 微服務一般採用自動化部署工具部署。Docker容器技術是微服務最佳部署的容器。
- 服務集中化管理(服務註冊與發現Eureka、Zookeeper、Consul)，監控(服務執行狀況監控Spring-Boot-Admin-Server)
- 微服務架構是分散式架構

微服務架構的缺點：

• 專案構建複雜程度遠高於單體應用
• 分散式系統中難保證資料一致性，一般情況下，少用分散式事物
• 服務部署比單體應用複雜

微服務架構難題及解決辦法：
- 服務之間故障傳播影響：譬如A服務呼叫了B服務，但是B服務因為網路或其他原因遲遲沒有響應，容易引起服務的雪崩效應 — >採用“熔斷機制”，快速報錯
- 分散式事物：事物失敗容易導致資料不一致 — >採用“兩階段提交”

三、SpringCloud簡介

Spring Cloud是最常用的微服務框架，依賴於Spring Boot，有快速開發，持續交付，容易部署等優點。
主要功能元件有：

• 服務的註冊與發現，註冊中心統一管理微服務例項，檢視各個服務的健康狀態
• 服務負載均衡，為了保證服務高可用，要叢集化部署
• 服務容錯–熔斷機制
• 閘道器–路由，過濾，
• 各個服務配置檔案的統一管理
• 服務之間相互呼叫的流程鏈路追蹤
• 實時日誌