前平安保險首席架構師蔡學鏞認為,許多宣稱導入微服務架構的企業,只強調系統及技術面,但是,業務才是微服務架構真正的挑戰。(圖片來源/iThome)

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


Advertisement

更多 iThome相關內容