微服務到底要解決什麼問題?

我在台灣的軟體公司服務, 觀察到許多公司在人才招募, 或是對外宣傳, 都會高聲呼喊著我們使用了 "微服務", 但當我成功進入一家公司, 我發現 "微服務" 並非那麼理想的解決團隊或業務發展所遭遇的問題, 甚至是一種商業口號, 聽起來比較高大尚, 比較好做生意 XD

若能用一句話總結, 那應該就是下面這句話了

Small, and Focused on Doing One Thing Well

這本書給了一些角度, 讓我重新思考與檢視公司的微服務架構設計, 有時候技術並非只是為了解決技術面向的問題,

建構微服務｜設計細微化的系統 (Building Microservices)

-- Sam Newman, O'REILLY, 2016

把微服務的格局縮小一點來看, 可能就是 SOLID principles, SRP (Single Responsibility Principle), 專注做好一件事, 把這概念放在軟體架構設計領域裡, 就變成微服務了. 這中間最困難的點在於如何定義好 "一件事", 並且取得平衡?

這個 "一件事" 可能是商業上的業務, 也可能是一個團隊要解決的問題.

微服務的團隊組織

在一個 5 人的開發團隊, 跟 50 人的開發團隊, 系統在設計必會有所差異. 而我認為這是最現實的人力問題. 你能想像在一個 5 人的開發團隊裡, 設計了 50 個微服務, 每個開發者必須在這個迷宮架構裡手忙腳亂地去維護這套系統?

我喜歡書上寫的一個觀點, "微服務" 可以是解決業務擴展, 而切分團隊的一個解決方案, 舉個我工作經驗上的例子好了, 一個電子商務系統, 原本的業務順序可能是, 使用者把東西加入購物車, 進入付款流程, 付款成功產生收據, 但隨著業務要支援現在越來越多樣的 "支付", 其實可以成立一個專門處理 "支付" 的團隊, 開發整合第三方的支付服務, 再統一設計一個專門的介面, 讓其他需要支付業務的團隊可以使用呼叫, 且回傳統一的格式與資料.

然而隨著業務的發展, 在 "支付" 處理的流程中, 可能會延伸出 盜刷, 洗錢名單 相關風險檢核, 這些業務是不是要統一介面給其他團隊呼叫, 其實就能決定是否要切一個微服務, 就看公司業務性質了.

彈性與技術分解

這也是微服務的一個重大優勢, 每個微服務都是具有自治能力的 (Autonomous), 也就是可以配合團隊招募的開發者, 選擇適合團隊的技術, 程式語言, 交付流程, 等等.

然而, 我實務上比較常利用微服務來處理一些升級的測試, 或是 AB 測試, 舉例來說, 原本某個 API 是設計在 Spring boot 2 的微服務裡, 但 Spring boot 3 是公司未來會採用的框架, 這時候我會嘗試把 API 移植到 Spring boot 3 的微服務, 並且盡可能地去採用 Spring boot 3 的新功能. 在這過程中可能會遇到流程需要呼叫舊的其他微服務, 這時候反而可以重新審視一下業務的邊界, 考慮是否要重新內聚？

架構擴展

若從水平擴展的角度來想, 微服務可以是解決高負載的一種方案, 假設一個微服務的 API 在一個時間點內可以處理 200 個請求, 當業務遭遇高併發業務時, 若該業務能設計成可以水平擴展, 盡可能的保持流 (Stream) 方式的處理, 盡可能地 Stateless 或許也是一種設計微服務的思考方式, 像是一些排程作業, 可能就很適合.

破碎的交易

微服務並非完全沒有副作用的, 當業務邊界不夠明確, 或是業務變動, 某些交易的一致性會變得非常麻煩, 或是遭遇難以處理的 CAP 相關問題, 我曾遭遇過有些公司用資料表來切分業務邊界的, 購物車相關資料表建立一個微服務, 結帳資料表建立一個微服務, 這會導致一些可怕的狀況, 使用者把東西加入購物車成功, 但在呼叫結帳微服務的 API 失敗, 導致了一個失敗的使用體驗. 而開發者時常因為版本差異, 導致 API 欄位異動或不相容... 我親身經歷過, 真的是惡夢.