趙 鵬 劉 暢 賈智宇 毋 濤 廖 軍

中國聯(lián)通研究院 北京 100176

引言

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

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

1 服務(wù)網(wǎng)格

1.1 服務(wù)網(wǎng)格概念

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

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

1.2 服務(wù)網(wǎng)格方案對比

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

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

表1 開源服務(wù)網(wǎng)格Istio與Linkerd對比

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

1.3 Istio方案的架構(gòu)

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

圖1 Istio 整體架構(gòu)圖

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

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

2 高可用環(huán)境

2.1 高可用概念

可用性是對一個(gè)系統(tǒng)在功能正常運(yùn)行條件下，該系統(tǒng)不中斷運(yùn)行能力的衡量?？捎眯灾笜?biāo)一般使用系統(tǒng)功能正常運(yùn)行時(shí)間與對應(yīng)統(tǒng)計(jì)總時(shí)間之間的比值作為具體量化指標(biāo)。高可用就是可用性的一種相對較高的水平。根據(jù)系統(tǒng)與應(yīng)用場景的不同，高可用對應(yīng)的可用性指標(biāo)數(shù)值不同，一般認(rèn)為高可用需要達(dá)到99.99%的可用性指標(biāo)。高可用環(huán)境就是為了達(dá)到高可用水平的可用性，系統(tǒng)在軟硬件方面采取的一系列手段。實(shí)現(xiàn)高可用的手段包括負(fù)載均衡、數(shù)據(jù)備份、主備架構(gòu)、多活等等。

服務(wù)網(wǎng)格作為一種微服務(wù)應(yīng)用中的服務(wù)治理方案，服務(wù)網(wǎng)格的運(yùn)行以微服務(wù)的具體實(shí)現(xiàn)方式為基礎(chǔ)。目前，容器已經(jīng)成為微服務(wù)的主要實(shí)現(xiàn)方式，同時(shí)Kubernetes已經(jīng)成為容器編排管理的事實(shí)標(biāo)準(zhǔn)。所以，本文中的高可用環(huán)境就是指以容器和Kubernetes為基礎(chǔ)，通過各種高可用手段，構(gòu)建一個(gè)適合服務(wù)網(wǎng)格運(yùn)行能夠長時(shí)間不中斷運(yùn)行的軟硬件系統(tǒng)。

2.2 Kubernetes集群高可用

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

圖2 兩種Kubernetes高可用架構(gòu)

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

3 部署實(shí)踐

3.1 系統(tǒng)設(shè)計(jì)和規(guī)劃

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

圖3 高可用環(huán)境下的服務(wù)網(wǎng)格系統(tǒng)架構(gòu)

根據(jù)以上系統(tǒng)架構(gòu)，對系統(tǒng)所需服務(wù)器、IP地址以及相關(guān)軟件版本進(jìn)行規(guī)劃，總共需要內(nèi)網(wǎng)IP地址11個(gè)，虛擬機(jī)或服務(wù)器10臺，kubernetes集群內(nèi)部pod和service子網(wǎng)地址段2個(gè)，對應(yīng)軟件及其版本如表2所示。

表2 系統(tǒng)規(guī)劃表

3.2 部署實(shí)踐

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

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

2)負(fù)載均衡搭建：在2個(gè)節(jié)點(diǎn)安裝haproxy和keepalived。Keepalived結(jié)合定期健康檢查和預(yù)先設(shè)置的權(quán)重，將2個(gè)節(jié)點(diǎn)分別設(shè)置為主備，其中主節(jié)點(diǎn)綁定VIP，實(shí)現(xiàn)主節(jié)點(diǎn)對外IP地址的統(tǒng)一。Haproxy負(fù)責(zé)實(shí)現(xiàn)流量在3個(gè)控制節(jié)點(diǎn)層的主節(jié)點(diǎn)之間的負(fù)載均衡。

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

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

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

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

4 結(jié)語

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