程式架構新取向 CA API Academy 與香港開發者探討「微服務」

微服務(Microservices)是現時企業開發應用程式的新方法。到底微服務有甚麼特點?CA Technologies API Academy 的 API Architecture 主席 Mike Amundsen 早前便來港分享了微服務的議題。

 

速度、安全乃微服務主要好處

微服務把大型單一(monolithic)的應用程式分拆為低耦合度(loosely coupled)的功能,並以 API 來互相存取。隨著 Agile 和 DevOps 的概念興起,微服務亦日漸流行。

各人對微服務有各種定義,Amundsen 則稱之為「於受限範內能互相操作、獨立部署的組件(independently deployable component of bounded scope that supports interoperability)」。現時已有不少企業使用,如 Netflix、Amazon、Spotify 等。

他續指,每間企業使用微服務的原因不盡相同。Netflix 透過微服務來把單一的系統分拆並遷移到雲端,加快系統測試和發布;Spotify 卻是應用於團隊中,使他們能更自主地拓展服務。不過總括而言,微服務能促進創新、加快速度、減低成本、避免技術負債(technical debt),「大規模地協調(harmonise),而非平衝(balance)速度和安全」。

 

微服微著重可替換性

Amundsen 指出微服務對於大型的項目較為理想,而且應以目標為本,如 Netflix 的微服務就以影片沒有緩衝為目標。另外,微服務著重「可替換性(replacability)」,即是開發者不會修改微服務的程式碼,而是整個換掉。這樣服務便可以在短時間內作小規模更新,降低風險。假如服務要在一段時間後推出大規模更新,除了有技術負債的風險之外,程式出現問題的話開發者便要花若干的時間檢查。

他續指,微服務的系統設計應考慮五個因素,即服務、解決方案、過程和工具、組織以及文化,當中後三者是關於「人」。Amundsen 又以 Netlfix 為例闡述人的因素如何影響設計,指他們內部需時 6 個月來批准一個項目遷移到雲端。

Amundsen 又說,設計時應把過程、產出和人劃一化。他補充,這其實是一個取捨,如把「人」劃一化會失去創新的機會,但效率可上升。

他亦告誡出席者,不應為加入一些很「有形」的功能而使系統變得複雜。

 

開發團隊少人為佳

最後 Amundsen 分享了有關開發團隊和創新的看法。他指出團隊的成員數目愈多,程式的錯誤亦會愈多,因此成員數目應保持少數,除可改善程式亦可促進溝通。Amundsen 更引用 Amazon CEO Jeff Benzos 的「2 Pizza Rules」總結:如果兩塊簿餅不能餵飽團隊成員,即是團隊太大了。

他又指企業應勇於創新,因為只有肯面對風險的企業才會成功;企業失敗的話則是一個學習的機會。Amundsen 引用 Google 作例子,指公司 20% Time 的概念讓員工於空餘時自由創新,從而製作一些未經計劃的創新產品。