趙 鵬 劉 暢 賈智宇 毋 濤 廖 軍

中國聯通研究院 北京 100176

引言

隨著云計算技術得到普遍應用和推廣，應用云化已成為企業(yè)IT系統演進的主流方向之一。由于應用云化和業(yè)務發(fā)展帶來的IT系統在復雜度、可靠性、成本等方面的問題，云原生、微服務、容器化逐漸成為下一代云計算技術的發(fā)展方向[1-2]。云原生是對于應用上云提出的一種應用架構思想和理念。根據CNCF關于云原生的最新定義，云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API[3]。伴隨云原生應用的出現和應用的微服務化，應用內服務或組件的數量成幾何級別增長。由此帶來的多服務間通信成為云原生應用面臨的主要問題，而服務網格正是解決這類問題的主要思路之一。

5G網絡商用落地的同時，市場呈現出了對5G網絡的繁多需求。市場需要已經從單一的網絡連接需求轉變?yōu)閷€性化、動態(tài)化的通信平臺服務的需要。為滿足市場不斷增長的多樣化、差異化需求，全球電信運營商正在嘗試使用基于云原生技術的解決方案，實現5G網絡的高效運營、業(yè)務靈活管理等問題[4]。同時，由于電信行業(yè)業(yè)務屬性之一是始終提供一種長期、穩(wěn)定可靠的網絡連接，所以電信運營商在利用云原生技術靈活、可擴展優(yōu)勢的同時，對云原生方案落地過程中的高可用性提出了更多的要求。本文基于電信行業(yè)對云原生和高可用性方案的需要，設計并提出了一套高可用環(huán)境下的服務網格系統，并通過實際部署驗證了該系統的高可用性。

1 服務網格

1.1 服務網格概念

多組件或多服務之間的通信一直是計算機軟件中的基本組成部分。隨著應用規(guī)模不斷發(fā)展，單服務器性能瓶頸問題以及服務器擴容升級成本問題凸顯，單體應用逐漸向微服務應用轉變[5]。單體應用時期，多服務間通信基本在應用內部實現，各個應用的實現方法各不相同。微服務應用時代，伴隨著應用的微服務化拆分，相比單體應用而言，多服務間通信方面需要解決的問題反而增多。微服務治理問題凸顯，亟待解決服務發(fā)現、故障處理、動態(tài)調度、調用安全等問題。微服務應用初期，各個應用采用各自方式解決微服務治理問題，導致了解決方案與業(yè)務緊耦合，重復開發(fā)現象明顯。隨著微服務治理的發(fā)展，一類更具通用性、與業(yè)務部分解耦的微服務治理庫和框架出現，如 Spring Cloud、Dubbo和Netflix OSS等。但是，這類通用庫或框架在解決服務治理問題方面仍然存在一些不足，如與特定語言綁定、技術門檻較高、業(yè)務邏輯與框架解耦程度不足等。服務網格就是一種解決以上不足的新型微服務治理方案。

Service Mesh(服務網格)一詞最早由Buoyant公司的CEO William Morgan于2016年提出并給出其定義。服務網格是一個專門處理服務間通訊的基礎設施層，它的職責是在由云原生應用組成服務的復雜拓撲結構下進行可靠的請求傳送，在實踐中，它是一組和應用服務部署在一起的輕量級的網絡代理，并且對應用服務透明[6]。服務網格具有如下特點：云原生、透明、網絡代理機制、基礎設施層方案。服務網格的基礎設施層定位，解決了與特定開發(fā)語言的綁定問題；同時，類似于計算、存儲等其他基礎設施資源一樣的使用方式，降低了服務網格的使用難度。通過網絡代理機制，服務網格實現了服務治理與業(yè)務代碼的徹底解耦，實現了服務網格對業(yè)務應用的透明。綜上所述，服務網格本質上就是一類專門解決應用微服務化帶來的多服務間通信的基礎設施級解決方案。

1.2 服務網格方案對比

從商業(yè)模式角度看，服務網格可以分為開源軟件方案和商業(yè)版方案。開源方案目前有Istio、Linkerd、Envoy；商業(yè)版方案方面，云服務商都推出了各自的商業(yè)托管方案，如AWS的APP Mesh，Google的Traffic Director，阿里云的ASM等。商業(yè)版本的服務網格大多基于開源軟件或部分基于開源軟件，并新增了對虛擬機、混合云、多云的支持。例如：AWS的APP Mesh的數據平面代理部分是基于開源Envoy開發(fā)的，對AWS生態(tài)完全集成，支持的服務運行平臺除了AWS EKS平臺外，還支持AWS EC2、AWS Fargate以及客戶在AWS上自建的Kubernetes集群；Google的Traffic Director整體基于Istio研發(fā)，同樣支持服務運行在GKE、虛擬機、客戶管理的 Kubernetes以及混合云中的服務。

服務網格的開源軟件方案數量眾多，但是，目前應用最廣、最具影響力的開源方案主要是Istio、Linkerd和Envoy。Envoy作為一款開源網絡代理被多個服務網格方案采用，并被采納為服務網格方案中的數據平面代理的具體實現。Envoy具有高性能、支持協議廣、流量管理功能豐富等特點。Istio和Linkerd兩款開源服務網格方案的對比分析，如表1所示。

表1 開源服務網格Istio與Linkerd對比

通過表1對比發(fā)現，Istio和Linkerd方案都相對成熟，具備了生產級的可用性，二者都支持主流的容器管理平臺，支持將sidecar自動注入到Pod中，支持多種主流通信協議，均具有完善的流量管理功能。但是，Istio方案具有更豐富的流量管理功能，支持更廣的服務平臺和更多的安全策略配置。具體實踐中應該根據具體需求，在功能豐富度、易用性、性能、兼容性等方面綜合考慮并做出選擇。

1.3 Istio方案的架構

基于以上對比分析，本文選擇Istio作為服務網格的部署方案。Istio方案的架構如圖1所示，整體可以分為兩個部分，即控制平面部分和數據平面部分。數據平面由代理以邊車的形式構成，具體實現服務間的通信和治理?？刂破矫嬗扇糠纸M織，分別是Pilot、Citadel、Galley，控制平面負責對所有代理構成的網絡整體進行編排管理。

圖1 Istio 整體架構圖

Isito數據平面中的代理具體是由Envoy實現的。代理以邊車的形式與對應服務一同部署。代理負責實現服務間的網絡通信，全權代理服務的所有入流量和出流量，同時對應服務對此無感知。同時，代理負責收集并向控制平面報告所有流量數據。Envoy代理本身功能豐富，包括服務發(fā)現、負載均衡、熔斷、健康檢查、故障注入、TLS 終端等。Isito數據平面中的Pilot負責管理數據平面的流量規(guī)則和服務發(fā)現。Pilot負責將路由策略轉換為Envoy特有的配置信息，并下發(fā)該信息到Envoy中，由Envoy代理具體實現流量管理。同時，Pilot通過平臺適配器和抽象模型，實現與平臺無關的服務發(fā)現功能。Isito數據平面中的Galley負責將Istio其余組件與從底層平臺獲取用戶配置的細節(jié)隔離，由Galley統一向底層平臺獲取、驗證用戶配置信息，并將配置信息分發(fā)至Istio其余組件。Isito數據平面中的Citadel負責服務間通信和治理的安全，通過內置的身份和證書管理，實現服務與服務、服務與用戶間的雙向驗證和加密通信。Citadel通過RBAC鑒權模型，支持“用戶—角色—權限”的多級鑒權認證。

Istio通過以上架構實現了服務網格對服務進行治理的透明度最大化，服務無需任何代碼更改，代理只需要消耗少量的資源，并以邊車的形式部署到服務旁邊，就可以截獲流量，實現流量控制。同時，Isito還具備可擴展性和可移植性，流量管理的功能可以通過對接其他系統不斷豐富，Isito對底層平臺依賴性低，可以方便地實現多云、多集群部署。

2 高可用環(huán)境

2.1 高可用概念

可用性是對一個系統在功能正常運行條件下，該系統不中斷運行能力的衡量。可用性指標一般使用系統功能正常運行時間與對應統計總時間之間的比值作為具體量化指標。高可用就是可用性的一種相對較高的水平。根據系統與應用場景的不同，高可用對應的可用性指標數值不同，一般認為高可用需要達到99.99%的可用性指標。高可用環(huán)境就是為了達到高可用水平的可用性，系統在軟硬件方面采取的一系列手段。實現高可用的手段包括負載均衡、數據備份、主備架構、多活等等。

服務網格作為一種微服務應用中的服務治理方案，服務網格的運行以微服務的具體實現方式為基礎。目前，容器已經成為微服務的主要實現方式，同時Kubernetes已經成為容器編排管理的事實標準。所以，本文中的高可用環(huán)境就是指以容器和Kubernetes為基礎，通過各種高可用手段，構建一個適合服務網格運行能夠長時間不中斷運行的軟硬件系統。

2.2 Kubernetes集群高可用

一個基本的Kubernetes集群至少包含以下兩類組件：主節(jié)點(含etcd數據庫)和工作節(jié)點。主節(jié)點包含API服務器、Scheduler和Controller Manager等組件，主要負責整個集群的控制和管理，實現容器的調度編排。Etcd數據庫負責存儲整個集群的配置和狀態(tài)信息。工作節(jié)點包含容器運行時、kubelet和kube-proxy等組件，主要負責承載部署到集群中的容器，是業(yè)務相關微服務組件的實際運行節(jié)點。Kubernetes集群的高可用是指系統在部分節(jié)點無法工作的情況下仍能保持正常運行的能力。由于Kubernetes系統自身就支持多個工作節(jié)點同時工作，即支持工作節(jié)點的高可用；所以，Kubernetes集群的高可用主要是實現主節(jié)點和etcd數據庫的高可用，即通過多個副本實現集群控制平面的高可用。根據etcd數據庫與主節(jié)點的關系，Kubernetes集群高可用架構分為堆疊式和外部式，如圖2所示。堆疊式和外部式高可用架構都采用分層設計，多個主節(jié)點通過負載均衡統一對外服務，多個工作節(jié)點通過負載均衡與主節(jié)點統一通信。

圖2 兩種Kubernetes高可用架構

堆疊式高可用架構采用主節(jié)點和etcd數據庫共享一個節(jié)點的方式部署，etcd數據庫只與本節(jié)點的API服務器通信。外部式高可用中主節(jié)點和etcd數據庫分別部署在不同的節(jié)點上，每一個etcd數據庫節(jié)點分別與每一個API服務器通信，實現了主節(jié)點和etcd數據庫的解耦。堆疊式高可用相較外部式高可用存在同時失敗的風險，即一個節(jié)點故障，將同時導致主節(jié)點和etcd數據庫故障，從而導致集群中可用性快速下降。反而，外部式高可用可以減少此類故障下的可用性下降程度。

3 部署實踐

3.1 系統設計和規(guī)劃

根據高可用環(huán)境部分和服務網格部分的分析，本文提出一種高可用環(huán)境下的服務網格系統，系統架構如圖3所示，主要包括三個部分，工作節(jié)點層、負載均衡層、控制節(jié)點層?？刂乒?jié)點層由3個主節(jié)點和3個etcd節(jié)點構成，采用外部式高可用Kubernetes架構，實現Kubernetes集群的高可用。負載均衡層由兩個負載均衡節(jié)點組成，二者互為主備，實現負載均衡自身的高可用，同時，通過浮動IP的方式，實現主節(jié)點對外的統一IP地址暴露。工作節(jié)點層由兩個節(jié)點構成，實現對服務網格以及其他應用的高可用承載。

圖3 高可用環(huán)境下的服務網格系統架構

根據以上系統架構，對系統所需服務器、IP地址以及相關軟件版本進行規(guī)劃，總共需要內網IP地址11個，虛擬機或服務器10臺，kubernetes集群內部pod和service子網地址段2個，對應軟件及其版本如表2所示。

表2 系統規(guī)劃表

3.2 部署實踐

根據上述系統設計與規(guī)劃，系統部署實踐主要分為六個部分，包括：環(huán)境準備、負載均衡搭建、etcd集群安裝、主節(jié)點搭建、工作節(jié)點添加、isito和應用部署。前五個部分為高可用環(huán)境的部署，第六部分為服務網格以及典型應用的部署。

1)環(huán)境準備：該步驟主要是完成操作系統、網絡以及基礎軟件的安裝調試，保證網絡連通，主要包括在除負載均衡節(jié)點以外的所有節(jié)點完成docker、kubectl、kubeadm、kubelet等軟件的安裝。為保證后續(xù)步驟的順利進行，在本步驟中對docker進行設置，主要是將docker程序的cgroupdriver選項設置為systemd，并為docker添加國內鏡像倉庫。

2)負載均衡搭建：在2個節(jié)點安裝haproxy和keepalived。Keepalived結合定期健康檢查和預先設置的權重，將2個節(jié)點分別設置為主備，其中主節(jié)點綁定VIP，實現主節(jié)點對外IP地址的統一。Haproxy負責實現流量在3個控制節(jié)點層的主節(jié)點之間的負載均衡。

3)etcd集群安裝：由于網絡原因，etcd集群安裝采用二進制安裝方式。提前生成并分發(fā)ca、server、client等證書到3個etcd節(jié)點，然后通過二進制安裝etcd程序，并通過修改etcd集群配置文件，啟動etcd集群。最后，通過增刪改查等操作，驗證了etcd集群的功能和高可用性。

4)主節(jié)點搭建：首先利用etcd階段生成的證書，完成主節(jié)點1的初始化。在完成網絡組件flannel的安裝配置后，再依次添加其他2個主節(jié)點加入控制平面。

5)工作節(jié)點添加：確認2個工作節(jié)點已完成docker安裝和配置，根據主節(jié)點證書和令牌依次添加2個工作節(jié)點。

6)isito和應用部署：通過yaml文件分別安裝isito和業(yè)務應用，驗證了服務網格對業(yè)務應用中的微服務進行管理的功能，包括灰度發(fā)布、流量調度等。

4 結語

以服務網格為代表的云原生技術凸顯了靈活、快速的優(yōu)勢，該技術尤其適合以5G技術為代表的電信運營商。服務網格在滿足電信級高可用條件后，將更進一步促使該技術在電信行業(yè)落地。本文在分析了主流服務網格Istio和Linkerd方案，并對比了Kubernetes堆疊式和外部式高可用架構的優(yōu)劣之后，在此基礎上提出了一個完整的高可用環(huán)境下服務網格系統。本文通過實際部署，驗證了服務網格能夠在該系統中長期穩(wěn)定運行，同時通過代理的方式簡潔地解決了微服務化應用中服務發(fā)現、流量調度等服務治理問題。該系統對后續(xù)通信領域服務網絡落地實施提供了一定的借鑒和參考。但是，本文所提方案應用于通信領域，推動5G業(yè)務快速發(fā)展，還需要進一步研究實踐，特別是還需要在服務網格多集群、多網格、高可用以及大規(guī)模高可用集群環(huán)境等方面進行研究與探索。