《從零開始學架構》筆記——第三部分：可擴展架構模式

• 2019 年 10 月 6 日
• 筆記

第十章 分層架構(面向流程拆分)

• 保證各層的差異足夠清晰，邊界足夠明顯
• 隔離關注點
• 層層傳遞

例如：MVC：分離數據處理，視圖顯示，業務邏輯

第十一章 SOA架構（面向服務拆分）

背景：

企業內部的IT系統重複建設且效率低下。

• 企業各部門都有獨立的IT系統，人力資源部門，財務部門，銷售部門....當一個員工離職後，需要很多部門同時註銷資訊。（冗餘）
• 業務發展，各部門合作的複雜度升高。

SOA思想

• 服務 所有業務功能都是一項服務，對外提供開放介面。例如上述各部門的人員管理就可以單獨劃分出一個服務，實現復用。【服務粒度的劃分是關鍵】
• ESB企業服務匯流排 屏蔽系統對外提供介面的方式，實現服務連接。
• 松耦合 減少服務的依賴和影響。

ESB問題和被背景

ESB功能強大，支援HTTP，RPC，JMS等多種協議和轉換格式，但同時帶來了大量資源消耗。

ESB的背景是在各種異構系統存在多年的情況下產生的，實屬無奈之舉。

第十四章 微服務

微服務和SOA的關係

1996 年，第一個SOA報告被發布

2014年， Martin Flower一篇關於微服務的學術性文章將微服務推向了高潮

從歷史的角度看，微服務和SOA是有一定先後次序的，兩者雖不相同，但也許有些淵源。

• 服務粒度 微服務比SOA更細
• 服務通訊 SOA採用ESB匯流排，而微服務採用HTTP輕量級通訊
• 服務交付 SOA慢，而微服務倡導持續交付，速度快
• 應用場景 SOA的ESB是針對已有大量異構系統的企業級設計的；而微服務更適合互聯網公司。

SOA和微服務並不存在優劣之分，兩者應用的場景應對的問題完全不一樣，就像你不能用一顆糖的好壞衡量一塊磚的價值。

微服務的坑

• 服務劃分過細，服務間關係複雜【單個系統複雜度下降，整個系統的複雜度上升】
• 服務數量太多，團隊效率下降
• 調用鏈過長導致的性能下降和排查問題困難
• 自動化部署複雜

微服務最佳實踐

• 服務粒度拆分（推薦三人開發一個微服務）
  • 基於業務邏輯拆分
  • 基於可擴展拆分（拆分出穩定，變動不大的微服務）
  • 基於可靠性拆分（將可靠性要求高的核心業務拆分出來）
  • 基於性能拆分（將性能要求高的拆分出來）
• 基礎設施
  • 自動化測試，部署
  • 配置中心
  • API網關
  • 服務註冊
  • 服務發現
  • 服務路由
  • 服務容錯
  • 服務監控
  • 服務跟蹤
  • 服務安全