【架構師觀點：前平安保險首席架構師蔡學鏞】微服務真正的瓶頸並非技術，而是業務

名列全球財富5百大第39名的平安保險，是中國第二大壽險公司，儘管網路用戶高達達2.4億人，年營收超過臺幣3兆元，但為了迎戰網路巨頭，如阿里巴巴、騰訊等，開始搶占傳統金融業地盤，平安保險早從2015年時，就開始追求轉型，更找來曾在阿里巴巴支付寶和中國銀聯擔任架構師的蔡學鏞，擔任首席架構師，負責打造Open API架構。

平安保險希望透過API，將內部業務系統開放給外部新創，未來若他們要推出新的支付型式，也能整合平安保險的系統和資料。

蔡學鏞為了打造Open API，也開始著手設計新的資訊架構時，但他發覺，若後端系統依舊維持單套式（Monolithic）架構，不僅無法承受過多使用者流量外，未來就算搬上雲端，也無法善用雲端的擴充能力。

面對這些老舊系統出現的弊病，「許多架構師都採取純技術手段，不太關心業務運作邏輯」，蔡學鏞舉例，像系統運作效率不佳、無法承受更多負載，擴充更多硬體資源可用於救急，但終究是治標不治本，「追根究柢，還是得要釐清業務的實際運作邏輯。」

導入微服務得先養成良好開發習慣

「一定要釐清，甚至重整業務的運作」，他以用戶帳號為例，得重新規畫系統需求，釐清用戶與帳號間是否存在一對一、一對多的函數關係。光是第一個階段，他就花了數個月的時間，才對平安保險內部系統完成全面性的盤點與系統分析。

不過，平安保險架構翻新的挑戰不只如此。完成規畫後，開發團對希望可以使用現成開發框架來支援新的架構，為了加速業務系統開發，蔡學鏞只好開始尋找適合使用的開發框架。

起初，蔡學鏞並沒有找到合適的解決方案，「導致工程師仍用老方法做事，因為框架並沒有限制住開發者的壞習慣」，他認為，設計良好的開發框架必須滿足兩個條件。首先是讓開發工作更為簡潔，再者是矯正開發者的習慣，「限制使用者得依循特定規範進行開發。」

在導入新架構的第一步，就是要改善過去不良開發習慣。蔡學鏞觀察到，許多開發者了解業務需求後，只是在資料庫新增欄位，針對特定需求撰寫程式，將資料取出，執行運算再回傳至資料庫。他表示，如此程式碼有3大問題。首先，這些程式只為特定需求而生，其他開發者無法執行維護工作。再者是缺乏結構化設計，即使跟其他系統有重疊功能，「該元件也無法重複利用。」最後則是靠昂貴資料庫執行繁瑣的運算，浪費其效能。

這也逼得蔡學鏞要著手設計自己的應用程式框架Karma，「它是一個純粹的反應式（Reactive）框架」，蔡學鏞解釋，這個框架中將每個元件打包成微服務，而元件彼此間都會互相影響。直到後來他才發現，原來分散應用程式框架Akka的設計理念與Karma有許多重疊，「技術會引領我們到正確的方向。」

微服務得滿足水平擴充、元件可重複使用

蔡學鏞表示，企業導入微服務架構總共有兩個優點。第一個優點是可擴充性，可以鎖定特定系統元件，隨需擴充。再者是元件可重複使用，面對業務變動，只需要稍微調整即可。而他認為，系統擴充性還相對好解決，「只要業務分析做得不徹底，系統元件就無法重複使用。」

以政府高度管制的金融業而言，法規朝夕令改，業務系統得時時配合進行調動。蔡學鏞舉例，中國在2016年12月底開始，總共將銀行帳戶分為3類。第1類帳戶中，存款戶可以自由辦理存款、購買金融產品。第2類帳戶則是透過網上銀行和手機銀行等管道提交開戶申請。第3類帳戶僅能用於小額消費及繳費支付業務，「但是最初設計微服務時，並不會想到這樣的未來需求」，導致當時設計出來的系統元件，不僅無法重複利用，還得一併修改過去的功能。

不過，他也坦言，架構規畫時間不足是導入微服務的一大挑戰。因為現今市場強調敏捷開發的風潮之下，最看重產品發布速度，但貿然在基礎架構功能還不齊全時，就得開始開發新架構的程式。「微服務的重點就是要設計」，雖然市場不會停止改變，但企業若只為速度急著導入新架構，恐怕會讓新架構不夠嚴謹，這是翻新架構的考驗。

也因此，蔡學鏞認為，許多宣稱導入微服務架構的企業，大多只強調系統及技術面，「但業務才是真正的挑戰。」他表示，在企業引入微服務架構之後，至少還要等上1至2年，當基礎架構可以順利撐過更多使用者流量，而系統架構也設想好未來可能需求，「才能夠稱作成功導入微服務。」

要導入微服務，系統得大規模翻新

外部因素如市場需求朝夕令改，使得企業難以導入微服務，但內部因素像系統大幅重構，可能影響系統營運也是一大障礙。

從平安保險推動微服務的經驗來看，蔡學鏞認為，導入維服務要靠公司發揮由上而下（Top-Down）的力量，「如果企業不下定決心大規模重新開發，根本不可能實現。」

由於營運穩定是企業重要目標，但面對老舊的應用程式，無法同時滿足既有架構並且導入微服務，「而全部重開發的風險太高，企業無法承受運作停擺。」蔡學鏞也表示，即使新專案都導入微服務架構也沒用，「因為系統瓶頸不在此，而新系統的後端也都會與舊系統有所牽連。」

蔡學鏞表示，微服務的成功與否，與該公司業務的複雜程度相當有關係。就以銀行、保險、證券金融業而言，業務相當複雜，開發的前置設計就得要花上許多時間。但以一家鎖定社交、社群市場的新創而言，業務相較之下並不複雜，更有機會成功導入微服務架構。

早在20世紀的60、70年代，就有人提出軟體危機（Software Crisis），描述既有軟體的產生方式，難以滿足未來迅速成長的需求。蔡學鏞認為，現在業界狀況則變得更加嚴重，「以前的危機是出自於複雜度，但競爭較不激烈，還有許多時間規畫」，但面對現今市場，企業如果花上半年投入系統分析及設計，「早已經被他人淘汰了。」蔡學鏞認為，即使新專案使用微服務架構，但受到老舊系統的牽制，仍然無法發揮其效益，「唯有經過一段時間，即便市場需求更改，但最初的設計讓開發工作減少，同時，大量流量也靠水平擴充撐過，這才是真正的微服務。」