在生產中使用Istio，咱們學到了什麼？

首先，給你們簡單介紹一下Istio，Istio是一個Service Mesh的開源框架，來自Google，大部分使用Go語言來開發，是Service Mesh的集大成者。

Istio數據層面主要使用envoy，Istio開發了一些 filter 擴展envoy的功能，這些功能主要集中在mixer上。Istio是新鮮出爐的技術，2017年5月0.1 release版本橫空出世，不過版本更新迭代很快，最新的版本是今年3月發佈的，1.1.3版。

Istio簡介

Istio在邏輯架構上由數據平面和控制平面組成。數據平面是經典的實現方式，由一組以 sidecar 方式部署的智能代理（Envoy）組成。這些代理能夠調節和控制微服務及 Mixer 之間全部的網絡通訊。

在每個容器中注入了一個sidecar，Istio的sidecar稱之爲Istio proxy，至關於envoy 加上Istio開發的envoy filter。Istio proxy能夠攔截整個容器的入口和出口流量。根據sidecar從數據層面接受到的規則和策略，進行一系列對於網絡流量的配置和管理，好比路由管理，加密，遙測數據收集。控制平面負責管理和配置代理來路由流量，此外，控制平面還配置 Mixer 以實施策略和收集遙測數據。

Istio有幾大塊功能，首先是流量控制，這個基本上是經過Istio裏的pilot組件來實現的。從圖上咱們能夠看到，rules api就是pilot提供的抽象API，用戶經過api來配置相應的規則。Paltform Adapter主要是兼容不一樣的平臺。用戶針對不一樣的平臺實現服務發現等功能。基於用戶的規則和從平臺收集的數據，經過envoy api把具體的規則下發到各個容器的Istio proxy。 這裏實現了大部分咱們須要的流量管理功能，例如負載均衡策略，路由控制。咱們能夠把原本發給服務A的請求，都導向另外一個服務。 故障注入，爲測試進行模擬。以及熔斷，url重寫，重試，超時等等。

Istio的第二塊，主要是安全機制。咱們能夠對網格內的微服務通信進行tls加密。在發起請求的Istio proxy對請求使用tls證書加密，在接受請求的Istio proxy對這個請求解密，這對於應用的開發者是無感的。Istio最優秀的地方就是對於業務開發者的基本無感。這些網絡調用相關的功能和策略被抽離出來，不用再放在應用的代碼裏。

Istio還提供了相似k8s rbac的權限實現方式。在servicerole定義使用service api的權限，經過service role binding綁定在k8s service account上，而後當應用經過service accout啓動後, 該應用就有service role裏定義的訪問其餘服務的權限。

下面一塊是策略和遙測，這個是Istio中爭議很是大的一個功能。好的方面是設計很是乾淨。Istio proxy只須要把它收集到的attribute發給mixer，mixer的Adapter基於attribute來作相應的操做。一類attribute用來作策略檢查，例如Qouta，另外一類用來作遙測數據收集，如promothues。 這其中體驗很差之處就在策略檢查上面。由於每一個請求都須要作這個檢查，這個檢查目前看來會影響總體的性能。1.1開始，Istio提供了簡單的方式能夠關閉全局這個檢查。若是你對性能要求比較高，目前最好仍是先關閉。

Istio 1.1的發佈對性能進行了大幅優化。官方提供的數據是：1000 k8s service， 2000個sidecar，每秒70000個請求在這個mesh網格中。這時候每一個proxy使用0.6個CPU，50M內存來支持每秒1000個請求。Istio的遙測，就是mixer須要0.6個cpu來支持每秒1000次的請求。這個地方並無說是否是包括策略檢查。我感受是不包含的。pilot須要1個cpu和1.5G的內存來作服務下發。最後，Istio proxy對服務間調用的性能影響是tp90 8ms。

微服務體系帶來的問題

原來的微服務體系中都面臨哪些難題呢？

首當其衝是定位和調試困難。當遇到bug或者性能問題，原來的方式基本都是逐級排查，從客戶遇到問題的地方開始。由於一個深層次的微服務會引發一系列的上層微服務出現問題。若是發現兩個服務直接之間的總體調用性能很差，這個時候哪怕你找到某一次性能差的日誌或數據，基於這個數據和日誌找出來的緣由不必定是root cause。這種排查問題的方式就像烽火臺，你只看到了最近的烽火臺，並不知道起點在哪。

第二，測試時數據會有遺漏，缺乏完整的測試數據。

最好的測試數據是線上的真實數據。可是線上的請求採集下來還須要獨立開發相應的程序，總體實現很麻煩。另外，若是測試微服務的錯誤處理，對於QA的黑盒測試來講，這還須要一個可配置的錯誤生成器。這點對於測試也是一個獨立的工做。

第三，缺乏上線流程。

咱們原來使用獨立的微服務做爲開關，來判斷是否加載新功能。在新的功能代碼外層加上調用該微服務的代碼，根據返回值來判斷是否執行新功能代碼，上線完成後再把開關代碼刪掉，的確有點麻煩。上線前須要修改源碼增長控制，上線完成後還須要在源碼中刪除這些邏輯。沒有簡單、無侵入的金絲雀和灰度發佈的實現方式。

第四，微服務間的網絡調用策略配置不靈活。

不一樣的客戶環境須要使用不一樣的網絡策略，例如重試，超時等等設置，若是對應的設置沒有經過配置文件暴露出來，就只能對代碼進行修改。並且這些代碼在業務代碼裏，統一的維護和升級都須要獨立的流程。

靈雀雲ASM如何解決上述問題？

靈雀雲從去年就開始有針對性地在ASM產品中解決這些問題。下面是咱們ASM的整體架構圖：

ASM controller是咱們開發的K8s controller，主要處理咱們本身定義的crd，以及作一些自動化的K8s資源處理；Dablo是ASM的前端界面；controller和diablo都會直接和K8s api server來通信；Istio gateway是Istio用來服務南北流量的接口，主要用來暴露集羣裏的微服務；jaeger分爲collector和query；collector直接從Istio proxy收集上報的調用鏈路數據，目前數據格式仍是用的zipkin，jqeger query是用來顯示調用鏈路的；爲了作namespace的數據隔離，咱們對jaeger的組件都作了相應的改造；存儲方式是ES；遙測數據用prometheus來存儲，數據從mixer收集而來；diablo經過直接調用prometheus api來獲取。

關於定位和調試，靈雀雲主要經過兩方面來解決：一方面使用promothues裏的遙測數據來繪製實時的拓撲圖。展現調用關係，以及調用數據，包括流量，性能，錯誤率等。另外一方面，經過jaeger的調用鏈來解決。咱們能夠查看完整的調用鏈路，具體到某次調用的時候，請求的內容，以及返回的狀態碼。

下面是咱們預覽版產品中的一些截圖。這個截圖來自於靈雀雲PaaS平臺的數據。咱們能夠看到整個平臺全部組件之間的調用關係，右邊是某兩個組件之間的調用數據，包含調用次數，rps，以及響應時間這樣的性能指標。這些能夠幫助咱們快速作定性的判斷。

後面兩張圖是咱們嵌入的jaeger query組件。當前面作了定性判斷後，這裏能夠查詢具體的問題是什麼，經過過濾條件來縮小範圍，而後具體看某一個請求的詳細信息。

爲了使用Istio這些功能，須要作些什麼配置呢？
1．全部的微服務中注入sidecar；
2．pod裏的container聲明瞭本身監聽的端口，保證可以攔截入口流量；
3．pod的label須要app和version兩個key；

1. K8s service裏聲明的port都必須包含name字段，根據使用的協議name的格式有必定的規則。例如使用是http協議，name能夠爲http或者以「http-」開頭；

5．服務調用的代碼須要作稍微的改造，須要獲取上一個請求header裏的一些字段，包括request id,trace_id, span_id。把他們設置在header中傳遞給下一個調用。這個在Istio官方的文檔裏能夠找到。
除了最後須要對代碼作少量的修改，前面都只是須要修改服務部署的yaml。

經過Istio提供的流量鏡像功能，咱們能夠很容易的使用生產環境來測試新的代碼。只須要把測試代碼經過一個獨立的應用直接發佈到生產環境，而後經過配置把流量拷貝一份調用這個測試代碼的應用就行了。

Istio的錯誤注入功能很容易模擬返回錯誤的狀態碼，增長請求返回的延遲。

在安全上線方面，在生產環境同時發佈新、老版本，經過拓撲圖和調用鏈的數據，來觀測新版本是否能夠正常工做。咱們經過流量的權重來實現灰度發佈，經過一些規則設置來實現金絲雀發佈。加上前面的生產環境測試，對於安全上線提供了很大的保證。

最後，靈活的網絡策略。經過istio的Virtual Service和Destination Rule這兩種資源，實現靈活的配置微服務間的網絡訪問策略。終於不用把這些策略的配置寫到咱們的代碼裏來，Istio的virtual service和destiinatio rule就徹底實現了。