張金玲 王天人 蔣 成 張正明 許 翀

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

引言

當微服務的數(shù)量隨著業(yè)務數(shù)量的增加而增加時，封裝和運行微服務程序的容器管理和編排難度相應的增加，微服務項目融合容器編排體系非常有必要。同時微服務支持的技術比較復雜且支持多種技術開發(fā)語言，因此開發(fā)語言之間如何調用、如何替換其他技術語言、如何降低技術升級替換成本等問題亟需解決，加之業(yè)務邏輯的復雜性需要項目研發(fā)人員的精力集中在業(yè)務的開發(fā)上，項目中服務的治理和運維需要分離開來，服務網(wǎng)格的引入很好地解決了這些難題[1]。服務網(wǎng)格將服務管理功能從整體項目中獨立出來，將服務治理功能提到微服務的底層部署端，在微服務底層部署端以獨立的方式部署，這種獨立服務治理方式敏捷地完成了項目的迭代演進，保障了系統(tǒng)的高可靠性，實現(xiàn)了支持多種語言的開發(fā)。

本文以現(xiàn)有的單體微服務項目為改造背景，介紹如何將容器編排技術、服務網(wǎng)格技術應用到微服務項目改造中。

現(xiàn)有微服務項目融合了業(yè)務與分布式系統(tǒng)的服務管理功能，服務管理包括服務注冊、服務發(fā)現(xiàn)、配置管理、熔斷限流、路由分發(fā)等功能，目前存在的問題有以下四點。

1)微服務數(shù)量隨業(yè)務量增加而增多，部署的容器數(shù)量級隨之變大，對于大量容器的編排問題需要解決。

2)業(yè)務復雜性帶來業(yè)務垂直深度的增強，共享能力和業(yè)務分工問題開始凸顯。

3)業(yè)務問題方面，業(yè)務邏輯與服務治理相關功能結合緊密，使得開發(fā)人員在開發(fā)業(yè)務邏輯的同時需要完成運維功能的開發(fā)，工作量巨大，開發(fā)人員不能專心投入于業(yè)務的研發(fā)。

4)原項目的運維部分功能支持多種語言開發(fā)的靈活性不高。

因此現(xiàn)有項目改造為基于容器編排技術和服務網(wǎng)格技術的項目非常有必要。整體改造方案首先完成容器的自動化部署運維，接下來進行業(yè)務間的逐步松耦合，業(yè)務邏輯與服務治理間的逐步松耦合，繼而形成專業(yè)分工的松耦合團隊，最終使得應用得以敏捷開發(fā)、快速增長[2]。

1 微服務項目改造方案

基于服務網(wǎng)格的微服務項目通過將原項目融合容器編排系統(tǒng)和服務治理框架，改造成為將服務治理功能從整個項目中獨立出來，將服務治理功能提到微服務底層部署端，在微服務部署端以獨立方式部署，容器部署運維自動化的體系。

整體的改造項目的技術架構圖如圖1所示，在服務治理與業(yè)務邏輯分離的實現(xiàn)上，服務網(wǎng)格采用了Sidecar模式，由圖中的Envoy實現(xiàn)，相較于將服務發(fā)現(xiàn)、服務路由等能力嵌入到應用內部的普通微服務框架更加靈活，做到了對應用完全無侵入性[3]。微服務與其代理之間相互通信，代理完成微服務輸入和輸出流量的控制，代理也可以作為網(wǎng)關，根據(jù)從Polit獲取的規(guī)則對外部的訪問進行接收并轉發(fā)到應用系統(tǒng)中。所有微服務部署在容器編排系統(tǒng)上，每個Node有一個或多個Pod，微服務所有的相關信息存儲于etcd中，對微服務信息的操作都經(jīng)由API Server的調用并訪問etcd完成。

圖1 改造項目技術架構圖

整體的改造項目的技術功能如圖2所示，共分為三個部分。

圖2 改造項目技術功能圖

1)在業(yè)務應用部分：改造后的業(yè)務應用只保留業(yè)務相關邏輯，并包裝為多個微服務。

2)在服務治理部分：改造項目將業(yè)務邏輯和服務治理功能分離，項目中動態(tài)路由、熔斷限流、安全訪問、流量攔截、負載均衡、服務發(fā)現(xiàn)、流量治理、服務監(jiān)測等運維功能分離出來。

3)在容器編排部分：業(yè)務層微服務的部署于容器中，容器管理部分包含自動化部署、擴縮容、狀態(tài)監(jiān)控、故障遷移、資源調度、資源隔離、容器運維等功能。

整個項目的服務運維層面功能由服務網(wǎng)格提供實現(xiàn)，包括服務可視化監(jiān)控和豐富的服務治理能力，由此很好地解決了系統(tǒng)微服務化后的維護難題。

2 通過容器編排技術實現(xiàn)基礎設施自動化

原微服務項目以容器化技術解決部署配置的問題，但隨著細粒度的微服務越來越多，進而存在容器管理和編排上的困難。為應對以上問題，將項目原有Spring-Cloud框架結合Kubenetes容器編排系統(tǒng)的技術架構，即改造為使用spring-cloud-kubenetes框架，底層使用Kubenetes環(huán)境實現(xiàn)自動化部署、容器擴縮容、容器的健康狀態(tài)管理、自動運維和跨集群調度等。

SpringCloud項目在改造為容器自動化編排時，結合spring-cloud-kubernetes框架，調用Kubernetes能力，服務注冊后微服務相關數(shù)據(jù)存儲在etcd中實現(xiàn)，其架構如圖3所示。

圖3中，Spring-Cloud環(huán)境下運行的serviceA和serviceB分別部署在Kubernetes的不同Node節(jié)點不同的Pod上，Kubernetes對應用服務提供了自動化部署以及后續(xù)容器的運維工作，同時部署時將服務的各個實例的地址通過API Server存儲在Kubernetes的etcd中。

圖3 服務注冊技術架構圖

3 剝離業(yè)務邏輯獨立運維管理

改造項目將SpringCloud應用中業(yè)務功能與服務發(fā)現(xiàn)、負載均衡、熔斷限流、智能路由等運維功能分離開來，由服務網(wǎng)格Istio框架實現(xiàn)業(yè)務邏輯與運維功能間的剝離，在保持原有的應用管理功能上融合Istio服務網(wǎng)格能力。由Istio組件中的Adapter實現(xiàn)與Kubernetes引擎的融合，有效調用容器編排相關的功能，完成對Kubernetes引擎提供服務治理能力的調用。

通過把服務治理功能從整體項目中獨立出來，將服務治理功能提到微服務底層部署端，在微服務部署端以獨立部署的方式，實現(xiàn)了去中心化，實現(xiàn)了服務治理功能的獨立，便利地完成服務管理和業(yè)務邏輯分開的迭代升級。同時服務網(wǎng)格架構將服務管理功能分離，大幅度的降低了對業(yè)務邏輯關聯(lián)度，實現(xiàn)了支持多技術語言的開發(fā)[4]。

3.1 服務發(fā)現(xiàn)功能

SpringCloud項目在改造后，通過結合Istio框架與spring-cloud-kubernetes框架，與微服務同節(jié)點獨立部署的服務代理調用kubernetes能力，通過API Server訪問etcd中內容實現(xiàn)。具體的服務發(fā)現(xiàn)功能由服務代理發(fā)起，調用應用控制面Pilot的接口，應用控制面Pilot中的adapter與Kubernetes里adapter相結合進行關聯(lián)通信，調用kube-apiserver，查找etcd中數(shù)據(jù)，發(fā)現(xiàn)kubernetes中服務與部署pod之間的對應關系并返回。Pilot將返回結果處理為服務代理Envoy可識別的轉發(fā)模型并下發(fā)到服務代理中，將kube-proxy的轉發(fā)功能由服務代理Envoy實現(xiàn)，完成服務發(fā)現(xiàn)功能，其架構如圖4所示。

圖4 服務發(fā)現(xiàn)技術架構圖

圖4中，一個應用服務在調用另一個應用服務時，首先代理調用應用控制面Pilot中的接口，Pilot調用kubenetes API Server的接口，最終查詢etcd中的服務相關的信息，將目的應用服務的相關信息返回至服務代理，服務代理向目標服務的多個Pod輪詢發(fā)起請求。具體流程如下。

1)ServiceA的服務代理訪問Pilot 的接口，發(fā)起服務訪問需求。

2)Pilot 的服務發(fā)現(xiàn)接口調用kubenetes API Server中的請求服務列表接口。

3)所有服務數(shù)據(jù)存儲在etcd中，由API Server調用，API Server的請求服務列表接口獲得數(shù)據(jù)庫中相關服務信息，最終獲取目標服務serviceB的實例列表。

4)ServiceA的 Envoy根據(jù)獲得的目標服務serviceB的實例列表，向ServiceB的多個Pod發(fā)起輪詢的訪問。

3.2 熔斷限流功能

Istio框架可以有效的實現(xiàn)當服務出現(xiàn)訪問異常情況時，對服務進行限制訪問流量操作或者將服務從負載均衡池中移除，以達到調用此服務或者多級調用此服務的服務能夠正常運行，防止出現(xiàn)系統(tǒng)癱瘓的現(xiàn)象[5]。主要通過熔斷限流規(guī)則的配置完成對應功能，包括異常點檢測規(guī)則和連接池配置規(guī)則。異常點檢測是指當某個服務實例不斷出錯或者超時響應時，對其進行切斷操作，防止對此服務實例進行多級調用者產(chǎn)生類似“雪崩”效應。連接池配置規(guī)則包括對服務提供者進行連接的數(shù)量、請求數(shù)、出錯后的允許重試的次數(shù)等，通過這些參數(shù)的設置，達到超過預設的訪問數(shù)量則斷開連接和限定重新連接的次數(shù)的效果，防止出現(xiàn)訪問數(shù)量劇增系統(tǒng)癱瘓的問題，實現(xiàn)系統(tǒng)的高可靠性。具體的步驟如下。

在應用控制面：

1)管理員通過命令行或接口創(chuàng)建熔斷限流的規(guī)則，包括基于連接池大小、連接請求數(shù)量和異常值參數(shù)，在DestinationRule中設置TrafficPolicy參數(shù)，連接池限流方式為ConnectionPool參數(shù)，異常檢測熔斷方式為OutlierDetection參數(shù)；

2)Pilot組件將熔斷限流規(guī)則進行轉換，轉換為代理Envoy可以識別的格式；

3)Polot組件將轉換后的規(guī)則下發(fā)給代理Envoy。

在應用數(shù)據(jù)面：

Envoy接收Polit的熔斷限流設置規(guī)則后，轉換為Cluster的配置對象，每個代理Envoy之間根據(jù)Cluster的配置信息進行通訊。配置規(guī)則中有具體的負載均衡池的設定、連接池和滿足故障檢測情況的參數(shù)。若滿足配置中的情況，則將有問題的服務實例撤離出負載均衡池，通過優(yōu)化負載均衡的方法啟動熔斷機制。

3.3 智能路由功能

請求路由可以根據(jù)不同需求，如按照百分比或按照請求內容等，將請求路由至不同的版本，將請求的訪問分配到對應的版本上[6]，具體步驟如下。

1)首先完成Pilot中的路由分配規(guī)則設置，包括流量與故障相關的配置。路由的請求設置由VirtualService中參數(shù)實現(xiàn)，完成路由轉發(fā)后對其他服務的訪問規(guī)則由DestinationRule設置，包括服務輪詢規(guī)則方法、連接配置和異常檢測等參數(shù)。

2)流量導向規(guī)則在Polit中改變成代理Envoy可辨別的形式，轉變后發(fā)送給Envoy。

3)Envoy首先從Pilot接收到路由規(guī)則，與此同時定期進行異常檢索并將檢索結果與當前運行情況發(fā)送給所有其他的代理。Envoy根據(jù)路由規(guī)則即負載均衡與系統(tǒng)中所有代理的異常檢索結果、當前運行結果，對流量進行分配，完成智能路由的功能[7]。

智能路由實現(xiàn)了pod訪問量均衡分配的效果，由Envoy按照配置與其他代理運行情況完成了流量的分配。如圖5所示，Polit設置了路由規(guī)則，ServiceB與ServiceB1訪問流量分配比例為4:1，ServiceA的服務代理Envoy接收了路由設置規(guī)則后，當外部訪問ServiceA時，其服務代理Envoy將訪問流量進行分配，80%的流量訪問ServiceB，其余的流量分配給ServiceB1。

圖5 服務智能路由

3.4 灰度發(fā)布

在項目迭代升級時，為防止項目整體上線時項目使用效果不佳，將少量的生產(chǎn)環(huán)境的流量分配到最新項目版本中，其余流量則留在原版本中，測試更新項目使用情況，是否存在問題，沒有問題后進而不斷增加新版本的流量使用占比，最終完成整體上線，通過此方法漸變、嘗試地完成項目版本的更新，保證項目使用效果[8]。

基于Spring-Cloud環(huán)境開發(fā)的微服務運行于Kubernetes的pod中，istio適配器與K8s控制節(jié)點相結合，使得與K8s有效融合，項目開發(fā)人員對路由策略進行配置進而完成灰度版本控制。其策略靈活的制定與對流量的管理有效實現(xiàn)了灰度發(fā)布，同時達到新老版本同時存在，且對不同版本敏捷的進行訪問流量配置的效果。

首先在應用控制層Polit中完成訪問流量配置的設置，所有代理Envoy接收對應的配置規(guī)則，每個代理在對目標服務進行訪問前，都需要按照流量配置的規(guī)則進行流量分發(fā)，達到版本迭代灰度發(fā)布的效果[9]。

灰度發(fā)布有多種規(guī)則，大多數(shù)以訪問流量比例為主，除此之外，還可以對訪問內容進行控制，包括服務請求方的操作系統(tǒng)、訪問時使用的瀏覽器和請求頭等。如圖6所示，為基于流量比例進行分配的服務灰度發(fā)布。

圖6 服務灰度發(fā)布

1)Pilot中設置灰度發(fā)布規(guī)則，為訪問serviceC的v1版本設置70%的流量，訪問serviceC的v2版本設置為30%的流量。Pilot將規(guī)則下發(fā)至各個服務代理Envoy中。

2)各微服務的代理Envoy接收到灰度發(fā)布的規(guī)則。

3)Spring-cloud serviceA調用Spring-cloud serviceC服務時，serviceA的Envoy設置分流，將流量的70%分發(fā)給serviceC的V1版本，將流量的30%分發(fā)給serviceC的V 2 版本。當S p r i n g-c l o u d serviceB服務調用Spring-cloud serviceC服務時，serviceB的服務代理同樣按照灰度發(fā)布的規(guī)則進行分發(fā)流量。

3.5 其他運維功能

基于istio框架改造的微服務項目，除了提供服務發(fā)現(xiàn)、熔斷限流、智能路由功能外，也能敏捷地完成鏈路監(jiān)控、安全策略、性能監(jiān)控等服務治理功能。改造后的微服務項目可以更好的實現(xiàn)復雜業(yè)務功能，通過istio非侵入性的配置，代理基于配置進行流量管理來完成各項運維功能，并將運維功能有效的融合到業(yè)務系統(tǒng)中[10]。

4 結束語

基于服務網(wǎng)格的微服務項目改造，是通過應用容器編排技術與服務網(wǎng)格技術等，解決實際原項目中面臨的隨著業(yè)務量增加而增加的大量細粒度微服務的部署、運維和治理難題，解決因業(yè)務邏輯與服務管理功能緊密結合導致的局部修改升級需要整體更新升級的問題。此項目改造實現(xiàn)了以下四個創(chuàng)新點。

1)在業(yè)務應用方面，原項目包含了業(yè)務邏輯與服務發(fā)現(xiàn)、負載均衡、熔斷限流和智能路由等運維功能，所有代碼聯(lián)系緊密。改造后項目將業(yè)務邏輯抽離出來，包裝為細粒度的多個微服務。

2)利用服務網(wǎng)格技術實現(xiàn)服務治理功能，并將服務治理功能與業(yè)務層進行有效性結合，實現(xiàn)業(yè)務邏輯與服務管理的剝離。服務治理實現(xiàn)方式簡單，規(guī)則設置方式敏捷。服務治理功能部署在底層，減少了對業(yè)務代碼的關聯(lián)，使得開發(fā)周期短，測試與運維簡易執(zhí)行，彌補了原項目業(yè)務與運維功能結合緊密、開發(fā)效率低、測試難度大的一系列問題，進一步提高業(yè)務快速迭代升級效率。

3)容器編排包含自動化部署、擴縮容、狀態(tài)監(jiān)控、故障遷移、資源調度、資源隔離、容器運維等功能，同時服務網(wǎng)格技術實現(xiàn)的服務治理功能與此底層平臺能夠進行有效性的融合，減少服務治理與容器編排底層路徑重復的問題，提高了服務治理的精確度與速度。

4)在與業(yè)務側的關系方面，原項目以lib包嵌入到業(yè)務代碼中，改造后項目為邊車模式，與業(yè)務松耦合。在語言壁壘方面，改造前的項目只允許Java語言發(fā)開，改造后項目無語言壁壘。