什麼是單體架構
一個歸檔包（例如war格式）包含所有功能的應用程序，通常稱爲單體應用，而架構單體應用的方法論，就是單體應用架構
單體架構存在的問題
- 複雜性高：單體應用整個項目包含的模塊非常多，模塊的邊界模糊，依賴關係不明確，代碼質量參差不齊
- 技術債務：隨着時間的推移，需求變更和人員迭代，會逐漸形成應用程序的技術債務，並且越積越多
- 部署頻率低：隨着代碼增多，構建和部署的時間也會增多，每次部署都要重新部署整個項目
- 可靠性差：某個應用有bug，可能會導致整個應用崩潰
- 擴展能力受限：單體應用只能作爲一個整體應用進行擴展，無法根據業務模塊的需要進行伸縮
- 阻礙技術創新：單體應用往往使用的技術平臺或方案解決所有的問題，團隊中的每個成員都必須使用相同的額開發語言和架構
如何解決單體應用架構的問題
微服務架構可以有效解決上面的問題
什麼是微服務架構
微服務架構就是一種將單一應用程序開發爲一組小型服務的方法，每個服務運行在自己的進程中，服務間採用輕量級通信機制（通常用http資源api），這些服務圍繞業務能力構建並且可通過全自動部署機制獨立部署
特性：
- 每個微服務可獨立運行在自己的進程中
- 一系列獨立運行的微服務共同構建起整個系統
- 每個服務爲獨立的業務開發，一個微服務只關注某個特定的功能
- 微服務之間通過一個輕量的通信機制進行通信，例如通過restful api進行調用
- 可以使用不同的語言與數據存儲技術
- 全自動的部署機制
優點
- 易於開發和維護
- 單個微服務啓動較快
- 局部修改容易部署
- 技術棧不受限
- 按需伸縮
挑戰
- 運維要求較高
- 分佈式固有的複雜性：使用微服務構建的分佈式系統，對於一個分佈式狎鷗亭泡麪哥，系統容錯，網絡延遲，分佈式事務等都會帶來巨大的挑戰
- 接口調整成本高：微服務直接使用接口通信，一個接口的修改，可能涉及到所有和這接口有關的都得做修改
- 重複勞動：很多服務可能都使用到了相同的功能，而這個功能並沒有達到分解爲一個微服務的程度，這個時候，可能各個服務都會開發這一個功能（可以使用共享庫來解決這個問題，比如將重複的功能封裝成公共組件，但是注意多語言環境可能行不通）