微軟Azure App Service開發團隊負責人Stefan Schackow表示,相比單套式架構,微服務對開發者的價值在於「可以快速嘗試及快速失敗」,即使發現該功能有缺陷,也不會對核心系統產生影響。(圖片來源/iThome)

微服務一詞究竟是新概念,抑或只是服務導向架構(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提醒,導入微服務必定有其代價,第一是系統複雜度。再者,應用程式劃分成分散節點後,得謹慎處理系統一致性的問題。最後是維運工作會更加複雜。


Advertisement

更多 iThome相關內容