眾所周知，基於微服務的應用更加適合執行在容器上，可以最大化發揮微服務的優勢。但在微服務應用上容器的過程中，由於使用者實際情況和發展規劃的差異，採取的路徑和方案也有不同。如何選擇最合適的方案，其中的關注點有哪些，並如何應對，都需要去認真考慮。

今天我們跟大家一起聊一聊這個主題《當我們說微服務上容器，我們在說什麼》，分享的內容主要包括微服務應用容器化的幾個典型場景、需要關注的問題以及對應的解決方案。

本文是 6 月 30 日“CloudTech 博雲說”第五期分享內容《當我們說微服務上容器時，我們在說什麼？》的回顧整理。

01 微服務與容器：1+1>2

大家肯定都聽說過雲原生或者 PaaS 落地的三駕馬車，即微服務、容器和 DevOps，三者相輔相成並有著廣泛的聯絡。在雲原生技術落地過程中，應用敏捷迭代和健壯執行的需求正是促進微服務應用產生並發展的重要因素。而虛擬機器作為 IT 基礎設施的支撐，從單體應用到微服務應用的時代，已經無法很好地滿足微服務應用部署的核心需求，即保證資源利用率不降低甚至提升，高效能、高可用、高彈性的保證等。

容器技術的興起並非偶然，而是正好契合了微服務應用時代的需求。

雲原生技術社群中最為人所認可的思想家之一，Adrian Cockcroft，他曾經說過在與容器結合使用後，微服務架構的優點得到了進一步的放大。原因在於，微服務鼓勵軟體開發者將整個軟體解耦為較小的功能片段，並且這些功能片段能夠應對外界的故障。而容器進一步對這種解耦性進行了擴充套件，它能夠將軟體從底層的硬體中分離出來。

根據信通院《中國雲原生使用者調研報告》顯示，國內 64% 的使用者將容器技術應用於部署微服務化應用，這也是國內使用容器的最多場景。

02 微服務的發展歷程

在談微服務容器化部署之前，我們先看看微服務的發展歷程。雖然微服務的架構有多種型別，但從總體來說主要分為兩種：一種是

有一定侵入性的傳統微服務架構

，如 Spring Cloud、Dubbo、gRPC 等，另一種是

近些年興起的非侵入式微服務架構 ServiceMesh

，如 Istio、Linkerd、Sofamosn 等。

其實從微服務發展演進的角度來看，除了所謂的侵入和不侵入的差異，微服務的另一個趨勢是向容器靠攏。傳統的微服務架構沒有考慮太多的容器化部署，而 ServiceMesh 天生就與 kubernetes 緊密結合，不得不說，這也是一種明顯的需求主導的技術變革趨勢。

03 微服務上容器，需要注意什麼？

當然，微服務從虛擬機器部署到容器化部署，肯定會帶來很多變化。那麼會有哪些主要變化呢？我們從以下主要五個角度做了一些簡單總結。

部署形態：從

虛擬機器到容器

的變化；

通訊模式：部署在容器上需要增加一層

容器網路層

；

服務框架：在服務框架上會更多的考慮服務網格方案，從而帶來

傳統微服務框架和服務網格共存以及演進

的問題；

管理架構：

容器化服務/叢集與非容器服務的共存

，需要有容器+非容器的統一部署和運維管理場景

應用架構：需要進一步地做

服務的雲原生/無狀態化改造

。

基於這些變化，我們可能會產生一些疑惑和不確定性。例如，如果是某某框架自研或採購的某某廠商的微服務應用，能上容器嗎？好上容器嗎？會不會很麻煩？帶來哪些問題？註冊是 nacos，或者是用到了某某元件、中介軟體，影響上容器嗎？帶著這些問題，我們先基於一個典型的微服務架構應用來看一下。

這個圖是一個比較典型的微服務架構應用。從業務維度來看，它由前後端的服務組成，基於傳統的管理框架提供註冊和配置。從元件視角來看，它包括了前端、後端服務、註冊中心、配置中心、閘道器和中介軟體。並且對於微服務的管理，還有服務呼叫、負載均衡、限流熔斷、服務監控、事務追蹤、分散式訊息等，透過 Dubbo 或 SpringCloud 可以提供這類管理元件的統一整合方案。基於以上，這時候我們會初步形成兩類微服務應用容器化的方案：

第一種，

對於各類元件、前後端應用去做容器化，改變它們的部署形態

。這個時候業務和治理邏輯還沒有完全解耦，治理和監控對業務程式碼還是有一定的侵入。

第二種，就是框架也進行演進，

採用服務網格 ServiceMesh 的方案，再進行容器化。

第一種場景我們可能會比較關心這些元件和服務的容器化改造的順序，而第二種場景會產生諸如 ServiceMesh 方案選型，傳統微服務治理框架如何更便捷地演進到 ServiceMesh 框架。針對這些問題，我們也梳理了幾個典型場景。

從整體上看，主要有三大典型場景：

傳統微服務架構應用上容器場景，

包括了部分上容器和全部上容器。

服務網格應用上容器場景，

涉及應用直接採用 ServiceMesh 框架和傳統微服務架構遷移或相容 ServiceMesh。

微服務應用容器化之後進行統一治理、運維的場景

。

下面我們一起來看一下，針對不同的場景，在這些場景裡有哪些需要重點關注的地方。首先是微服務應用上容器的兩種方式。

在應用全部容器化的場景，

會關注應用狀態保持、配置、通訊、日誌，版本釋出和部署等。

在應用部分容器化的場景

，需要關注網路互通、配置正確等。由於時間關係，這裡就不一一展開了，這裡可以參考我們最近釋出的《應用上容器指南》。

下面針對一些關鍵點我們來展開詳細闡述一下。

04 微服務上容器，中介軟體不上容器，如何解決網路問題

首先在應用部分容器化中，即微服務應用上容器，中介軟體不上容器的場景中，存在著一個痛點或者關注點，也就是

容器叢集內外如何高效、安全的互通

，就如之前使用虛擬機器網路那樣。

這張圖很好地展現了這個場景，一部分服務部署在了 kubernetes 容器叢集上，但註冊中心、資料庫中介軟體等還是部署在虛擬機器或者物理機上，甚至還有一部分服務也是執行在容器叢集外部的。

那麼對於註冊中心來說，它希望各個服務還是像以前虛擬機器部署一樣去做註冊，網路直通，同時服務對於資料庫中介軟體的訪問效能不要降低。

這其實是對容器叢集的網路方案提出了更高的要求。

目前，業界有這兩種容器網路方案，Underlay 和 Overlay 模型。這兩種模型比較好理解，

一種是容器網路使用虛擬機器網路的扁平化網路方案，就是 Underlay

，

另一種是容器網路在虛擬機器網路之上再架設一層私有網路，就是 Overlay。

對於這種容器叢集內外直通的場景，比較推薦使用 Underlay 方案

，因為這種方案提供了更高的網路效能，更低的效能損耗，並且使用原有的虛擬機器網路實現二層互通，基於固定 IP 地址可以配置精確完整的防火牆策略。

如果選擇 Overlay 網路方案，則需要透過 nodeport 或 Ingress 等特殊配置實現內外網互聯互通，

Overlay 網路方案更推薦微服務和中介軟體全部容器化的場景，

其中跨叢集的通訊可以透過網路聯邦來實現高效能的互聯互通。

05 微服務和中介軟體都上容器，如何解決中介軟體容器化？

剛剛有講過，在微服務和中介軟體都上容器的場景，除了網路選型，還有一個重點關注的內容，就是中介軟體的容器化。例如 MySQL、Redis、Kafka、Nacos 之類，這些中介軟體不光需要考慮怎麼容器化部署，還要進行包括全生命週期管理、可觀測性、災備、自動運維和無縫升級等中介軟體管理能力的建設。

既保障容器化的中介軟體的高效能高可靠，同時也要實現具備更高的自動化運維能力。在這塊，業界有一個基本達成共識的方案，即採用

Operator

，來對中介軟體的單例項/高可用方式進行自動部署編排，並提供相關的全生命週期和監控運維、備份恢復的能力。

透過 Operator 來實現中介軟體容器化，或者說雲原生化，相比於傳統的中介軟體管理和運維方案，例如基於 ansible 的方案，具有特有的一些優勢。一是可以發揮容器的高效能和高彈性，同時具備更強的自動化運維能力和快速部署能力。

現在社群裡也有很多中介軟體的開源 Operator，但如果要做到真正的企業級落地，還需要做很多的增強。

例如，多版本、個性化指標、大規模資料遷移，網路的高效能通訊、安全可靠和運維排障效率高，儲存也有高效能、消耗小、原地重啟、智慧編排、運維簡單等要求，同時開源的 Operator 在跨資料中心的容災雙活和備份能力上也比較缺乏。所以在實際落地中，這些問題都需要考慮，要根據自己的使用場景和需求來合理選擇 Operator 以及是否要去做相關增強。

06 傳統微服務如何向 ServiceMesh 演進？

在微服務應用使用 ServiceMesh 框架的場景中，有個問題絕大部分的使用者都繞不過，就是

現有傳統微服務框架如何演進到 ServiceMesh 架構？

我們可以反過來想想，首先這個事有必要做嗎？或者為什麼要做？

這時候我們需要先了解，傳統微服務框架下存在的大量難以解決的痛點有哪些？

業務程式碼與微服務框架 SDK 強耦合（同一程序）；

業務升級與微服務框架升級強繫結導致微服務框架自身演進困難；

少量語言獨大進展快，小眾語言進展慢帶來的微服務框架 SDK 多語言並行開發與維護成本高；

異構服務框架難以共存完成漸進式演進，導致單體應用改造微服務應用的啟動成本高；

單一的語言限制了應用場景和人才的多樣性，就如 Springcloud 主要支援 Java，對多語言支援比較差。

而採用 ServiceMesh 框架後，實現了業務邏輯與治理功能的分離。在服務網格中，將治理能力下沉到基礎設施後，業務的開發、部署、升級都和服務治理的基礎設施解耦了。業務開發者可以專注自己的業務部分，只要沒有修改業務程式碼，就無需重新編譯和上線變更。當治理能力升級只需基礎設施升級即可，基礎設施的升級對使用者業務完全沒有影響。我們可以看到，ServiceMesh 方案具備多語言、多協議支援，無侵入、治理解耦和下沉、讓開發更加規範化和難度降低等非常明顯的優勢。

這時大家可能會有個疑問，傳統微服務架構應用遷移到 ServiceMesh 上，是不是很麻煩？

我們在相關的專案實踐和落地中，總結了兩種常見改造方案，兩者共同的核心是要去做解耦、剝離以及裁剪的事情。首先是流量治理的相關工作要透過 Envoy 等 Sidecar 來做，另外要考慮的是要不要動業務程式碼本身。

一種比較好理解，就是

裁剪掉服務治理 SDK

；另一種比較保守的方式是

只修改配置，SDK 依然保留

，但實際保留的主要是程式碼框架、應用協議等開發功能，涉及到微服務治理的內容都解除安裝到基礎設施去做。這需要原來的註冊中心，治理等相關功能要藉助 Kubernetes 和 ServiceMesh 去做，包括註冊中心使用 kubernetes service 能力，直接使用 kubernetes 的服務名和埠訪問目標服務，結合自身需求，使用網格中的治理能力來逐步替換原有的相關能力。

修改配置的方式需要手動的配置 ribbon，利用這種機制給對應微服務的後端例項地址中配置服務的 Kubernetes 服務名和埠。當 Spring cloud 框架中還是訪問原有的服務端微服務名時，會將請求轉發到 kubernetes 的服務和埠上。這樣訪問會被網格資料面攔截，從而走到網格資料面上來。服務發現負載均衡和各種流量規則都可以應用網格的能力，就是說原來的 SDK 裡的內容還在，治理元件什麼的也還在，但被旁路掉了。這種方式可以實現程式碼 0 修改，不需要重新編譯，實現真正的不侵入程式碼的轉型和遷移。

但裁剪 SDK 的方式，改造更徹底，從最終的映象大小看，整個專案的體量也能得到極大的瘦身。這種方式客戶根據自己的實際使用方式，進行各種裁剪，最終大部分是把 Spring Cloud 退化成 Spring Boot。這種方式會有一定的程式碼改造工作量，並且需要重新編譯。

這兩種方案可以根據業務開發現狀、規模和需求酌情選用。

說到微服務的管理和運維，我們會關注”兩個統一“。

一個是微服務框架的統一管理，另一個是容器和非容器部署架構的統一管理

。我們的實際現狀可能是一些應用是 Springcloud 框架，有些應用是 Dubbo 框架，有些是 ServiceMesh 框架，而這些應用有可能會部分部署在虛擬機器部分在容器上。整體的、完整統一的釋出和運維管理體系的建立還是很有必要，否則又會產生多套管理平臺，導致運維的工作量增大，運維效率也比較低。

這是一個比較典型的建議，我們推薦微服務的運維管理要做成異構化的支撐，包含監控和治理兩塊的內容需要考慮。我們可以在服務監控上做統一設計，服務治理可以在建立應用時選擇不同的架構進行不同治理方案的選擇，而後根據平臺的統一治理元件管理能力或者 Sidecar 能力來實現不同的治理能力支撐。

07 關於博雲

最後也簡單介紹一下博雲針對我們今天討論的場景，在產品和解決方案維度做了哪些事情。

針對企業微服務轉型，博雲可以提供微服務諮詢服務，並且有相關的企業級產品

微服務應用管理平臺 BMS

，覆蓋開發、釋出、執行階段，同時提供中介軟體統一管理和企業級 API 閘道器等元件，並且具有在大量客戶尤其金融客戶那裡積累了豐富經驗的服務團隊，可以提供一整套完整的產品及服務解決方案。

在產品設計上，我們以應用為核心，提供開發與釋出視角的統一雙模應用釋出、管理、運維視角的統一監控，以及執行視角的多框架統一治理，真正實現了書同文、車同軌。

針對中介軟體管理場景，博雲的中介軟體管理平臺 BMM 基於開源 Operator 做了大量企業級增強，對於之前提到的開源 Operator 的一些不足，如高效能網路和儲存的需求、跨機房的容災備份需求等都做了全面設計提升。目前已經支援了 MySQL、Redis、Elasticsearch、Kafka、RocketMQ、PostgreSQL、Nacos、Zookeeper 等主流中介軟體的全生命週期管理能力。在多個專案的實踐中，對於中介軟體交付效率的提升、運維成本的降低、資源成本的節省都有非常顯著的效果。

在之前討論到容器網路的兩種網路模型，博雲自研的 BeyondFabric 產品都可以提供完整的解決方案支援，它結合了大量實踐場景，從功能的完整性、高效能、穩定可靠性、易用性等多個維度做了全面設計。其中 Fabric Underlay 方案提供 pod 和 workload 的固定 IP 地址和地址段，多資料面管理，pod 多網絡卡多協議支援，透過 DPDK 和動態 qos 提供高效能低延時的支撐，在 IPAM 地址池管理場景，支援大規模 IP 快速分配。

Fabric Overlay 方案提供網路聯邦，在同構的聯邦場景下提供高效能互通方案，不需要使用閘道器，另外提供多種隧道協議及隧道加密支援，可以提供分散式的 Egress 閘道器，在 namespace 和 workload 的級別均可以設定 eip。另外還有一些其他的核心能力，例如透過微分段的方式解決大規模叢集流表效能問題，分散式控制器保障網路執行穩定可靠，支援 windows 網路支援 arm 架構叢集等，在這裡就不一一贅述了。我們在公眾號上也有

容器網路

專題的文章，有興趣的朋友可以搜尋看一下。

今天的分享也到此結束，感謝大家。