【深入淺出，Paas之路】華為云MVP田曉亮：企業向微服務架構轉型的幾點思考

IDC的報告曾指出，到2021年，在超過一半的全球2000強企業中，平均1/3的數字化服務交互都將來自API開放生態系統，增長勢頭遠超其自身的API交互能力。開放的API生態系統是企業數字化平臺開放重構的關鍵。

據悉，來自 Twitter、Netflix 和 Google 等公司的廣受歡迎的公共 API 平均每天調用 10 億到50億次，API調用量逐漸成為一個開放平臺成功的關鍵指標，哪些技術可以驅動API快速增長？

擁有12年研發經驗的田曉亮給出了他的答案。田曉亮現擔任華為云微服務領域首席架構師，他也是國內早期服務網格實踐者，曾自研服務網格作為云服務提供給客戶業務使用。且聽他娓娓道企業數字化轉型的關鍵，以及系統性開展微服務化的一些重要舉措。

微服務為何如此重要？

這里引用Smart Bear 2020年的API報告。

如上圖所示，微服務技術遙遙領先，成為最關鍵的領域技術，是企業API經濟的技術基石。排在第二的DevOps相關技術則是微服務順利落地的關鍵要素和前提。而微服務本身是一種架構模式，這也側面證明了軟件架構設計的價值。

一款軟件大部分的生命周期都處在維護期，不斷地接受新需求，不斷變化演進以滿足需求。軟件架構設計的主要目標便是支撐軟件系統的全生命周期，設計良好的架構可以讓系統便于理解、易于修改、方便維護，并且能輕松部署。軟件架構的終極目標就是最大化程序員的生產力，同時最小化系統的總運營成本，微服務架構恰好能完美地達成這個目標。

當然，有個題外話，研發人員也不必擔心效率提升自己被優化，因為杰文斯悖論在這里也適用：技術進步提高單位人力利用效率，結果是增加而不是減少企業對人力的需求。

是什么阻礙了微服務的應用

接下來再看報告中另一個部分，是什么阻礙一個組織應用微服務？

依次為：

欠缺實踐經驗和技巧（或者我認為是不易雇傭相關人才）；

現存代碼改造難；

工作負擔太重，沒人（新的需求加入管道，它可以增加營收，此時如果老架構不是業務發展的障礙，就被擱置）；

IT成熟度不足、流程問題、基礎設施問題；

沒預算；

還沒確定業務方向；

缺少團隊協作；

缺少工具和技術。

因為缺乏上述提到的這些東西，向微服務架構模式前進的企業可謂是千瘡百孔。作為云服務提供商，或許可以幫助企業解決這些問題。

田曉亮講了一個他親身經歷的故事：我曾經拜訪過一家企業，他們打算讓業務團隊在云上買些虛擬機自己搭建基礎平臺，被我阻攔了下來。因為當他們的業務增長后，會遇到各種各樣的平臺問題，但又沒有相關的人才儲備。當他們用開源的軟件部署，遇到的生產問題其實需要開源社區的人來解決。而這個企業并沒有清晰劃分職責的技術組織。從商業視角出發，非主營核心業務通過外來購買付費服務來完成更為合適。另外他們也許進入了一個致命的架構設計誤區，在沒有確定業務能力的情況下過早的進行了技術選型，而這個工作通常是要延后處理的，平臺的維護成本可能會拖垮業務開發團隊。

通常情況下，大企業一般會使用云廠商提供的計算、存儲等資源，也有自建IaaS服務或者兩者并用的，然后在laaS層之上構建PaaS服務，為公司內部的業務服務。所以大型企業會清晰地拆分業務團隊與基礎設施團隊，田曉亮本人就曾是基礎設施團隊的一員。在這種情況下，基礎設施團隊也是微服務架構模式的忠實用戶。也就是說，他們不但要支撐好平臺用戶的微服務，自己也應用了該模式。

基于多年的微服務轉型經驗，田曉亮提煉了幾個可以幫助企業完成微服務數字化轉型的關鍵點。

如何系統性的展開微服務化

我們可以圍繞軟件開發的速度，系統的安全和服務質量來構建微服務相關技術底座。再結合業務的實際發展，逐步轉型微服務架構，不必在業務發展初期草草決定技術細節。

匹配業務所需

是否選擇微服務架構模式應該從業務實際需求出發，企業先明確定義業務用例和策略，在此基礎上進行架構方案的選擇。對于一些剛剛起步的公司，單體應用也許就能滿足業務需求。

一切以快為準，當單體的開發效率比微服務高時，就果斷的選擇單體。而隨著業務的擴大，企業可以通過絞殺者模式將單體應用向微服務架構模式遷移，進行單體應用絞殺的過程也稱為應用現代化的過程。

據維基百科，絞殺模式的使用場景是從單體應用平滑演進到微服務，將遺留應用程序轉換為現代技術和技術棧的過程，也可稱之為應用程序現代化。

這種模式通常針對1個遺留應用系統，適合前期野蠻成長，業務增速較快的企業。整個改造流程不需要一步到位，一點點補充新的功能進入管道，比如有的功能可以增加營收，此時如果老架構不是企業業務發展的障礙，就可以被擱置并隨時重啟演進。

具體策略有：

新功能用新的微服務實現（阻止單體水平擴展和演進）

隔離表示層和后端（降解單體）

將現有的功能提取到微服務或者獨立為微服務（降解單體）

華為云CSE，解決分布式系統治理之難

從單體成為微服務之后，假如沒有成熟的工具配套，一切的成本都是翻倍提升的，這也是為什么說技術沒有銀彈。運行時的治理就是其中一個難題。

華為云CSE的設計意圖就是讓企業的治理成本和門檻降低，以保障業務穩定健壯的運行，提供高質量API服務。

CSE微服務引擎提供了基于業務視角的流量治理功能，使用可視化界面規劃流量策略，無需關心微服務系統的復雜性。企業需要的只是定義好流量特征，比如登陸操作每分鐘只能允許5次。另外使用Spring Cloud編程的應用可以無縫使用云上的能力，無需額外編碼。

CSE還提供了RBAC認證鑒權系統，提供基于標簽的細粒度資源授權功能，可以規劃多個賬號，賦予角色和相關權限，保證多個團隊協作過程中不會誤操作或者訪問不該訪問的數據。這套認證系統獨立于華為云的IAM，類似MySQL的賬號系統是完全獨立的，這樣團隊之間就可以安全共享一套微服務引擎。

微服務編程框架or服務網格，業務為王

在進行編程框架和服務網格（Istio）之間的技術決策前，不妨先遵循架構設計階段一個較好的指導思想——保留可選項，即盡可能推遲技術細節的相關決策。比如先確定業務能力是什么，收集用例，再決定選關系型數據庫還是非關系型數據庫，亦或是兩者皆用。任何一種技術的選擇皆如此。

如在Spring Cloud這類編程框架和服務網格之間的選型存在疑慮時，就要充分的分析企業的業務是否匹配這些技術的適用場景，是否能支撐商業成果。因為選擇什么技術手段支撐，終究要回歸到業務本質來。企業要對多種可彼此替代的技術進行詳盡的洞察和對比，結合需要支撐的業務場景做詳盡的論證來驗證最適合的技術到底是什么。

下邊這張表格列舉了微服務開發下這兩種技術方案的部分特性對比，它并不代表孰優孰劣，只是告訴企業要選擇對應的能力來匹配業務、支撐業務。打個比方，Istio能提供絕對的內部網絡通信安全，這是它獨有的能力，如果企業的業務需要這樣級別的防護，那么選擇Istio管理會更加方便，而Istio卻有很多不關心的維度，而這些維度正式編程框架提供的能力。

管理好API

如果API主要給外部系統調用，最好采用頂層設計的策略。不建議把這些對外暴露的API的設計權放到各個團隊手中，因為最外層的、系統平臺消費者可見的API必須是定義良好，風格一致的API，并且嚴格控制兼容性，可以使用CloudTest對這些API編寫測試用例，并且在每次部署后，都執行一遍測試用例以確保平臺的行為始終一致。

API是業務的門面，可以采用Spring Cloud Gateway開發框架編寫對外呈現的API，框架會自動生成Open API文檔并注冊到CSE微服務引擎實例中，這樣可以重點審視API的定義，及時進行改進，高質量的交付所有的API。

從DevOps文化建設入手

當企業全面推動DevOps文化，并熟練讓交付團隊掌握相關工具后，微服務架構思維必然會在組織里萌芽。團隊需要代碼庫，流水線等一系列服務來打造一條高效的生產線，故此DevOps技術因為其重要性排在了關鍵技術第二位。如果沒有DevOps的成熟建設，就不要展開架構微服務化。

華為云的DevCloud是集華為研發實踐、前沿研發理念、先進研發工具為一體的研發云平臺,面向開發者提供研發工具服務，讓軟件開發簡單高效

當然，系統性展開微服務化并非只有技術類工作，文化理念、團隊合作形式、關鍵成員不斷學習和精進都是微服務化的關鍵。

總結

簡而言之，微服務架構滿足了架構設計模式中的單一職責和共同閉包原則，它是業務和商業發展成規模化后的必經之路。微服務既符合架構設計原則，也能最小化系統運營成本，支撐高效的商業活動，在激烈的競爭中起到了“潤滑劑”的作用。所以，你的業務是否已經準備好應用微服務了？

微服務 微服務引擎 CSE

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。