服務(wù)網(wǎng)格和Istio初識(shí)-續(xù)

目錄

• 1、服務(wù)治理的三種形態(tài)

• 2、服務(wù)網(wǎng)格的特點(diǎn)

• 3、網(wǎng)格帶來的損耗

• 4、為什么服務(wù)網(wǎng)格選擇 Istio

• 5、Istio 與 kubernetes

• 6、微服務(wù)和 Istio 的選擇側(cè)重

• 7、Istio 的侵入性

• 8、Istio 用在哪

• 9、Istio 做了什么

• 10、用什么姿勢(shì)接入 Istio

• 11、Istio 不是銀彈

本文是服務(wù)網(wǎng)格和 Istio 初識(shí)的續(xù)篇內(nèi)容，主要是漫談(記錄)一些關(guān)于服務(wù)網(wǎng)格、Istio的一些理論及個(gè)人認(rèn)知

“

為什么還要寫這類看似枯燥的文章？我始終認(rèn)為，學(xué)習(xí)和實(shí)踐應(yīng)用一門新技術(shù)之前，應(yīng)該做好多方調(diào)研，全局認(rèn)知，當(dāng)前有什么痛點(diǎn)能解決而不是有哪些功能能拿來用等等，到最后不至于僅僅是用了起來而已

”

1、服務(wù)治理的三種形態(tài)

服務(wù)治理的發(fā)展經(jīng)過了以下三種形態(tài)的演進(jìn)

• 應(yīng)用程序中包含治理邏輯（代碼自行實(shí)現(xiàn)，復(fù)用性很低）
• 治理邏輯獨(dú)立的代碼（sdk方式，提高復(fù)用性，但避免不了的是要應(yīng)用一起打包部署）
• 治理邏輯獨(dú)立的進(jìn)程（sidecar模式，對(duì)應(yīng)用無感知，解耦合）

2、服務(wù)網(wǎng)格的特點(diǎn)

• 基礎(chǔ)設(shè)施：服務(wù)網(wǎng)格是一種處理服務(wù)間通信的基礎(chǔ)設(shè)施層
• 云原生：服務(wù)網(wǎng)格尤其適用于在云原生場(chǎng)景下幫助應(yīng)用程序在復(fù)雜的服務(wù)拓?fù)溟g可靠地傳遞請(qǐng)求
• 網(wǎng)絡(luò)代理：在實(shí)際使用中，服務(wù)網(wǎng)格一般是通過一組輕量級(jí)網(wǎng)絡(luò)代理來執(zhí)行治理邏輯的
• 對(duì)應(yīng)用透明：輕量網(wǎng)絡(luò)代理與應(yīng)用程序部署在一起，但應(yīng)用感知不到代理的存在，還是使用原來的方式工作

3、網(wǎng)格帶來的損耗

傳統(tǒng)環(huán)境下，服務(wù)A到服務(wù)B可以直接通過網(wǎng)絡(luò)（ip或服務(wù)名）直連

用了網(wǎng)格后，從A服務(wù)到B服務(wù)的一個(gè)訪問必須要經(jīng)過A服務(wù)的Sidecar攔截Outbound流量執(zhí)行治理動(dòng)作；再經(jīng)過B服務(wù)的Sidecar攔截Inbound流量，執(zhí)行治理動(dòng)作。這就引入兩個(gè)問題：

• 增加了兩處延遲和可能的故障點(diǎn)
• 多出來的這兩跳對(duì)于訪問性能、整體可靠性及整個(gè)系統(tǒng)的復(fù)雜度都帶來了新的挑戰(zhàn)

通過保證轉(zhuǎn)發(fā)代理的輕量和高性能降低時(shí)延影響，尤其是考慮到后端實(shí)際使用的應(yīng)用程序一般比代理更重，疊加代理并不會(huì)明顯影響應(yīng)用的訪問性能；另外，對(duì)于這些高性能的代理，只要消耗足夠的資源總能達(dá)到期望的性能， 特別是云原生場(chǎng)景下服務(wù)的彈性特點(diǎn)使得服務(wù)實(shí)例的彈性擴(kuò)展變得非常方便，通過擴(kuò)展實(shí)例數(shù)量總是能得到期望的訪問性能

因此最終需要決策的是：是否愿意花費(fèi)額外的少量資源在這些基礎(chǔ)設(shè)施上來換取開發(fā)、運(yùn)維的靈活性、業(yè)務(wù)的非侵入性和擴(kuò)展性等便利？

4、為什么服務(wù)網(wǎng)格選擇 Istio

• 控制面設(shè)計(jì)

Istio作為一種全新的設(shè)計(jì)，在功能、形態(tài)、架構(gòu)和擴(kuò)展性上提供了遠(yuǎn)超服務(wù)網(wǎng)格的能力范圍。它基于xDS協(xié)議提供了一套標(biāo)準(zhǔn)的控制面規(guī)范，向數(shù)據(jù)面?zhèn)鬟f服務(wù)信息和治理規(guī)則。Istio的早期版本使用Envoy V1版本的API，即Restful方式，其新版本使用Envoy V2版本的API，即gRPC協(xié)議。標(biāo)準(zhǔn)的控制面API解耦了控制面和數(shù)據(jù)面的綁定。Nginx的nginMesh、F5 Networks的Aspen Mesh等多種數(shù)據(jù)面代理支持Istio的控制面，甚至有些老牌微服務(wù)SDK也開始往Istio上集成

• 數(shù)據(jù)面設(shè)計(jì)

Istio的標(biāo)準(zhǔn)數(shù)據(jù)面Envoy是由Lyft內(nèi)部于2016年開發(fā)的，比Linkerd更早。2016年9月，Envoy開源并發(fā)布了1.0.0版本；2017年9月，Envoy加入CNCF，成為第2個(gè)Service Mesh項(xiàng)目；2018年11月，Envoy從CNCF畢業(yè)，這標(biāo)志著其趨于成熟。從開發(fā)語言上看，Envoy是使用C++開發(fā)的，其性能和資源占用比用Rust開發(fā)的Linkerd Proxy要更好，更能滿足服務(wù)網(wǎng)格中對(duì)透明代理的輕量高性能要求；從能力上看，Envoy提供L3/L4過濾器、HTTP L7過濾器，支持HTTP/2、HTTP L7路由及gRPC、MongoDB、DynamoDB等協(xié)議，有服務(wù)發(fā)現(xiàn)、健康檢查、高級(jí)LB、前端代理等能力，具有極好的 可觀察性、動(dòng)態(tài)配置功能；從架構(gòu)實(shí)現(xiàn)上看，Envoy是一個(gè)可高度定制化的程序，通過Filter機(jī)制提供了 高度擴(kuò)展性，還支持熱重啟，其代碼基于模塊化編碼，易于測(cè)試。除了在Istio中應(yīng)用，Envoy在其他Service Mesh框架中也被廣泛應(yīng)用，漸漸成為Service Mesh的數(shù)據(jù)平面標(biāo)準(zhǔn)

• 大廠加持

Istio由谷歌和IBM共同推出，從應(yīng)用場(chǎng)景的分析規(guī)劃到本身的定位，從自身架構(gòu)的設(shè)計(jì)到與周邊生態(tài)的結(jié)合，都有著比較嚴(yán)密的論證。Istio項(xiàng)目在發(fā)起時(shí)已經(jīng)確認(rèn)了將云原生生態(tài)系統(tǒng)中的容器作為核心打包和運(yùn)行時(shí)，將Kubernetes作為管理容器的編排系統(tǒng)，需要一個(gè)系統(tǒng)管理在容器 平臺(tái)上運(yùn)行的服務(wù)之間的交互，包括控制訪問、安全、運(yùn)行數(shù)據(jù)收集等，而Istio正是為此而生的；另外，Istio成為架構(gòu)的默認(rèn)部分，就像容器和Kubernetes已經(jīng)成為云原生架構(gòu)的默認(rèn)部分一樣

另外一點(diǎn)，很多的公有云廠商在提供kubernetes容器服務(wù)時(shí)也內(nèi)置了Istio功能或者二次開發(fā)（包裝）了Istio，例如阿里云的asm

5、Istio 與 kubernetes

Istio和Kubernetes從設(shè)計(jì)理念、使用體驗(yàn)、系統(tǒng)架構(gòu)甚至代碼風(fēng)格等小細(xì)節(jié)來看，關(guān)系都非常緊密。更細(xì)粒度的 proxy 提供更多更細(xì)粒度的能力

Istio最大化地利用了Kubernetes這個(gè)基礎(chǔ)設(shè)施，與之疊加在一起形成了一個(gè)更強(qiáng)大的用于進(jìn)行服務(wù)運(yùn)行和治理的基礎(chǔ)設(shè)施，并提供了更透明的用戶體驗(yàn)。

• 數(shù)據(jù)面

數(shù)據(jù)面Sidecar運(yùn)行在Kubernetes的Pod里，作為一個(gè)Proxy和業(yè)務(wù)容器部署在一起。在服務(wù)網(wǎng)格的定義中要求應(yīng)用程序在運(yùn)行的時(shí)候感知不到Sidecar的存在。而基于Kubernetes的一個(gè)Pod多個(gè)容器的優(yōu)秀設(shè)計(jì)使得部署運(yùn)維對(duì)用戶透明，用戶甚至感知不到部署Sidecar的過程。用戶還是用原有的方式創(chuàng)建負(fù)載，通過Istio的自動(dòng)注入服務(wù)，可以自動(dòng)給指定的負(fù)載注入Proxy。如果在另一種環(huán)境下部署和使用Proxy，則不會(huì)有這樣的便利

• 統(tǒng)一服務(wù)發(fā)現(xiàn)

Istio的服務(wù)發(fā)現(xiàn)機(jī)制非常完美地基于Kubernetes的域名訪問機(jī)制構(gòu)建而成，省去了再搭一個(gè)類似Eureka的注冊(cè)中心的麻煩，更避免了在Kubernetes上運(yùn)行時(shí)服務(wù)發(fā)現(xiàn)數(shù)據(jù)不一致的問題

盡管Istio強(qiáng)調(diào)自己的可擴(kuò)展性的重要性在于適配各種不同的平臺(tái)，也可以對(duì)接其他服務(wù)發(fā)現(xiàn)機(jī)制，但在實(shí)際場(chǎng)景下，通過深入分析Istio幾個(gè)版本的代碼和設(shè)計(jì)，便可以發(fā)現(xiàn)其重要的能力都是基于Kubernetes進(jìn)行構(gòu)建的

• 基于Kubernetes CRD描述規(guī)則

Istio的所有路由規(guī)則和控制策略都是通過Kubernetes CRD實(shí)現(xiàn)的，因此各種規(guī)則策略對(duì)應(yīng)的數(shù)據(jù)也被存儲(chǔ)在kube-apiserver中，不需要另外一個(gè)單獨(dú)的APIServer和后端的配置管理。所以，可以說Istio的APIServer就是Kubernetes的APIServer，數(shù)據(jù)也自然地被存在了對(duì)應(yīng)Kubernetes的etcd中

Istio非常巧妙地應(yīng)用了Kubernetes這個(gè)好基座，基于Kubernetes的已有能力來構(gòu)建自身功能。Kubernetes里已經(jīng)有的，絕不再自己搞一套，避免了數(shù)據(jù)不一致和用戶使用體驗(yàn)的問題

Istio不僅數(shù)據(jù)面Envoy跑在Kubernetes的Pod里，其控制面也運(yùn)行在Kubernetes集群中，其控制面組件本身存在的形式也是Kubernetes Deployment和Service，基于Kubernetes擴(kuò)展和構(gòu)建

最后，看看微服務(wù)、容器、Kubernetes、Istio四者的關(guān)系

6、微服務(wù)和 Istio 的選擇側(cè)重

微服務(wù)是架構(gòu)風(fēng)格、方法論，Istio是一套完整的實(shí)踐

但是，回到我在本文開頭提到的一點(diǎn)觀念，Istio是用來解決問題的，并不是微服務(wù)理論的一種落地，在實(shí)際項(xiàng)目中拿著微服務(wù)的細(xì)節(jié)列表來硬套Istio的功能，比如要求Istio治理的服務(wù)必須實(shí)現(xiàn)微服務(wù)的服務(wù)注冊(cè)的一些細(xì)節(jié)，就明顯不太適當(dāng)

7、Istio 的侵入性

從單個(gè)應(yīng)用來看，Sidecar與應(yīng)用進(jìn)程的解耦帶來的應(yīng)用完全無侵入、開發(fā)語言無關(guān)等特點(diǎn)解除了開發(fā)語言的約束，從而極大降低了應(yīng)用開發(fā)者的開發(fā)成本。這種方式也經(jīng)常被稱為一種應(yīng)用的基礎(chǔ)設(shè)施層，類比TCP/IP網(wǎng)絡(luò)協(xié)議棧，應(yīng)用程序像使用TCP/IP一樣使用這個(gè)通用代理：TCP/IP負(fù)責(zé)將字節(jié)碼可靠地在網(wǎng)絡(luò)節(jié)點(diǎn)間傳遞，Sidecar則負(fù)責(zé)將請(qǐng)求可靠地在服務(wù)間進(jìn)行傳遞。TCP/IP面向的是底層的數(shù)據(jù)流，Sidecar則可以支持多種高級(jí)協(xié)議（HTTP、gRPC、HTTPS等），以及對(duì)服務(wù)運(yùn)行時(shí)進(jìn)行高級(jí)控制，使服務(wù)變得可監(jiān)控、可管理

從全局來看，在多個(gè)服務(wù)間有復(fù)雜的互相訪問時(shí)才有服務(wù)治理的需求。即我們關(guān)注的是這些Sidecar組成的網(wǎng)格，對(duì)網(wǎng)格內(nèi)的服務(wù)間訪問進(jìn)行管理，應(yīng)用還是按照本來的方式進(jìn)行互相訪問，每個(gè)應(yīng)用程序的Inbound流量和Outbound流量都要經(jīng)過Sidecar代理，并在Sidecar上執(zhí)行治理動(dòng)作

Sidecar是網(wǎng)格動(dòng)作的執(zhí)行體，全局的管理規(guī)則和網(wǎng)格內(nèi)的元數(shù)據(jù)維護(hù)通過一個(gè)統(tǒng)一的控制面實(shí)現(xiàn)，只有數(shù)據(jù)面的Sidecar和控制面有聯(lián)系，應(yīng)用感知不到Sidecar，更不會(huì)和控制面有任何聯(lián)系，用戶的業(yè)務(wù)和控制面徹底解耦

8、Istio 用在哪

Istio是一個(gè)服務(wù)治理平臺(tái)，治理的是服務(wù)間的訪問，只要有訪問就可以治理，不在乎這個(gè)服務(wù)是不是 所謂的微服務(wù)，也不要求跑在其上的代碼是微服務(wù)化的。單體應(yīng)用即使不滿足微服務(wù)的若干哲學(xué)，用Istio治理也是完全可以的

9、Istio 做了什么

以前后端分離的服務(wù)為例 前端 服務(wù)的代碼中通過域名訪問 后端 服務(wù)，在兩個(gè)服務(wù)中都不用包含任何服務(wù)訪問管理的邏輯。Istio在其中都做了什么（可以做些什么）

• 自動(dòng)通過服務(wù)發(fā)現(xiàn)獲取服務(wù)實(shí)例列表，并根據(jù)負(fù)載均衡策略選擇一個(gè)服務(wù)實(shí)例
• 對(duì)服務(wù)雙方啟用雙向認(rèn)證和通道加密
• 如果某個(gè)服務(wù)實(shí)例連續(xù)訪問出錯(cuò)，則可以將該實(shí)例隔離一段時(shí)間，以提高訪問質(zhì)量
• 設(shè)置最大連接數(shù)、最大請(qǐng)求數(shù)、訪問超時(shí)等對(duì)服務(wù)進(jìn)行保護(hù)
• 限流
• 對(duì)請(qǐng)求進(jìn)行重試
• 修改請(qǐng)求中的內(nèi)容
• 將一定特征的服務(wù)重定向
• 灰度發(fā)布
• 自動(dòng)記錄服務(wù)訪問信息
• 記錄調(diào)用鏈，進(jìn)行分布式追蹤
• 根據(jù)訪問數(shù)據(jù)形成完整的應(yīng)用訪問拓?fù)?/section>
• ……

所有這些功能，都不需要用戶修改代碼，用戶只需在Istio的控制面配置即可，并且動(dòng)態(tài)生效

對(duì)業(yè)務(wù)代碼完全沒有侵入性

10、用什么姿勢(shì)接入 Istio

雖然Istio能解決那么多的問題，但是引入Istio并不是沒有代價(jià)的。最大的問題是Istio的復(fù)雜性，強(qiáng)大的功能也意味著Istio的概念和組件非常多，要想理解和掌握Istio，并成功在生產(chǎn)環(huán)境中部署需要非常詳細(xì)的規(guī)劃。一般情況下，集群管理團(tuán)隊(duì)需要對(duì)kubernetes非常熟悉，了解常用的使用模式，然后采用逐步演進(jìn)的方式把Istio的功能分批掌控下來

• 第一步，自然是在測(cè)試環(huán)境搭建一套Istio的集群，理解所有的核心概念和組件。了解Istio提供的接口和資源，知道它們的用處，思考如何應(yīng)用到自己的場(chǎng)景中，然后是熟悉Istio的源代碼，跟進(jìn)社區(qū)的issues，了解目前還存在的issues和bug，思考如何規(guī)避或者修復(fù)。這一步是基礎(chǔ)，需要積累到Istio安裝部署、核心概念、功能和缺陷相關(guān)的知識(shí)，為后面做好準(zhǔn)備

• 第二步，可以考慮接入Istio的觀察性功能，包括logging、tracing、metrics數(shù)據(jù)。應(yīng)用部署到集群中，選擇性地（一般是流量比較小，影響范圍不大的應(yīng)用）為一些應(yīng)用開啟Istio自動(dòng)注入功能，接管應(yīng)用的流量，并安裝prometheus和zipkin等監(jiān)控組件，收集系統(tǒng)所有的監(jiān)控?cái)?shù)據(jù)。這一步可以試探性地了解 Istio對(duì)應(yīng)用的性能影響，同時(shí)建立服務(wù)的性能測(cè)試基準(zhǔn)，發(fā)現(xiàn)服務(wù)的性能瓶頸，幫助快速定位應(yīng)用可能出現(xiàn)的問題。此時(shí)，這些功能可以是對(duì)應(yīng)用開發(fā)者透明的，只需要集群管理員感知，這樣可以減少可能帶來的風(fēng)險(xiǎn)

• 第三步，為應(yīng)用配置timeout超時(shí)參數(shù)、自動(dòng)重試、熔斷和降級(jí)等功能，增加服務(wù)的容錯(cuò)性。這樣可以避免某些應(yīng)用錯(cuò)誤進(jìn)行這些配置導(dǎo)致問題的出現(xiàn)，這一步完成后需要通知所有的應(yīng)用開發(fā)者刪除掉在應(yīng)用代碼中對(duì)應(yīng)的處理邏輯。這一步需要開發(fā)者和集群管理員同時(shí)參與

• 第四步，和ingress、helm、應(yīng)用上架等相關(guān)組件和流程對(duì)接，使用Istio接管應(yīng)用的升級(jí)發(fā)布流程。讓開發(fā)者可以配置應(yīng)用灰度發(fā)布升級(jí)的策略，支持應(yīng)用的藍(lán)綠發(fā)布、金絲雀發(fā)布以及AB測(cè)試

• 第五步，接入安全功能。配置應(yīng)用的TLS互信，添加RBAC授權(quán)，設(shè)置應(yīng)用的流量限制，提升整個(gè)集群的安全性。因?yàn)榘踩膯栴}配置比較繁瑣，而且優(yōu)先級(jí)一般會(huì)比功能性相關(guān)的特性要低，所以這里放在了最后

當(dāng)然這個(gè)步驟只是一個(gè)參考，需要根據(jù)自己的情況、人力、時(shí)間和節(jié)奏來調(diào)整，找到適合的方案

11、Istio 不是銀彈

Istio的架構(gòu)在數(shù)據(jù)中心和集群管理中非常常見，每個(gè)agent分布在各個(gè)節(jié)點(diǎn)上（可以是服務(wù)器、虛擬機(jī)、pod、容器）負(fù)責(zé)接收指令并執(zhí)行，以及匯報(bào)信息；控制中心負(fù)責(zé)匯聚整個(gè)集群的信息，并提供API讓用戶對(duì)集群進(jìn)行管理。kubernetes也是類似的架構(gòu)，SDN（Software Defined Network）也是如此。相信以后會(huì)有更多類似架構(gòu)的出現(xiàn)，這是因?yàn)閿?shù)據(jù)中心要管理的節(jié)點(diǎn)越來越多，我們需要把任務(wù)執(zhí)行分布到各節(jié)點(diǎn)（agent負(fù)責(zé)的功能），同時(shí)也需要對(duì)整個(gè)集群進(jìn)行管理和控制（control plane的功能），完全去中心化的架構(gòu)是無法滿足后面這個(gè)要求的

Istio的出現(xiàn)為負(fù)責(zé)的微服務(wù)架構(gòu)減輕了很多的負(fù)擔(dān)，開發(fā)者不用關(guān)心服務(wù)調(diào)用的超時(shí)、重試、rate limit的實(shí)現(xiàn)，服務(wù)之間的安全、授權(quán)也自動(dòng)得到了保證；集群管理員也能夠很方便地發(fā)布應(yīng)用（AB 測(cè)試和灰度發(fā)布），并且能清楚看到整個(gè)集群的運(yùn)行情況

但是這并不表明有了Istio就可以高枕無憂了，Istio只是把原來分散在應(yīng)用內(nèi)部的復(fù)雜性統(tǒng)一抽象出來放到了統(tǒng)一的地方，并沒有讓原來的復(fù)雜消失不見。因此我們需要維護(hù)Istio整個(gè)集群，而Istio的架構(gòu)比較復(fù)雜，尤其是它一般還需要架在kubernetes之上，這兩個(gè)系統(tǒng)都比較復(fù)雜，而且它們的穩(wěn)定性和性能會(huì)影響到整個(gè)集群。因此再采用Isito之前，必須做好清楚的規(guī)劃，權(quán)衡它帶來的好處是否遠(yuǎn)大于額外維護(hù)它的花費(fèi)，需要有相關(guān)的人才對(duì)整個(gè)網(wǎng)絡(luò)、kubernetes和Istio都比較了解才行

See you ~