蘇寧微服務治理架構Istio的通信和治理之道
原創【51CTO.com原創稿件】伴隨著互聯網技術的不斷發展，各大互聯網公司的系統越來越復雜，傳統的系統架構越來越不能滿足業務的需求，取而代之的是微服務架構。目前比較流行的微服務架構有阿里的Dubbo，Spring Cloud，還有蘇寧的RSF框架。
雖然上述的技術比較成熟，并且都能夠很好的治理微服務系統，但是使用以上框架管理微服務時，需要在業務代碼中添加微服務治理相關的代碼，導致了業務人員不能專注于業務開發，還需要考慮微服務治理的解決方案，并且將解決方案融合到其業務系統中。并且伴隨著微服務治理解決方案的升級，也需要修改相關的業務代碼，會增加相關業務開發人員的工作量。
為了解決上述的問題，Buoyant公司提出了Service Mesh(服務網格)的概念。并且于2016 年 1 月 15 日***發布，業界***個 Service Mesh 項目(Linkerd)。Service Mesh是一個在服務和基礎網絡之間的專用基礎設施層。它可以讓業務系統完全不用關心微服務的治理，只需要專注于自身的業務邏輯。
伴隨著Service Mesh技術不斷發展，越來越多的Service Mesh產品不斷的涌現出來，在所有的Service Mesh產品中，Google/IBM 聯合開發的開源項目Istio是***秀的Service Mesh產品。接入Istio服務網格之后，現有的業務系統在不需要改變任何代碼的情況下，將具備流量管理，路由控制，服務降級等功能。
sito服務網格的架構
stio服務網格邏輯上分為數據面板和控制面板。
- 數據面板由一組智能代理(Envoy)組成，并且作為邊車(sidecar)進行部署，調解和控制微服務之間的網絡通信。
- 控制面板負責管理和配置代理來路由流量。此外，控制面板配置Mixers來執行策略和收集數據。
下圖顯示了構成每個面板的不同組件：
- Pilot為Envoy sidecars提供服務發現能力，并且為智能路由提供路由管理能力。Pilot可以將路由規則下發到各個Envoy sidecars中，從而通過Envoy sidecars控制系統路由。并且，Pilot公開了用于服務發現、負載均衡池和路由表的動態更新的 API。這些API將Envoy從平臺特有的細微差別中解脫出來，簡化了設計并提升了跨平臺的可移植性。
- Mixer負責在服務網格上執行訪問控制和使用策略，并從Envoy代理和其他服務收集遙測數據。代理提取請求級屬性，發送到Mixer進行評估。Mixer包含一個靈活的插件模型，使Istio能夠接入到各種主機環境和基礎設施后端，從這些細節中抽象出Envoy代理和Istio管理的服務。
- Citadel通過內置身份和證書管理，提供強大的服務間認證和終端用戶認證。通過Citadel可以升級服務網格中的未加密流量，并為運維人員提供基于服務身份而不是網絡控制來強制執行策略的能力。
- Istio使用Envoy代理的擴展版本，Envoy是用C++開發的高性能代理，在服務網格中控制所有服務的入站和出站流量。Istio利用了Envoy的許多內置功能：
- 動態服務發現
- 負載均衡
- TLS終止
- HTTP/2和gRPC代理
- 熔斷器
- 健康檢查
- 基于百分比流量拆分
- 故障注入
- 豐富指標
Istio的安裝，啟動和驗證：
- 下載***的Istio安裝文件，并且解壓。
- 在環境變量PATH中追加，Istio的運行路徑。
- 確保所需的鏡像已經下載并部署在集群中的機器上，同時安裝前需要保證機器已經安裝好Docker 環境。并且保證部署文件istio.yaml 或istio-auth.yaml 中的鏡像名和下載的鏡像一致。
- 通過以下兩種方式中任意一種方式啟動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服務網格的優勢
伴隨著微服務不斷的發展，Istio服務網格的使用場景越來越多，通過Istio服務網格的接入，解決了下述各種問題。
- 隨著公司業務的不斷發展，公司內部原有大量的Web應用，在不想改造代碼的前提下，想加入服務化大家庭，享受各種服務治理的能力。
- 隨著新技術的不斷涌現，加上公司業務的快速發展，公司內部不同的業務系統會根據不同的場景選擇不同的語言進行業務開發，例如Node.js, Go等等。不同的語言都需要接入服務化大家庭，享受各種服務治理的能力。
- 隨著業務的發展，微服務架構必然需要不斷的升級，基于Istio架構的微服務，業務系統和微服務架構是解耦的，所以在微服務架構升級時，業務部門不需要做任何修正，從而減輕了業務部門的工作量。
- Istio在Pilot配置路由規則，然后將路由規則下發至Envoy，Envoy根據路由規則，可以在不修改應用程序的前提下實現應用的灰度發布，熔斷，擴縮容，注入故障等功能。從而減輕了開發和運維的工作量。
- Istio通過Mixer的配置，可以在不修改應用的前提下，為服務添加白名單，ACL的檢查，從而控制服務的訪問。
- Istio的Citadel通過內置身份和證書管理，來保護服務之間的所有通信安全性，而不會對開發人員造成麻煩的證書管理負擔。
Istio服務網格作為一個基礎設施層，將微服務的治理完全從業務系統中獨立出來了，業務開發人員從此可以完全的專注于業務系統的開發，不需要考慮微服務治理等方面的問題，極大的提高了業務開發人員的生產效率。同時由于Istio作為一個基礎設施層，輕量級高性能網絡代理，對應用透明，運維人員可以依靠統一的規則進行維護，從而也極大的提高了運維人員的生產效率。同時也降低了業務開發人員與運維人員的溝通成本。
Isito服務網格的不足
雖然istio 降低了應用服務與服務治理之間的耦合度，讓用戶能夠將主要精力放在具體的業務功能實現上，而不需要過多的考慮服務治理(如流量控制、負載均衡、故障處理等)方面的問題，提高了開發效率，并且Istio通過高度的抽象和良好的設計采用一致的方式解決了灰度發布的問題，通過Pilot下發路由，然后Envoy對流量進行了轉發，極大的提高了運維的生產性。
但是Istio還是存在一個極大的痛點，即高并發訪問時吞吐量不能夠達到蘇寧大促的需求。利用上圖的模型對Istio進行了壓力測試，來驗證Istio的吞吐量和穩定性。在高并發的情況下Istio頂住了壓力，***的保證了訪問的正確性，沒有發生任何丟包，請求失敗，路由混亂的錯誤。
但是Istio吞吐量并不是很理想，服務間以HTTP 方式訪問時吞吐量尤其低下，服務間以GRPC 方式訪問時性能雖有提升，但是還是不能夠完全滿足蘇寧大促期間的高并發量的要求。Istio 在微服務治理方面所展現的功能特性和靈活性使得Istio的魅力格外亮眼，目前Istio也是開源社區活躍性居于前列的開源項目，蘇寧也會繼續為Istio的發展貢獻一份力量。相信在不久的將來，Istio 在吞吐量上的痛點能夠得到突破，達到蘇寧大促的需求。
Isito服務網格的引進
目前蘇寧為了適應新技術的發展和提高資源的利用率，正在大力推進公司內部的系統從虛擬機向Kubernetes + Docker的架構化轉換。通過Kubernetes + Docker的引入，為Istio提供了所需的基礎架構。
因此我們將以此為契機加快在蘇寧內部推進Istio系統，先在非大促的系統中進行推廣，在社區和我們共同努力下，當性能能夠滿足大促需求時，再將Istio系統推廣到大促系統，從而將全公司全部的系統都納入到Istio的管理中。通過Istio的接入，集團內部的所有服務在不需要做任何修改的前提下，可以享受各種服務治理的能力。并且通過Istio的推進，在提高集團的開發運維效率的同時，降低了業務上線時發生錯誤的概率。
【參考文獻】
[1] https://istio.io/docs/reference/
作者：林正國，蘇寧易購IT總部數據云公司中間件研發中心高級技術經理，一直從事基礎中間件的研發工作，擁有著10余年的中間件研發經驗。目前主要負責蘇寧基礎中間件的開發和維護。深知基礎中間件的穩定對電商平臺的重要性，正在為不斷提升蘇寧中間件的穩定性和高效性而奮斗。
【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】
