導入微服務前一定要知道的事

微服務一詞究竟是新概念，抑或只是服務導向架構（Service Oriented Architecture，SOA）在雲端時代的的浴火重生？「在眾多軟體架構中，又蹦出微服務這個新詞彙」，知名架構設計聖經《Refactoring》作者也是ThoughtWorks首席科學家Martin Fowler認為，服務微服務架構沒有一套明確的定義。

前平安保險首席架構師蔡學鏞則表示，曾有中國企業CIO詢問他該如何定義每個微服務的顆粒度（granularity），「這也顯示微服務架構非常的不成熟」，就如90年代開始爆紅的物件導向，開發者亦爭論物件該有的大小，或函數長度為何。

不過，從這個名稱的第一個字「微」，還是可以一窺其特性。Martin Fowler表示，微服務架構是一種開發應用程式的方法，將單一應用程式劃分成多個小型服務。各服務各自執行獨立的程序，並且利用API溝通。同時，各服務功能都是以企業業務邏輯為基礎發展、開發，必須具備自動化、獨立部署的特性。

而微軟Azure技術長Mark Russinovich在自家部落格上也點出微服務架構的最大價值，他認為，微服務具備敏捷、彈性擴充等特性，「非常適用於當代雲端應用程式。」而微服務這一詞背後的意涵在於，應用程式被拆解成各自獨立運作的小型服務，每個服務只負責單一功能，「每個微服務必須能獨立更新，這樣的鬆散耦合架構讓應用程式能夠快速的創新。」

微軟Azure App Service開發團隊負責人Stefan Schackow表示，比起整套系統水平擴充，「將處理大量任務的微服務各自水平擴充，效率會更好」，前平安保險首席架構師蔡學鏞也認為，憑藉這個優點，微服務可以解決促銷、搶購等系統爆量事件。

此外，大型企業應用程式常見的痛點，也就是結構盤根錯節的應用程式平臺，想要修改部分程式碼，都可能牽一髮動全身。相比之下，應用程式架構複雜度比不上這些大企業的公司，碰上轉型時，反而體質上有先天優勢。Stefan Schackow認為，這些企業沒有過多包袱，「新創公司開張第一天就可以使用微服務了」，他認為，相比單套式架構，微服務對開發者的價值在於「可以快速嘗試及快速失敗」，因為該元件只專注於單一任務，即使發現該功能有缺陷，也不會對核心系統產生影響。

而蔡學鏞也認為，業務系統複雜度會影響企業導入微服務的成功機率，「而新創公司有機會導入微服務架構，像是一些專注開發社交、社群應用程式的新創，應用程式可能只需要十多個類別就可以完成。」

傳統應用系統多半採用單套式（Monolithic）架構，Martin Fowler舉例，企業常用的是經典三層式系統架構，只有簡單的客戶端應用程式、資料庫，以及伺服器端應用程式。

Mark Russinovich表示，三層式架構中，每個元件各自是一個單套式的應用程式。一般遇到工作負載超過硬體負荷時，解決方法通常是垂直擴充或升級硬體，「避免重新開發軟體。」但是，他認為，三層式架構會限制了基礎資運架構的敏捷度，開發者只能在同個應用程層內，開發更多彼此互相依賴的服務，「導致任何一個服務的小更動，都必須重新部署整套應用系統。」

雖然單套式架構也可以利用負載平衡，執行更多Instance，完成水平擴充的任務，「不過大家開始對它感到挫敗，因為現在許多應用程式都部署在雲端上執行」，受限於此架構本身的僵固性，Martin Fowler也同意，即使是些微的程式碼異動，開發者也都必須重新部署、建置，隨時間過去，「單套式架構不易維持良好的模組架構。」

微服務是顆粒度更精細的SOA架構

許多人認為，微服務跟傳統SOA並沒有特別差異，僅是新瓶裝舊酒。像PHP之父Rasmus Lerdorf就認為：「在架構上，微服務跟SOA並沒有差異」，即使其名稱有所更動，核心理念仍然是建立模組化、可替用的元件。

Martin Fowler也同意，微服務的確跟SOA相當類似，但他認為，SOA一詞背後有許多意義，原因是許多人利用企業服務匯流排（ESB）整合單套式應用程式，「我看過有些人利用ESB隱藏系統的複雜性，最後得到很差勁的SOA」，因此他認為，微服務可說是實作確實的SOA架構。

蔡學鏞則從應用規模來看，SOA的焦點在於設計出對外的API，讓外部使用者也能介接使用，「顆粒度不是SOA的重點」，但是微服務架構則不然，設計微服務的重點正是精密的顆粒度，為了讓元件具有有高度自主性（Autonomy），各服務都有獨立的資料庫，「微服務就是顆粒度更小的SOA。」他強調。

導入微服務不只有好處，也伴隨著三大代價

誠然，相較單套式架構，微服務確實能解決許多傳統應用程式的開發痛點，開發者看到微服務具有獨立部署、開發彈性大，可以混用多種開發工具的優點時，Martin Fowler也提醒，導入微服務會帶來3種代價。

第一種代價就是分散式系統帶來的複雜度。他表示，分散式系統開發難度高，「遠端呼叫很慢，而且存在失敗風險。」再者，將每個應用程式劃分成獨自運作的分散節點，「系統更新有許多來源，開發者必須要謹慎處理系統一致性的問題。」最後的挑戰則是讓維運工作更加複雜，「如果沒有自動化，根本不可能管理一大堆的微服務」，必須要導入持續整合、系統監控。

紅帽雲端應用程式開發首席架構師Christian Posta表示，當今企業在業務領域及系統規模，都一定會碰上複雜度所帶來的挑戰，對企業來說，「導入微服務是趟長途旅行，無論是企業組織、應用程式規模，或是業務領域都要有所變革。」

Christian Posta也認為，微服務的做法因每家公司而異，沒有非遵守的鐵則或規定，重點在於是否願意付出代價。

但是，企業想要嘗試微服務的好處，到不一定得將資訊架構一次砍掉重練。Stefan Schackow表示：「想要一次到位，很容易跌倒。」他觀察，企業已經投入許多資源在舊有應用程式之上，想要重新開發整套業務應用程式，多半會發生許多問題。他建議，企業在現有平臺上疊加微服務應用程式是比較恰當的做法，「適應一段時間後，就可以將部分核心任務改用微服務提供。」

擁抱微服務要先做的三件事

企業在採用微服務之前，Martin Fowler建議，要先做到三件事，才能順利導入新架構。第一項是，他建議，應用程式必須具備快速建置的能力，想要達到更嚴謹的微服務架構，應用系統開發階段，就必須高度自動化。

第二項則是必須要導入應用程式監控機制。他解釋，由於微服務是靠著許多鬆散耦合（Loosely-Coupled）的服務組成，「系統運作時必定會故障，而且不容易發現問題在哪」，基本必須監控的項目包含系統出錯的次數以及服務可用性。最後一項則是要能快速部署應用程式，「無論是測試環境、正式環境，開發者都要可以快速部署服務」，他認為，在早期階段導入階段中，可以容許些微人為介入，但是最終還是要設法達到全部自動化。

而這三項建議也意味著，開發團隊與維運團隊得更密切合作，「這也和DevOps文化有關聯」，Martin Fowler表示，這樣合作模式的必要性，就是要確保應用程式能快速建置、部署，也能提早一步發現系統故障，「如果無法滿足這三個基本條件，你不應該將微服務架構列入考慮。」他建議。

圖片來源／Ade Oshineye

ThoughtWorks首席科學家Martin Fowler提醒，導入微服務必定有其代價，第一是系統複雜度。再者，應用程式劃分成分散節點後，得謹慎處理系統一致性的問題。最後是維運工作會更加複雜。