前言

依個系列主要係個人讀書紀錄，希望可以達到幾個自我目的。

• 紀錄自己既讀書進度

• 之後睇返自己既簡讀從而減少重讀既時間

• 加強自己閱讀記憶

同時都希望各位不幸讀到既小弟文章既師兄有所裨益，歡迎指導小弟。
注：文章有好大可能會中英夾雜，盡量希望用日常溝通用詞編寫。

正式進入主題！

CH 1 - 什麼是微服務?(What Are Microsevices?)

微服務Microservices 係其中一種服務向架構(service-oriented architecture)

特點：

• 獨立可發佈性 (Independent Releasable/Deployable)
• 圍繞商業領域(Business Domain)設計
• 每一個微服務都係可被視為黑盒 (Black Box)
• 擁抱資訊隱藏，高內聚，低耦合 (High cohesion, Low coupling)
• 管理及擁有各自嘅狀態
• 服務由網絡連接(提供/獲取）

獨立可發佈性

獨立可發佈性係微服務最最最重要嘅紀律。重點係可以喺唔需要重新發佈任何其他微服務嘅情況下，進行更改，發佈俾我哋嘅用戶使用。為左獨立可發佈性，我哋要確保微服務係低耦合，同時需要確保服務之間有明確，清晰同穩定嘅合約/接口。
向後兼容亦都重要，令上游服務唔受更新影響。

圍繞商業領域設計

有啲技巧例如領域驅動設計(Domain-driven design，DDD)可以幫到我哋有更好嘅代碼結構，更真實咁反映現實領域。微服務都有同一樣嘅概念去定義服務邊界。如果推出一個新功能，係需要更改超過一個微服務嘅話，會係好高成本！所以針對商業功能去分割服務係嘅話，就可以盡可能高效咁更新商業功能。微服務嘅方向係，比起技術功能嘅高內聚，商業功能嘅高內聚係更優先嘅選擇。

擁有服務自己嘅狀態

微服務應該避免使用共用數據庫。如果一個微服務想要拎到另一個微服務嘅數據，應該去向果個微服務請求。咁微服務就有能力決定有咩係共享，有咩係隱藏，咁樣我們能夠清晰咁去區分可以自由更改嘅內部功能同埋唔可以經常更改嘅外部接口。微服務隱藏內部嘅狀態，就好似面向對像OO編程嘅封裝。

大細

Microservice應該幾Micro?依個問題係冇絕對答案。或者個答案係：盡量細但同時提供到佢自己負責嘅功能。作者覺得係唔洗擔心Microservice嘅大細，反而更家應該關注嘅係2個問題，你可以處理到幾多個微服務? 點樣去界定服務範圍令到服務發揮全部嘅功能，而唔令到所有嘢變得混亂耦合。

靈活性

Jame Lewis話 "Microservice buy you options",「微服務為你提供選擇」。同時Buy係買，係有成本/代價嘅！你要決定值唔值得為你之後可能嘅選擇去付出依個前設成本。當然，佢帶黎嘅靈活性都係多維度嘅，包括組織、技術、規模、穩定性等等。我哋唔會肯定到將來會發生咩事，依個架構理論上可以幫我哋解決將來可能遇到嘅問題。喺開放性同架構成本之間做一個平衡！

對齊組織架構同系列架構

三層式架構係系統設計中係非常普遍，作者認為最主要嘅原因係因為我哋係咁樣去建立我哋嘅組織架構。
康威定律(Conway's law)

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
(自行翻譯本)系統設計受制於製造出黎嘅組織機構，基本上係複製機構嘅對話溝通結構。

因為開發部門通常都係分開前端(Frontend), 後端(Backend)同數據庫管理員(DBA)。所以就自然會出現三層式架構，各職員可以順暢咁進行自己果部份嘅開發工作。依種架構選擇咗一個最佳化嘅方向--技術！我哋將同一樣技術嘅人分類喺一齊。

但係我哋被要求做嘅大部分更改都係同商業功能有關。依個架構有高技術內聚，但商業內聚就相對較低，每一個改動可能都會橫跨三個層面。而微服務方面，每一個服務可能end up都需要依個三層架構，但呢個只係服務內部嘅實作問題。
其實放眼公司其他部門，其實大部分都係商業分類。例如：客服部，倉務部，采購部等都係進行業務分層！

單體架構(The Monolith)

前面已經初步講左微服務，通常都會同Monolith架構作比較。為左更好了解，以下會討論一下咩係Monolith架構

單進程單塊架構(The Single-Process Monolith)

出於穩健性同埋擴展性，Single-Process Monolith都可能有好多個實例(Instances)，即係複雜個程式係多個伺服器上面。但係佢哋嘅本質都係一致，就係將全部代碼打包晒喺一個進程入面。而最終都係喺一個數據庫度讀/寫數目，比其他程式或者人去使用。依個方法簡單，直接，大部分人一睇就明，喺相對較細嘅組織係非常合理同有效。

模塊化單塊架構(The Modular Monlith)

單進程單塊架構嘅變化版，包含左獨立嘅模塊。每個模塊可以獨立運行，但係仍然需要合埋一齊咁去部署。對於好多組織嚟講，模塊化單塊架構可以係一個更好嘅選擇。如果模塊嘅界限定義得好，佢可以容許高度平行工作，同時避免咗分佈式微服務架構嘅挑戰，係一個簡單好多嘅部署方法。

分佈式單塊架構(The Distributed Monolith)

分佈式單塊架構係一個由多個服務組成嘅系統，但由於種種原因，整個系統必須一齊部署。作者認為，依種架構同時擁有分佈式同埋單塊架構嘅缺點，又得唔到兩方面嘅優點！

單塊架構與交付競爭(Delivery Contention)

因為單塊架構嘅問題，當越來越多人同時係同一個系統上面做更改，開發員之間就會越要大量協調。唔同嘅成員係幾時推出功能會有分歧，可能其中一部分已經做完，但另一部分又仲做緊，令到推出時間推遲。喺邊個負責咩嘢同邊個決定嘅問題上，容易產生混淆。

Monolith優點

簡單得多嘅部署方式可以避免唔少分佈式系統嘅陷阱。可以導致更加簡單嘅開發者工作流程，監控、排除故障，以及端對端(end-to-end)測試嘅活動都可以大大簡化。
Monolith亦可以簡化內部嘅代碼重用。如果我哋要喺一個分佈式系統內重用代碼，我哋需要決定係咪要複製代碼、拆個Library出黎、將共享單嘅功能放入一個服務。而對於一個Monolith，就簡單得多，所有代碼都喺度，就直接用啦！
有啲人開始覺得Monolith係需要避免嘅。佢哋覺得『Monolith』呢個詞同『Legacy』係同義詞。作者認為Monolith係一個選擇，而且係一個明智嘅默認選擇(default choice)。

待續；