1 單體應用架構圖舉例：
2、微服務架構圖舉例：
微服務，服務調用基本組件：
服務描述，註冊中心，服務框架，服務追蹤，服務治理
3 、 單體應用與微服務架構優缺點
單體應用有如下優點：
- 爲人所熟知：現有的大部分工具、應用服務器、框架和腳本都是這種應用程序；
- IDE友好：像 NetBeans、Eclipse、IntelliJ 這些開發環境都是針對開發、部署、調試這樣的單個應用而設計的；
- 便於共享：單個歸檔文件包含所有功能，便於在團隊之間以及不同的部署階段之間共享；
- 容易部署：只需將單個歸檔文件複製到單個目錄下。
- 方便調試，代碼都在一起；
- 沒有分佈式開銷，所有服務都在本地容器內；
- 中小型項目可以快速迭代，不需要太多資源。
單體應用的一些不足：
- 不夠靈活：對應用程序做任何細微的修改都需要將整個應用程序重新構建、重新部署。開發人員需要等到整個應用程序部署完成後才能看到變化。如果多個開發人員共同開發一個應用程序，那麼還要等待其他開發人員完成了各自的開發。這降低了團隊的靈活性和功能交付頻率；
- 妨礙持續交付：單體應用可能會比較大，構建和部署時間也相應地比較長，不利於頻繁部署，阻礙持續交付。在移動應用開發中，這個問題會顯得尤爲嚴重；
- 受技術棧限制：對於這類應用，技術是在開發之前經過慎重評估後選定的，每個團隊成員都必須使用相同的開發語言、持久化存儲及消息系統，而且要使用類似的工具，無法根據具體的場景做出其它選擇；
- 技術債務：“不壞不修（Not broken，don’t fix）”，這在軟件開發中非常常見，單體應用尤其如此。系統設計或寫好的代碼難以修改，因爲應用程序的其它部分可能會以意料之外的方式使用它。隨着時間推移、人員更迭，這必然會增加應用程序的技術債務。
- 代碼維護難：代碼功能耦合高，新人不知道何從下手，維護比較困難；
- 開發效率低：所有的開發在一個項目改代碼，遞交代碼相互等待，代碼衝突不斷；
微服務具有如下優點：
- 單獨部署，獨立開發，易於開發、擴展、理解和維護；
- 比單體應用啓動快；
- 複雜性低，局部修改很容易部署，有利於持續集成和持續交付；
- 故障隔離，一個服務出現問題不會影響整個應用；
- 不會受限於任何技術棧。
- 微服務只是業務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。
- 易於和第三方應用系統集成。
微服務具有如下缺點：
- 需要分佈式事務的支持；
- 效率相對低，團隊依賴強，一個服務的版本延遲會拖慢整個應用的開發週期
- 開發難度大；垮服務的調用通常是不同的機器，甚至是不同的機房，開發人員需要處理超時、網絡異常等問題
- 分佈式系統比單體應用架構複雜，隨着服務數量增加，管理複雜性增加，極大地增加運維工作量；
- 故障診斷比較難，不容易定位錯誤節點；
4、單體應用和微服務各適用的業務場景
單體應用適合場景：
- 業務場景簡單
- 創業團隊，項目初期等場景，需要快速開發迭代
微服務適合場景：
- 業務場景複雜，核心業務可以獨立
- 業務量大
5、業務開發中單體應用過渡膨脹帶來的問題
- 數據量大，散落各處，取值不便
- 牽一髮動全身，迭代艱難
6、應從哪些角度去進行微服務拆分
- 縱向拆分：從業務維度進行拆分。拆分標準按照業務的關聯程度來決定，關聯比較密切的業務適合拆分成爲一個微服務，功能相對比較獨立的業務適合拆分爲一個微服務。
- 橫向拆分：從公共且獨立功能的維度進行拆分。拆分標準是按照是否有公共的被多個其他服務調用，且依賴的資源獨立，不與其他業務耦合。
- 服務化拆分的前提條件：
-
- 服務如何定義，包括通訊協議，接口描述
-
- 服務如何發佈和訂閱（註冊中心）
-
- 服務如何監控
-
- 服務如何治理
-
- 故障如何定位