Clean Architecture Chapter 27 Services Great and Small (Robert C. Martin)

沒有精準讀完整本書, 只是針對第 27 章的服務進行討論

SOA or Microservices 架構的迷思

Robert 主要針對 SOA 與 Microservices 所宣稱的優點進行批判一下

• Services 本身要和其他服務進行解耦 (decouple )
• Services 可以區分成許多獨立(independent)團隊進行開發與部署.

針對 decouple 解耦上面的謬論, 他指出在一個系統之間, 因為有許多共享的資源, 導致解耦上是困難的, Services 之間其實都具有某種相依性. 導致彼此 APIs 呼叫時, 增加新的欄位都會容易造成問題.

此外, 歷史證明老舊系統也可以建構在 Monoliths 或是 Component-Based 的系統上, 不斷地擴充與應用. 許多 independent 獨立運作團隊是很難獨立存在的, 開發/部署/運作 時都是需要彼此協調的.

Kitty Problem 討論

簡單來說, 若一個計程車叫車系統已經運行了一年有餘, 那麼當初宣稱使用 Microservices 所建構的架構如下.

現在加入了允許攜帶小貓功能, 這功能要有 Taxi 運匠願意送, 且若客戶宣稱對貓過敏, 要排除三天之內有送過小貓的 Taxi.

此時, 使用 Microservices 必須同時修改 Taxi UI, Taxi Finder 與 Taxi Selector, 解耦的結果就是都要去調整, 且上線的同時, 版本也需要同步更新. 因此獨立團隊也根本不獨立.

接著, 若採用物件導向的設計.

基本上, TaxiFinder and TaxiSelector 是 interfaces 去實作成為 Rides, 當有 Kittens 加入時, 也是實作相關的 interfaces. 換言之, 可以擴充且延伸開發的架構才是 Robert 認為的架構設計所在.

但是 Microservices 架構之中, 是否可以做到 OO 的設計進行擴充呢 ?

我想, 他的重點應該就是 27.3 這張圖, 不用過度強調 Microservices 架構. 而是講求 Services 內部架構設計是否允許可擴充才是架構的重點.

結論

其實, 我認為 Robert 對於 Microservices 架構上面的認知有點偏激. Microservices 所強調的 decouple 是一種概念, 讓每個團隊可以獨立運作且充分合作. 假想, Google Map APIs 要更換版本, 所有有使用到 old API 的 APP vendors 當然都要配合修正之. 然而, OOP 設計理應當存在每個環節之中, Service 內部當然也不例外.

另外, Microservice 的版本同步也是另外的一個課題, 以 TaxiUI 來看, 都需要等到 Finder/Selector/Dispatcher/Supplier 都要到新的版本才能開放, 此時就要有一個 version tracking 機制在其中, 或使用 k8s 的 chart 去定義版本號. 才能避免版本不對稱的問題.

最後, 我認為 Microservice 最大的優點就是 decouple, 因為 decouple 可以讓團隊更清晰他們的工作目標與職責, 在 container 環境之中, decouple 可以讓 scale 更為簡單容易. 只是 Robert 認為 Service Decouple 不是真正的架構(我其實不否認這句話), 真正的架構是 Object-Oriented 的思維. 也許是我們早已習慣 OO 的設計與開發, 認為這是理所當然的事情而已吧.