前言

Istio發布1.0版本后，其服務發現和路由規則功能已基本具備production能力，我們也開始了Istio和公司內部微服務平臺的集成工作，打算以Istio為基礎打造一個微服務管控中心，在這里把目前的進展和遇到的坑和大家分享一下。

現有系統架構

目前公司的微服務架構如圖所示，系統中主要包含三類服務：

• 業務服務，大部分的業務服務都已經實現了微服務化和無狀態，采用docker容器部署在K8s集群中，利用K8s的容器管理能力進行服務部署，彈縮。但也有部分服務只做了容器化，但并未進行微服務改造，此類服務屬于SOA架構，一個服務可能對外暴露多個業務API，這和敖小劍老師在《SOFAMesh中的多協議通用解決方案》系列文章中提到的情況是類似的。

• 一些有狀態的公共服務，例如數據庫，FTP服務器，共享緩存等，目前未放入到K8s集群中，但業務服務對這些公共服務存在大量的依賴。

• 其他未納入K8S集群的服務，如遺留系統和第三方系統提供的服務。某些業務服務和這些服務之間存在互相訪問的需求。

服務注冊

電信領域與IT領域相比有一些特殊性，其中一點就是多網絡平面的需求。多網絡平面是電信領域的一個術語，通俗來講就是系統中存在多個網絡。采用多個網絡的目的一般是為了管理原因，例如管理系統采用一個網絡進行通信，而應用之間的通信在另一個網絡上，這多個網絡之間是相互隔離的。

采用多網絡平面后，和標準的K8S網絡模型有所不同，標準的K8S集群中的一個Pod上只會有一個網絡接口。我們的PaaS對K8S的網絡進行了擴展，使其支持多個網絡，即一個Pod上可以有多個網絡接口（該解決方案已開源，參見https://github.com/ZTE/Knitter）。

由于需要支持多網絡平面，我們開發了自己的服務注冊系統，該服務注冊系統中同時包含了K8s租戶中的微服務，公共服務和外部服務的所有服務相關信息。服務注冊系統通過REST接口對外提供服務注冊接口，也提供管理界面。K8S集群中的服務啟動后通過代理檢測并自動注冊，外部服務可以通過管理界面注冊，也可以開發第三方代理進行注冊。

采用了定制的服務注冊系統后的另一個優勢是K8S中部署的運行實例和注冊的服務關系是很靈活的，一個運行實例可以注冊多個服務，以支持尚未進行微服務改造的SOA類型的應用。

服務發現

系統內部服務之間采用客戶端發現機制，先通過服務發現接口從Service Registry中查詢到對端服務地址再發起請求。平臺提供了封裝好的SDK提供給應用微服務使用，SDK中封裝了服務發現以及LB，重試，斷路等服務底層通訊機制。

API Gateway

系統外部對內的調用通過API Gateway進入，采用服務端服務發現機制。服務名編碼在請求URL中，API Gateway解析URL得到服務名后，再根據Service Registry的服務注冊信息進行分發。

根據PaaS的部署場景，系統可以采用1級或者2級API Gateway進行請求分發。單租戶場景下采用1級API Gateway；多租戶場景下可采用2級API Gateway。第一級的Gateway在K8S集群外，是整個系統的總入口，負責分流K8s不同租戶以及外部服務的流量。第二級Gateway在K8S租戶中，是租戶內服務的請求入口。兩級API Gateway都從Service Registry獲取服務信息，考慮到安全和效率因素，每個Gateway只能拉取和自己負責部分的服務信息。

API Gateway支持虛擬主機，提供4層和7層的LB。除此以外，API Gateway被設計為一個可插拔的平臺，可以采用插件方式進行擴展，目前實現了下述插件功能：

• 對外部請求進行性能數據收集和統計分析。

• 調用認證服務對外部請求進行登錄驗證。

• 實現了限流、熔斷、黑白名單等功能。

• 可以通過分流規則實現應用的灰度發布。

痛點

• 在系統的初始階段，大部分的微服務都是基于JAVA編寫的，我們通過SDK封裝了服務發現，重試，限流，熔斷等用于服務間點對點通訊的邏輯提供給各個業務微服務使用。但隨著系統的發展，越來越多微服務開始采用Golang編寫，還有相當一部分基于Python的微服務，而且作為一個平臺，可以預見到將來還可能會有更多其他語言。為每一種語言編寫一套SDK的方案漸漸變得難以維護。將微服務的通訊層下沉到Mesh層是一個趨勢。

• 在API Gateway處可以對外部請求的性能數據進行統計分析，但無法對系統內部各個微服務之間調用的性能數據進行收集處理。如果采用侵入式的方案，則需要在各個語言和框架中采用一套標準的接口，并且要針對不同語言編寫對應的SDK，維護工作量很大，而且對于業務微服務的編碼有較大的限制，因此采用sidecar方式對微服務之間調用性能數據進行收集是一個更為合理的方式。

• 通過在API Gateway處使用分流規則來實現灰度發布的方案有較大限制，只能對應用整體進行分流，而無法對應用中的單個微服務的不同版本進行分流配置。因此基本上無法通過灰度發布來實現微服務粒度的快速升級迭代。

Istio集成方案

引入Istio后，系統架構如下圖所示

控制面

引入Istio Pilot提供服務發現和流量規則。Service Registry是基于Consul自研的，由于Pilot已經支持Consul的適配器，因此可以很容易地將我們的Service Registry作為服務信息提供者集成到Pilot中。

提供用戶界面對Mesh中的traffic rule進行配置，規則可以在設計應用藍圖時進行配置，也可以在運行期進行動態修改、添加和刪除。

引入Mixer進行Metrics收集，后端連接到Promeheus，打算采用自己開發界面對指標進行呈現。

目前采用Zipkin和Envoy直連進行分布式跟蹤，后續可能改用jager，因為jager采用了open tracing協議，開放性更好一些，而且是go編寫的，和我們目前的技術棧匹配。

數據面

在各個業務微服務的Pod中加入Envoy proxy，提供服務發現，可靠通訊，并根據Pilot下發的路由規則對服務通訊進行路由。

雖然Istio提供了Ingress Gateway，但Ingress Gateway只是提供了一個虛擬主機和Https終結的功能，并不能滿足我們的業務需求。因此我們決定繼續采用自研的API Gateway。但API Gateway的服務發現，LB功能交給Envoy接管，并將API Gateway上已實現的限流、熔斷、重試等規則切換為Pilot的Traffic rule，改為由Envoy處理。處理方式是在Internal API Gateway處也部署一個Envoy代理。

目前的進展

目前我們已經完成了Pilot和Mixer的集成，由于系統內部采用了是自己的安全方案，暫未考慮Citadel的集成。

驗證了服務發現，路由規則，Metrics收集和Distributed Tracing

開發用戶友好的界面對Istio的路由規則進行配置和管理。

基于Istio的路由規則，結合K8S開發了微服務的在線灰度升級。

遇到的坑和待解決問題

Istio不支持多網絡平面，導致Envoy在進行服務轉發時出現了死循環，環境中Envoy由于File Descriptor被耗光不停重啟。這個問題隱藏較深，花了差不多兩周時間定位和排除。我們正在基于Istio進行擴展以支持多網絡平面，并準備向社區貢獻這部分代碼。

社區沒有給出Mixer如何在K8S外進行部署的詳細文檔，在部署Mixer時遇到了較多的坑。

Mixer沒有Consul environment的 Adapter，因此上報的Metrics中缺失部分attribute，我們正在評估編寫該適配器，并準備向社區貢獻這部分代碼。

Istio目前主要支持的是HTTP和GRPC，對于異步消息如Kafaka并未支持。而要完成一個業務級的端到端路由控制，異步消息是必不可少的一環，可喜的是Envoy社區已經有計劃要對Kafaka進行支持。(https://github.com/envoyproxy/envoy/issues/2852)

對于IT應用來說，Service Mesh面對的主要是用戶（北向）流量和服務間（東西向）流量，但對于CT應用來說，還有很大一部分屬于網元到管理系統（南向）的流量，這部分流量基本上都是采用的自定義協議，目前尚不能被Istio理解。敖小劍老師在?《SOFAMesh中的多協議通用解決方案x-protocol介紹系列（3）——TCP協議擴展》介紹的阿里SOFAMesh的擴展方案已經提出了一個很好的思路。

About

Huabing Zhao?is a software architect, an Istio Member and an ONAP PTL. He has a solid experience in the information and telecommunication technology industry for more than 17 years.

Throughout his career, he has built a number of large-scale, cross-country NMS/OSS platforms/systems and operation tools, most of them are still running in productions.

He loves open source and has been contributing to various open source projects, he is a member of Istio1, a PTL of ONAP2, the author of Hugo clean-white theme3.

He also has strong interests in various technical topics such as Cloud Native, Artificial Intelligence, Cryptocurrencies, Smart Home, etc. He love sharing his ideas about these things in his blog.

Huabing holds a BSc in Computer Science and Technology from Chongqing University in China.

Currently, Huabing works as a software architect in ZTE Corporation and also wears the hat of PTL in ONAP open source project. For now, his main focus is to build a microservice-based, cloud-native, reliable, resilient and scalable open network automation platform.

While he is free, he likes writing technical blog posts, watching movies, swimming, hiking, travelling and learning languages.

Feel free to connect Huabing at Github? and Linkedin?, leave your thoughts in his blog? or share your ideas by writing him an email.

https://zhaohuabing.com/top/about/

想要和趙化冰老師面對面交流么？

8月22日18:00-21:00，中生代技術社區聯合DaoCloud組織論道云原生Service Mesh架構沙龍，趙化冰老師將分享《深入淺出Istio》主題，歡迎架構師朋友們來交流云原生技術

識別上圖二維碼或者點擊閱讀原文報名搶票

總結

以上是生活随笔為你收集整理的Istio微服务平台集成实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。