在當今資訊爆炸的時代，各行業的業務量都在爆發性增長，對於傳統企業來說，增長的業務量往往對IT系統帶來不少挑戰，出現瞭如應用模組耦合、業務程式碼滾雪球式增長、專案迭代時間長、單模組故障影響全域性等問題。因此，很多傳統企業希望轉型微服務架構來解決上面的問題。而微服務框架自身的複雜性及架構多樣性，則為該架構的選型及構建增加了入門門檻。因此，希望TSF對微服務的摸索經驗和技術實踐能為眾多企業構建微服務框架發揮一定的借鑒作用。
微服務架構來源於分散式架構，是分散式系統在雲端計算時代產物，一個或多個微服務可以組成一個大型複雜軟體應用，微服務之間是松耦合的架構、可以獨立部署、升級。基於微服務的系統可提供高階別的系統水平擴充套件能力。
在微服務架構的實現中，為提升效率和降低門檻，應用開發者會基於微服務框架來實現微服務。微服務框架一定程度上為使用者遮蔽了底層網路的複雜性及分散式場景下的不確定性。透過API/SDK的方式提供服務註冊發現、服務RPC通訊、服務配置管理、服務負載均衡、路由限流、容錯、服務監控及治理、服務釋出及升級等通用能力。
第一代微服務框架（準確來說應該屬於分散式RPC通訊框架），分層架構如下：
代表是COBRA及WebServices，透過協議描述檔案（IDL/WSDL）約定雙方的通訊介面，應用透過SDK來進行服務通訊。但是，應用開發者需要寫大量複雜及重覆的程式碼來解決分散式場景下的服務發現、失敗重試、過載熔斷等問題。
為瞭解決第一代框架中遇到的問題，出現了第二代微服務框架，分層架構如下：
典型的產品是SpringCloud、Finagle、Dubbox等。開發人員透過整合相應的類庫SDK，透過配置以及呼叫SDK介面的方式來進行微服務的開發。由於Java語言的便捷以及Spring框架的普及，當前這種樣式的微服務框架是業界使用最廣泛的微服務框架。傳統行業中，對於那種本身是基於Java&Spring;開發的應用、或者新開發的應用，基本上都首選採用該微服務框架來進行改造。
但是第二代框架也不能解決所有問題，對於一些類似傳統銀行、敏感機關、或者小型企業的行業客戶，其應用的特點具備跨語言、應用改造流程複雜、線上節點替換升級風險大、ISV技術積累較淺的特質。在這種情況下，往往難以說服他們使用框架SDK進行改造。
在這種背景下，催生了下一代微服務架構SeviceMesh，一種基於外接Sidecar樣式的微服務框架。其架構特點是把微服務框架的能力移到了微服務外部，作為獨立的Sidecar行程來提供。微服務之間透過Sidecar透明代理的方式來進行通訊。使得服務開發者只需要聚焦業務本身，服務可隨意跨語言實現。而在升級過程中，Sidecar可以獨立升級，無需與微服務進行聯動替換。從而解決了第二代框架所遺留的問題。
典型的開源產品有Spring Cloud Sidecar（無獨立控制面）以及Istio/Envoy（帶獨立控制面），分層架構如下：
接下來我們針對TSF中使用的Spring Cloud及ServiceMesh的能力做一個展開的分享。
-
服務框架層包括嵌入式SDK以及ServiceMesh。
-
服務生命週期管理層包括自研的PaaS以及治理運維平臺（不在本次分享範圍之內）
嵌入式SDK主要是基於Spring Cloud來實現。Spring Cloud是業界改寫量比較高的一個優秀的開源微服務框架，其特點是基於Spring Boot微容器能力的基礎上，融合了Netflix、HashiCorp等組織所開源的元件，形成的一個配置驅動，能力相對完備，高度可擴充套件的服務框架。如下為其元件與微服務框架能力的對應表：
由表格可以看出，Spring Cloud的核心能力在於微服務互動本身，但是其存在以下的問題：
-
缺乏複雜的服務治理能力（服務降級、服務監控、動態擴縮容、灰度釋出），在一些可靠性、效能要求較高的場景下，也缺少相應的原生能力支撐（如異地多活，服務本地快取，四層協議通訊）。
-
在一些生產態的問題定位定界上，由於Spring Cloud自身列印的日誌以debug為主，但是為了效能考慮，現網往往不會開啟debug日誌。因此當出現服務丟失等問題時，最常見的做法是依賴服務治理平臺整合外部的APM框架來進行應用內部監控。
因此，大家在基於Spring Cloud作為服務框架的實踐過程中，要註意規避或解決上面所提及的問題。而TSF對Spring Cloud透過自研及整合開源的方式，補齊了Spring Cloud的所缺失的短板，提供了完善的含PaaS及運維治理能力的服務框架，但由於篇幅關係今天不展開討論。
TSF服務框架的ServiceMesh主要是有2類實現。
第一類ServiceMesh實現是無獨立控制面的全功能Sidecar，主要適用於有一定的研發能力，且對定製化要求較高的企業客戶。TSF主要是基於Spring Cloud Sidecar能力來實現全功能Sidecar。Spring Cloud Sidecar的靈感來源於Netflix的Prana，這個也是Spring Cloud與ServiceMesh融合的重要手段。其主要工作流程如下圖所示：
每個服務節點上會部署一個Sidecar行程，Sidecar根據配置將自身監聽地址以及服務名註冊到Consul Server。當收到外部請求時，會直接到達Zuul Servlet，此時首先判斷請求是否來源於自身節點服務，假如來源於自身節點服務，則直接走本地路由。否則，就走Ribbon流程進行服務路由及轉發。Sidecar在執行過程中，會定期呼叫所代理的服務的健康檢查介面，獲取服務健康狀態並上報Consul Server。這種Sidecar代理+服務的方式，所表現出來的行為，與直接嵌入Spring Cloud SDK樣式所表現的行為是一致的。Spring Cloud Sidecar樣式的缺點在於對服務的URL有要求（來源於Zuul的約束，必須帶有服務名），同時原生的Zuul + Ribbon轉發樣式的效能較差，缺少獨立控制面使得運維成本較高。
第二類實現是帶獨立控制面的Sidecar，主要適用於對定製化要求不高，但是對效能比較敏感，業務程式碼改造工作量大，希望低成本運維的企業客戶。帶獨立控制面的Sidecar也是ServiceMesh的業界通用實現。但是開發團隊應該如何去實現這種ServiceMesh呢？
實現微服務框架的關鍵在於開源選型。TSF在Mesh構建初期，業界已經有不少優秀的開源資料面Sidecar產品，如Envoy、Linkrd、nginMesh、Conduit等，而且各有各的亮點和最佳適用場景。但最終資料面選定Envoy的原因在於：
-
Envoy社群成熟度較高，商用穩定版本面世時間較長。如nginMesh以及Conduit至今仍未有商用版本。
-
Envoy底層基於C++，效能上優於使用Scala的Linkrd，同時C++與騰訊系的語言體系較吻合。
-
Envoy在騰訊內部使用相對廣泛，穩定性相當高，對於執行態代理，穩定性直接影響交付質量。
而對於資料面的開源選型，則可選範圍相對較少，當前控制面集大成者是Istio，業界幾乎所有的開源資料平面產品（Conduit除外），都支援對接Istio，但是Istio存在2個問題使得當時在選型上掙紮了一下：
-
原生的Istio大部分能力與Kubernetes是強關聯的。而TSF則是與P層平臺解耦的，框架在設計上需要能夠對接多P層平臺。
-
Istio至今未有商用穩定版本，當前最新版本是0.7.1。
-
Istio擁有極高的社群影響力，開發團隊來源於Google和IBM。所基於的xDS（LDS、RDS、CDS、EDS）控制介面規範幾乎成為控制面的實際規範。
-
Istio版本速度較快，今年內極有可能會推出1.0版本。
-
透過調研Istio程式碼，發現透過一定程度的定製及擴充套件，可以使得Istio與Kubernetes成功解耦。經過選型後，我們Mesh產品架構如下：
-
Istio-Pilot：ServiceMesh的大腦，對接註冊中心與配置中心，透過不同的介面給資料面節點提供服務呼叫所需要的全部規則及資訊（包括Envoy的內部監聽及轉發規則、叢集服務資訊、服務路由規則、負載均衡規則、服務實體資訊等），所依賴的控制介面描述可參考：https://github.com/envoyproxy/data-plane-api/tree/master/envoy/api/v2
-
Istio-Mixer：提供了一套Attribute處理框架，可供使用者去定製服務許可權控制、服務Quota限流、呼叫統計資訊上報及採集分析的能力。
-
Istio-CA：主要是安全相關的。提供證書的更新、金鑰集中管理下發、RBAC許可權模型的更新及維護等能力。
-
Pilot-Agent：提供環境初始化、服務註冊、Envoy行程監控的能力。
-
Envoy：提供服務的透明代理能力，可以根據控制面下發的控制資訊進行訊息的投遞。當前支援的協議包括HTTP、HTTP2、GRPC。Envoy本身提供listener介面供自定義私有協議。
下麵透過一個例子講解一下ServiceMesh內部如何進行訊息路由：
-
服務A透過http://:/url的方式對服務B發起REST服務呼叫。
-
A節點的流量接管能力將該報文接管到本節點的Envoy行程。
-
Envoy行程透過Pilot下發的控制資訊（該控制資訊的分類及運算比較複雜，鑒於篇幅關係不詳細展開，後續有機會再單獨開篇介紹），經過一系列的負載均衡計算及許可權檢查，確定了B服務的標的實體節點，將資訊投遞給該節點。
-
B節點收到訊息後，流量接管能力將訊息接管進Envoy。Envoy透過Quota限流策略檢查是否已經達到上限，檢查透過後，則根據Pilot下發的內部路由規則，路由給節點內的服務實體。
-
服務實體收到請求後，進行業務邏輯的處理。
最後，分享下ServiceMesh在使用過程中所遇到的待改進點以及思路。
當前ServiceMesh在推廣過程中，遇到的最大的障礙實際上還是Istio未有商用版本的問題。不過其實從Istio官網可以瞭解到，當前Istio大部分核心能力已經是beta或者stable狀態（https://istio.io/about/feature-stages.html）。
因此在商用前只要能夠仔細評估涉及的能力範圍，原則上不會出現較大的問題。其他潛在問題的待改進思路如下：
-
暴力流量接管：這個也是網上詬病比較多的問題。由於Istio的資料面依賴於針對容器內流量進行全接管，但是對於虛擬機器場景下可能不適用，畢竟虛擬機器上可能不僅僅只有Mesh的服務。因此，需要考慮細粒度的接管方案。
-
全量服務發現問題：Istio是一個集中的控制面，在構建路由資料時，會預設從註冊中心獲取全量的服務實體資料，一旦服務節點量級上升後，會導致較嚴重的效能及資源佔用問題。因此，定製過程中可以考慮採用服務元資料的方式來減少發現的資料量。
-
Mixer快取穿透的問題。由於Envoy在每個請求的傳送前以及接受到請求後，都需要往Mixer去查詢許可權及Quota資訊，為提升效能，Envoy會對這些查詢結果進行快取。而由於這些資訊是per request的，而且Envoy無法知道會有哪些attributes（key）需要去快取，從而快取的總量有可能根據呼叫時長而呈現不斷增長的趨勢，引發資源佔用問題。因此，在這方面可以適當引入LRU演演算法來解決。
-
多租戶隔離的支援。在公有雲場景下，使用者對隱私和隔離看得非常重要。往往不同使用者/租戶之間，服務配置、節點資訊、控制資訊等資源資料是隔離的，互相不可見。但是Istio本身並不支援這種級別的隔離。需要框架整合者去進行擴充套件。
-
自動服務註冊能力的支援。Istio並不提供自動服務註冊能力（其服務模型依賴Kubernetes的Service），因此，假如需要將Istio脫離Kubernetes執行，首要解決的是自動服務註冊的問題。思路是Pilot提供介面獲取應用節點服務資訊，然後透過透過每個節點部署的Pilot-Agent拉取並註冊節點服務實體。
由於ServiceMesh是一個技術棧相當深的系統，在不同業務場景下，所面對的挑戰以及所需要的底層技術並非今天的分享就能夠介紹全面的。
由於本人學識有限， 所談及的內容難免有疏漏之處，還請各位朋友不吝指正。謝謝！
Q：請問你們微服務與Kubernetes的關係是怎麼樣的？下層跑的是Kubernetes容器嗎？
A：Kubernetes原則上是屬於PaaS平臺，PaaS平臺是負責服務的生命週期管理以及伸縮運維等能力。而我們微服務框架本身實際上更多是針對服務呼叫以及治理方面，其架構是與PaaS解耦，並且可以對接不同的PaaS平臺（包括Kubernetes），我們下層支援容器及虛擬機器。
Q：請問一下TSF如何融合Spring Cloud和ServiceMesh？
A：TSF透過3種方式融合：一方面我們有一部分ServiceMesh方案基於Spring Cloud實現；二方面，是統一服務模型與配置模型；三方面，是體驗統一，就是服務的部署/升級及運維的體驗是一致。
Q：引入Mesh之後，會額外多一跳，這多一跳帶來的效能損失，TSF是如何找回來的？
A：其實很多團隊會糾結引入Mesh後多了的那1跳的效能損失，其實經過我們驗證，一方面Envoy效能極高，媲美Nginx；二是這一跳的損耗，實際上與業務處理時延有比較大的關係，如果業務處理時延在30毫秒以上，那麼這一跳帶來的損耗實際上可以控制在可控範圍內（具體要看機器效能）。
Q：30ms時延算很大了。如果是2ms或者0.xms是不是必須考慮這個問題了？也就是說可能得看Envoy的效能與業務的效能是否接近？
A：根據我們在公有雲的測試結果來看是的，假如業務是屬於那種對快速響應而且對時延特別敏感的業務，確實需要跟進實際的測試模型來評估下具體的效能損耗。
Q：對於Spring Cloud與Spring Cloud Sidecar的區別是什麼呢，對於從SOA轉型到Spring Cloud有什麼好的建議嗎？謝謝。
A：Spring Cloud Sidecar是以Sidecar方式支援非Java應用而提供的，和Spring Cloud沒有太直接關係。具體從SOA到Spring Cloud轉型這個不太好泛泛而談，要結合實際情況分析。
Q：Istio和Kubernetes結合使用時，服務註冊和服務發現是怎麼用的？
A：Istio本身支援多種服務註冊發現機制（包括Kubernetes、Consul、Digital Foundry、Ereuka等），在啟動Istio時作為引數來配置即可。
Q：請問是否有過使用gRPC通訊的相關案例或者需要註意的坑？目前是否能夠在生產環境應用？
A：暫時沒有發現envoy-grpc的坑，不過Istio官方對於gRPC的feature狀態是alpha，所以個人不建議在生產環境的使用Istio。
本次培訓內容包括：Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
