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

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

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

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

sito服務網(wǎng)格的架構

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

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

下圖顯示了構成每個面板的不同組件：

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

Istio的安裝，啟動和驗證：

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

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

【運行命令】：kubectl apply -f install/kubernetes/istio-auth.yaml

不啟用雙向認證：

【運行命令】：kubectl apply -f install/kubernetes/istio.yaml

         5. 安裝驗證

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

【運行命令】：kubectl get svc -n istio-system

確認一下對應的pod 已成功部署并且所有的容器都啟動并運行：

【運行命令】：kubectl get pods -n istio-system

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

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

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

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

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

雖然istio 降低了應用服務與服務治理之間的耦合度，讓用戶能夠將主要精力放在具體的業(yè)務功能實現(xiàn)上，而不需要過多的考慮服務治理(如流量控制、負載均衡、故障處理等)方面的問題，提高了開發(fā)效率，并且Istio通過高度的抽象和良好的設計采用一致的方式解決了灰度發(fā)布的問題，通過Pilot下發(fā)路由，然后Envoy對流量進行了轉發(fā)，極大的提高了運維的生產性。

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

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

Isito服務網(wǎng)格的引進

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

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

【參考文獻】

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

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

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