【51CTO.com原創(chuàng)稿件】伴隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，各大互聯(lián)網(wǎng)公司的系統(tǒng)越來越復(fù)雜，傳統(tǒng)的系統(tǒng)架構(gòu)越來越不能滿足業(yè)務(wù)的需求，取而代之的是微服務(wù)架構(gòu)。目前比較流行的微服務(wù)架構(gòu)有阿里的Dubbo，Spring Cloud，還有蘇寧的RSF框架。

雖然上述的技術(shù)比較成熟，并且都能夠很好的治理微服務(wù)系統(tǒng)，但是使用以上框架管理微服務(wù)時(shí)，需要在業(yè)務(wù)代碼中添加微服務(wù)治理相關(guān)的代碼，導(dǎo)致了業(yè)務(wù)人員不能專注于業(yè)務(wù)開發(fā)，還需要考慮微服務(wù)治理的解決方案，并且將解決方案融合到其業(yè)務(wù)系統(tǒng)中。并且伴隨著微服務(wù)治理解決方案的升級，也需要修改相關(guān)的業(yè)務(wù)代碼，會(huì)增加相關(guān)業(yè)務(wù)開發(fā)人員的工作量。

為了解決上述的問題，Buoyant公司提出了Service Mesh(服務(wù)網(wǎng)格)的概念。并且于2016 年 1 月 15 日***發(fā)布，業(yè)界***個(gè) Service Mesh 項(xiàng)目(Linkerd)。Service Mesh是一個(gè)在服務(wù)和基礎(chǔ)網(wǎng)絡(luò)之間的專用基礎(chǔ)設(shè)施層。它可以讓業(yè)務(wù)系統(tǒng)完全不用關(guān)心微服務(wù)的治理，只需要專注于自身的業(yè)務(wù)邏輯。

伴隨著Service Mesh技術(shù)不斷發(fā)展，越來越多的Service Mesh產(chǎn)品不斷的涌現(xiàn)出來，在所有的Service Mesh產(chǎn)品中，Google/IBM 聯(lián)合開發(fā)的開源項(xiàng)目Istio是***秀的Service Mesh產(chǎn)品。接入Istio服務(wù)網(wǎng)格之后，現(xiàn)有的業(yè)務(wù)系統(tǒng)在不需要改變?nèi)魏未a的情況下，將具備流量管理，路由控制，服務(wù)降級等功能。

sito服務(wù)網(wǎng)格的架構(gòu)

stio服務(wù)網(wǎng)格邏輯上分為數(shù)據(jù)面板和控制面板。

• 數(shù)據(jù)面板由一組智能代理(Envoy)組成，并且作為邊車(sidecar)進(jìn)行部署，調(diào)解和控制微服務(wù)之間的網(wǎng)絡(luò)通信。
• 控制面板負(fù)責(zé)管理和配置代理來路由流量。此外，控制面板配置Mixers來執(zhí)行策略和收集數(shù)據(jù)。

下圖顯示了構(gòu)成每個(gè)面板的不同組件：

• Pilot為Envoy sidecars提供服務(wù)發(fā)現(xiàn)能力，并且為智能路由提供路由管理能力。Pilot可以將路由規(guī)則下發(fā)到各個(gè)Envoy sidecars中，從而通過Envoy sidecars控制系統(tǒng)路由。并且，Pilot公開了用于服務(wù)發(fā)現(xiàn)、負(fù)載均衡池和路由表的動(dòng)態(tài)更新的 API。這些API將Envoy從平臺特有的細(xì)微差別中解脫出來，簡化了設(shè)計(jì)并提升了跨平臺的可移植性。
• Mixer負(fù)責(zé)在服務(wù)網(wǎng)格上執(zhí)行訪問控制和使用策略，并從Envoy代理和其他服務(wù)收集遙測數(shù)據(jù)。代理提取請求級屬性，發(fā)送到Mixer進(jìn)行評估。Mixer包含一個(gè)靈活的插件模型，使Istio能夠接入到各種主機(jī)環(huán)境和基礎(chǔ)設(shè)施后端，從這些細(xì)節(jié)中抽象出Envoy代理和Istio管理的服務(wù)。
• Citadel通過內(nèi)置身份和證書管理，提供強(qiáng)大的服務(wù)間認(rèn)證和終端用戶認(rèn)證。通過Citadel可以升級服務(wù)網(wǎng)格中的未加密流量，并為運(yùn)維人員提供基于服務(wù)身份而不是網(wǎng)絡(luò)控制來強(qiáng)制執(zhí)行策略的能力。
• Istio使用Envoy代理的擴(kuò)展版本，Envoy是用C++開發(fā)的高性能代理，在服務(wù)網(wǎng)格中控制所有服務(wù)的入站和出站流量。Istio利用了Envoy的許多內(nèi)置功能：
  • 動(dòng)態(tài)服務(wù)發(fā)現(xiàn)
  • 負(fù)載均衡
  • TLS終止
  • HTTP/2和gRPC代理
  • 熔斷器
  • 健康檢查
  • 基于百分比流量拆分
  • 故障注入
  • 豐富指標(biāo)

Istio的安裝，啟動(dòng)和驗(yàn)證：

1. 下載***的Istio安裝文件，并且解壓。
2. 在環(huán)境變量PATH中追加，Istio的運(yùn)行路徑。
3. 確保所需的鏡像已經(jīng)下載并部署在集群中的機(jī)器上，同時(shí)安裝前需要保證機(jī)器已經(jīng)安裝好Docker 環(huán)境。并且保證部署文件istio.yaml 或istio-auth.yaml 中的鏡像名和下載的鏡像一致。
4. 通過以下兩種方式中任意一種方式啟動(dòng)istio。

啟用sidecar 之間的TLS 雙向認(rèn)證(我們采用這種方式)：

【運(yùn)行命令】：kubectl apply -f install/kubernetes/istio-auth.yaml

不啟用雙向認(rèn)證：

【運(yùn)行命令】：kubectl apply -f install/kubernetes/istio.yaml

         5. 安裝驗(yàn)證

istio 啟動(dòng)成功后，其基本服務(wù)組件啟動(dòng)，包括istio-ingress、istio-mixer 和istio-pilot，查看一下已啟動(dòng)的istio 服務(wù)：

【運(yùn)行命令】：kubectl get svc -n istio-system

確認(rèn)一下對應(yīng)的pod 已成功部署并且所有的容器都啟動(dòng)并運(yùn)行：

【運(yùn)行命令】：kubectl get pods -n istio-system

Isito服務(wù)網(wǎng)格的優(yōu)勢

伴隨著微服務(wù)不斷的發(fā)展，Istio服務(wù)網(wǎng)格的使用場景越來越多，通過Istio服務(wù)網(wǎng)格的接入，解決了下述各種問題。

1. 隨著公司業(yè)務(wù)的不斷發(fā)展，公司內(nèi)部原有大量的Web應(yīng)用，在不想改造代碼的前提下，想加入服務(wù)化大家庭，享受各種服務(wù)治理的能力。
2.  隨著新技術(shù)的不斷涌現(xiàn)，加上公司業(yè)務(wù)的快速發(fā)展，公司內(nèi)部不同的業(yè)務(wù)系統(tǒng)會(huì)根據(jù)不同的場景選擇不同的語言進(jìn)行業(yè)務(wù)開發(fā)，例如Node.js, Go等等。不同的語言都需要接入服務(wù)化大家庭，享受各種服務(wù)治理的能力。
3. 隨著業(yè)務(wù)的發(fā)展，微服務(wù)架構(gòu)必然需要不斷的升級，基于Istio架構(gòu)的微服務(wù)，業(yè)務(wù)系統(tǒng)和微服務(wù)架構(gòu)是解耦的，所以在微服務(wù)架構(gòu)升級時(shí)，業(yè)務(wù)部門不需要做任何修正，從而減輕了業(yè)務(wù)部門的工作量。
4. Istio在Pilot配置路由規(guī)則，然后將路由規(guī)則下發(fā)至Envoy，Envoy根據(jù)路由規(guī)則，可以在不修改應(yīng)用程序的前提下實(shí)現(xiàn)應(yīng)用的灰度發(fā)布，熔斷，擴(kuò)縮容，注入故障等功能。從而減輕了開發(fā)和運(yùn)維的工作量。
5. Istio通過Mixer的配置，可以在不修改應(yīng)用的前提下，為服務(wù)添加白名單，ACL的檢查，從而控制服務(wù)的訪問。
6. Istio的Citadel通過內(nèi)置身份和證書管理，來保護(hù)服務(wù)之間的所有通信安全性，而不會(huì)對開發(fā)人員造成麻煩的證書管理負(fù)擔(dān)。

Istio服務(wù)網(wǎng)格作為一個(gè)基礎(chǔ)設(shè)施層，將微服務(wù)的治理完全從業(yè)務(wù)系統(tǒng)中獨(dú)立出來了，業(yè)務(wù)開發(fā)人員從此可以完全的專注于業(yè)務(wù)系統(tǒng)的開發(fā)，不需要考慮微服務(wù)治理等方面的問題，極大的提高了業(yè)務(wù)開發(fā)人員的生產(chǎn)效率。同時(shí)由于Istio作為一個(gè)基礎(chǔ)設(shè)施層，輕量級高性能網(wǎng)絡(luò)代理，對應(yīng)用透明，運(yùn)維人員可以依靠統(tǒng)一的規(guī)則進(jìn)行維護(hù)，從而也極大的提高了運(yùn)維人員的生產(chǎn)效率。同時(shí)也降低了業(yè)務(wù)開發(fā)人員與運(yùn)維人員的溝通成本。

Isito服務(wù)網(wǎng)格的不足

雖然istio 降低了應(yīng)用服務(wù)與服務(wù)治理之間的耦合度，讓用戶能夠?qū)⒅饕Ψ旁诰唧w的業(yè)務(wù)功能實(shí)現(xiàn)上，而不需要過多的考慮服務(wù)治理(如流量控制、負(fù)載均衡、故障處理等)方面的問題，提高了開發(fā)效率，并且Istio通過高度的抽象和良好的設(shè)計(jì)采用一致的方式解決了灰度發(fā)布的問題，通過Pilot下發(fā)路由，然后Envoy對流量進(jìn)行了轉(zhuǎn)發(fā)，極大的提高了運(yùn)維的生產(chǎn)性。

但是Istio還是存在一個(gè)極大的痛點(diǎn)，即高并發(fā)訪問時(shí)吞吐量不能夠達(dá)到蘇寧大促的需求。利用上圖的模型對Istio進(jìn)行了壓力測試，來驗(yàn)證Istio的吞吐量和穩(wěn)定性。在高并發(fā)的情況下Istio頂住了壓力，***的保證了訪問的正確性，沒有發(fā)生任何丟包，請求失敗，路由混亂的錯(cuò)誤。

但是Istio吞吐量并不是很理想，服務(wù)間以HTTP 方式訪問時(shí)吞吐量尤其低下，服務(wù)間以GRPC 方式訪問時(shí)性能雖有提升，但是還是不能夠完全滿足蘇寧大促期間的高并發(fā)量的要求。Istio 在微服務(wù)治理方面所展現(xiàn)的功能特性和靈活性使得Istio的魅力格外亮眼，目前Istio也是開源社區(qū)活躍性居于前列的開源項(xiàng)目，蘇寧也會(huì)繼續(xù)為Istio的發(fā)展貢獻(xiàn)一份力量。相信在不久的將來，Istio 在吞吐量上的痛點(diǎn)能夠得到突破，達(dá)到蘇寧大促的需求。

Isito服務(wù)網(wǎng)格的引進(jìn)

目前蘇寧為了適應(yīng)新技術(shù)的發(fā)展和提高資源的利用率，正在大力推進(jìn)公司內(nèi)部的系統(tǒng)從虛擬機(jī)向Kubernetes + Docker的架構(gòu)化轉(zhuǎn)換。通過Kubernetes + Docker的引入，為Istio提供了所需的基礎(chǔ)架構(gòu)。

因此我們將以此為契機(jī)加快在蘇寧內(nèi)部推進(jìn)Istio系統(tǒng)，先在非大促的系統(tǒng)中進(jìn)行推廣，在社區(qū)和我們共同努力下，當(dāng)性能能夠滿足大促需求時(shí)，再將Istio系統(tǒng)推廣到大促系統(tǒng)，從而將全公司全部的系統(tǒng)都納入到Istio的管理中。通過Istio的接入，集團(tuán)內(nèi)部的所有服務(wù)在不需要做任何修改的前提下，可以享受各種服務(wù)治理的能力。并且通過Istio的推進(jìn)，在提高集團(tuán)的開發(fā)運(yùn)維效率的同時(shí)，降低了業(yè)務(wù)上線時(shí)發(fā)生錯(cuò)誤的概率。

【參考文獻(xiàn)】

[1] https://istio.io/docs/reference/

作者：林正國，蘇寧易購IT總部數(shù)據(jù)云公司中間件研發(fā)中心高級技術(shù)經(jīng)理，一直從事基礎(chǔ)中間件的研發(fā)工作，擁有著10余年的中間件研發(fā)經(jīng)驗(yàn)。目前主要負(fù)責(zé)蘇寧基礎(chǔ)中間件的開發(fā)和維護(hù)。深知基礎(chǔ)中間件的穩(wěn)定對電商平臺的重要性，正在為不斷提升蘇寧中間件的穩(wěn)定性和高效性而奮斗。 

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】