嘉賓 | 裴斐

編輯 | 薛梁

雲原生時代已經到來，較早發力的企業和新業務率先享受到雲原生先進理念和領先架構的紅利。然而，傳統行業和企業裡的存量系統，依舊揹負著沉重的技術債務和歷史包袱，在技術革新與架構演進道路上舉步維艱。

12 月 3-4 日北京 ArchSummit 架構師峰會上，我們就策劃了一個專題，專門講雲原生技術應用經驗，和遇到問題該如何解決的話題，這裡麵包括來自百度、作業幫、網易和位元組跳動的實戰經驗。

那麼，傳統業務如何平滑跨入雲原生架構呢？

網際網路企業的做法一般是以“縱”“橫”架構為核心設計導向。縱，即以關鍵技術為核心的縱向能力建設，增強技術能力深度；橫，即以業務場景為核心的橫向能力建設，再結合微服務、負載均衡、服務網格、容器等雲原生技術。

在傳統行業、企業存量系統裡，其實運用以上網際網路企業的方法，也可以幫助傳統行業業務順利進入雲原生“航道”，高效獲得雲原生建設的價值回報。

但這裡也存在一定的技術痛點，接下來從微服務架構選型、閘道器負載均衡、容器環境等角度闡述。

微服務與服務網格

縱1——服務框架現狀：

傳統服務框架的引入需要業務研發者有明顯的感知，隨著服務規模的擴大，需要服務框架引入更多治理功能，隨之帶來了更多需要業務研發者學習、理解、掌控、維護、升級更多服務治理相關框架的壓力。

縱2——服務框架進化難點：

服務框架進化的難點在於不是所有業務都可以輕易遷移到服務網格，需要在傳統服務框架基礎上，具備輕量級的技術方案，以無侵入業務（程式碼）的方式，快速增強現有業務使用的傳統服務框架，具備限流、熔斷、降級、認證鑑權、動態配置等全套服務治理能力，且具備模組化、熱插拔、完整相容性等能力，幫助業務快速實現服務治理的提升，並具備後續演進到服務網格的能力。

縱3——服務網格現狀：

最為流行的服務網格框架 Istio 有良好的背書（谷歌、IBM）和完整的體系能力，但依舊存在協議、註冊中心、治理功能支援有限、傳統環境支援弱等業務落地問題，效能、穩定性無法達到生產標準等大規模生產支撐問題。

縱4——服務網格建設難點：

資料面、控制面等全方面實現協議的擴充套件、註冊中心的納管、治理功能的擴充套件，降低業務接入⻔檻；不侵入原生框架的主幹程式碼完成擴充套件，方便後續沿著社群路線持續演進；延時、配置處理最佳化等服務網格典型痛點，需要結合元件最佳化、網路最佳化、協議棧最佳化等綜合手段實現無限縮小帶給業務效能的損耗。

橫——實現平滑跨越的難點：

服務框架和服務網格解決的問題雖然相近，但技術棧截然不同，且業務希望把使用服務框架階段遺留的問題能使用服務網格統一解決，就導致在使用傳統服務框架的業務，只能透過大量的業務程式碼改造，才能以新的方式接入服務網格，這在絕大多數企業存量業務都很難實現，給業務的架構和技術轉型帶了極大阻力。實現平滑跨越需要探尋使用兩代技術棧（服務框架和服務網格）業務實現呼叫互通、互訪、統一治理的技術方案，並且構建面向業務遷移、可管控、可觀測的橫向平臺，最終保證業務遷移的平滑性和穩定性。

閘道器與負載均衡

縱1——Java 非同步化閘道器難點：

Java 非同步化閘道器受限於 JVM 效能瓶頸，流量代理能力上限明顯。一方面為了應對大規模生產流量考驗，需要完成對 Java 非同步化效能的極致最佳化；另一方面需要構建完整的代理、治理、擴充套件、觀測的 API 閘道器平臺能力。

縱2——基於 Envoy 閘道器構建難點：

原生 Envoy 是一個單純的流量代理軟體，構建完整的 API 閘道器需要圍繞 Envoy 構建完整的控制能力、配置管理、外掛機制、觀測系統以及完善的管控平臺。此外，基於 Envoy 實現 API 閘道器僅僅是一個起點，替代更多傳統 L7 的流量代理或負載均衡器（如 Nginx、HAProxy、F5），以及雲原生的 Ingress、Serverless 函式閘道器，需要圍繞 Envoy 進行進一步的設計與擴充套件實現。

橫——從多元件、多場景到技術棧、能力統一難點：

傳統技術和設計理念下，同樣處理 L7 流量，不同場景使用了不用技術棧，如 API 閘道器有 Java 非同步化的 Spring Cloud Gateway、Zuul，Nginx+OpenResty 的 Kong；負載均衡有 Nginx、HAProxy、F5；雲原生的 Ingress、Serverless 函式閘道器，等等。基於 Envoy 除了能分別實現傳統 L7 流量 代理元件的替代外，還能夠構建統一的通用 L7 閘道器，實現多元件整合統一，以統一元件應對多場景需求。通用 L7 閘道器，整合覆蓋原有多元件、多場景，是“橫”的主要難點。

傳統環境與容器難點

傳統環境下雲原生元件適應能力弱。以雲原生服務網格 Istio 為例，在傳統環境下僅提供了納管虛機節點，且僅支援一臺物理機 / 虛擬機器部署一個服務 +Sidecar 代理，對不具備實際生產需求。想要實現業務從傳統環境到容器環境的演進，需要打通服務網格在傳統環境和容器環境的能力，包括支援一臺物理機 / 虛擬機器部署多個服務 +Sidecar 代理，支援傳統環境的 Sidecar 代理生命週期管理，打通註冊中心、配置中心等等。

從傳統環境到容器環境遷移過程無保障。跨環境的遷移在存量業務系統是常態，遷移過程中流量不中斷、業務無感知是主要難點。一方面需要服務框架 / 服務網格東⻄向代理具備區域優先、異常兜底能力，可以智慧識別並把流量導向可用的環境和服務例項；另一 方面需要類似 L7 通用閘道器能力，解決跨環境、跨叢集網路不通，註冊中心不通的問題。

【活動推薦】

技術方案聽起來都是完美的，但也存在很多實踐痛點，例如急功近利，過於強調新技術；支撐業務場景的廣度不足，⻓效性不足，架構和方案大多短視，短期造輪子等等。