線上公開課 | 微服務太雜亂難以管理？一站式服務治理平臺來襲！

課程概要
如今微服務已成為構建現代雲應用的主導模式，它圍繞著特定的業務功能，將單個元件分解為獨立的服務。但隨之而來產生另外的問題：越來越多的系統被拆解成了很多個細胞一樣的微服務，如何對微服務進行管理，這成為許多工程師頭疼的挑戰。

相信很多成熟企業都擁有複雜的研發環境：上百條產品線、上千位開發人員、數千個服務。

服務部署在多個地域的多個機房，各種服務執行環境很多。開發語言繁多，例如京東智聯雲以Go、C++、Java、Node.js為主，少量的Python和PHP，隨著業務線不同使用的技術框架不同。呼叫協議有rest，有非rest的HTTP等，還有自定義TCP協議的……

如何統一管理？服務治理應運而生。透過服務治理來解決分散式服務和微服務在整體的開發和執行時出現的運維問題，處理服務之間的關係，提供一系列資料依據和工具。

4月21日，技術公開課《六週玩轉雲原生》第五講《微服務架構下，服務治理體系的演進歷程》由京東雲與AI事業部雲產品研發部架構師張俊峰為大家詳細講解了服務治理、Spring Cloud微服務架構特點、Service Mesh以及京東智聯雲在微服務的探索。

以下是精華分享內容，我們們一起來看看：

六週玩轉雲原生

微服務架構下服務治理體系的演進歷程

— 京東雲與AI產品研發部架構師 張俊峰 —

1 服務治理演變史

服務治理是隨著業務規模的不斷擴大，架構設計方案的不斷演進逐步衍生出來的一個概念。那麼我們根據架構的演進過程瞭解一下服務治理的出現過程。

一、單體架構

在服務治理的“史前”年代裡，不管是介面或是業務處理、資料處理都簡單粗暴地放在一個包裡，隨著業務的增長，給開發維護造成巨大的壓力。

二、分層架構

隨著業務的快速發展，開發者開始對業務系統進行拆分來解決併發問題，此時系統分為前端和後端，出現了分層架構。其優點是比單層架構降低了耦合性，增加協作性，缺點是重複開發，如果設計能力不足的話，一個介面設計問題還將影響整體系統。

三、分散式架構

在垂直產品基礎上進行水平的拆分，抽取出基礎來搭建起分散式架構。其優點是提高了程式碼複用率和提高開發效率，缺點是網狀呼叫、靜態配置地址和擴容較複雜。

此時出現“服務治理”的概念，當時這階段的服務治理是簡單的DNS服務發現和負載均衡。

四、SOA架構

此時，AWS研發出新的架構——SOA（面向服務的架構），SOA是一種粗粒度、松耦合服務架構，服務之間透過簡單、精確定義介面進行通訊。

它採用中心化的服務治理，中間透過ESB（企業服務匯流排）中心化來實現服務註冊、負載均衡等服務治理。SOA的優點是應用更容易維護，耦合度更低、擴充套件性更高。缺點是受ESB影響較大，維護成本很高。

基於此，國內巨頭網際網路公司採取“去中心化”的最佳化策略，ESB不再做服務治理呼叫工作。去中心化的優點是自動服務註冊和發現，服務列表自動推送，動態監控服務狀態，人為控制服務狀態。

五、微服務架構

因為SOA是針對結構化的程式設計，缺少熔斷、灰度等功能。隨著微服務架構的出現，提供配置管理、服務限流、鏈路跟蹤等豐富的服務治理功能。不過其缺點是當一套框架來支撐時，可支援的程式語言不足，且透過SDK整合的形式，造成升級困難。

從以上的架構演變過程可以總結出服務治理髮展的階段：：

1、從最初的純負載均衡形式，以Nginx或者VIP負載均衡為代表，功能比較單一，靜態化配置，擴充套件比較困難。

2、發展到治理邏輯程式碼單獨出現，業務程式碼和治理邏輯整體耦合，但隨著服務增多，維護變得困難。

3、緊接著是治理邏輯獨立成程式碼庫，以SDK的方式來提供，但其對多語言支援不足，如果SDK有問題升級較困難。

那麼下一代服務治理架構將是怎樣的？我們以目前應用最廣泛的Springcloud框架為例，來了解一下從傳統架構到雲原生架構下服務治理方式的改變。

2 服務治理上“雲”：從傳統框架到雲原生

Spring Cloud利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發，提供服務發現註冊、配置中心、訊息匯流排、負載均衡、斷路器、資料監控等部署。

圖注：Spring Cloud整體服務核心框架

Spring Cloud的優點有：針對外部使用者的訪問提供了微服務閘道器；針對服務治理，提供服務發現和配置中心，包括監控體系和容錯等體系；針對底層中介軟體、資料層，提供訊息匯流排、大資料驅動等功能。

Spring Cloud在物理機或虛擬機器下的服務治理部署是：當一個請求進來時，先經過閘道器層，微服務閘道器從註冊中心獲取到請求要訪問的微服務例項地址，微服務例項啟動時從配置中心獲取相關配置，然後把本身的服務地址等引數寫入到註冊中心，微服務透過註冊中心獲取業務依賴的其他微服務的地址進行呼叫。然後發現使用者的註冊中心，在配置中心進行公共配置。

這種傳統架構會存在一些不足之處：

1、Spring Cloud不支援灰度釋出；

2、服務閘道器：不支援動態路由，容易突破業務體系，需二次開發；

3、服務跟蹤：依靠第三方支援鏈路跟蹤，對APM的支援也比較欠缺；

4、UI分散且簡陋；

5、只支援Java，不支援異構系統；

6、程式碼入侵也嚴重，以後Spring Cloud V1升級到Spring Cloud V2時較困難。

雖然有以上問題，Spring Cloud提供了專門的spring-cloud-kubernetes專案和K8S整合，提供與程式碼程式設計無縫結合的靈活方式也許會增添競爭力。Springcloud部署到K8S環境中後，需要把原來的依賴替換為spring-cloud-kubernetes一整套：

1、微服務閘道器被K8S提供的ingress代替；

2、服務資料儲存在K8S叢集的ETCD中，註冊發現透過K8S的APIServer提供；

3、配置中心換成了K8S的ConfigMap。

儘管如此，Spring Cloud在K8S下的服務治理仍存在不足：一是不支援異構多語言；二是框架升級很困難；三UI還是原來的Spring Cloud。

為了解決當前微服務治理上存在的問題，新的服務治理架構——把服務治理程式碼獨立成程式，應允而生。這個新的服務治理架構我們稱之為Service Mesh。它將整體服務程式碼獨立成一套服務，將業務程式碼和治理邏輯做了整體的分離，如此一來，讓升級變得簡單。

3 Service Mesh：業務和治理程式碼分層

Service Mesh是一個專用的基礎設施層，旨在“在微服務架構中實現可靠、快速和安全的服務間呼叫”。它不是一個“服務”的網格，而是一個“代理”的網格，服務可以插入這個代理，從而使網路抽象化。Service Mesh 的本質是提供應用間的流量和安全性管理以及可觀察性。

Service Mesh有四大特點：應用程式間通訊的中間層、輕量級網路代理、應用程式無感知、解耦應用程式和服務治理。

如此一來，Service Mesh將業務模組和服務治理分開。

從上圖中我們看到，控制面和資料面分離，應用在部署的時候，每個應用附帶一個Side Car，這個Side Car是攔截每一個應用對外請求的。同時控制面的服務治理策略下到Side Car中具體的執行，這樣的話，即使業務模組升級和服務治理的升級也能互不影響的，還能動態調整服務治理的規則和策略。

從Service Mesh的結構和特點，我們可以總結出其對於服務治理的理念：

1、微服務治理與業務邏輯解耦：把大部分SDK能力從應用中剝離出來，並拆解為獨立程式，以 sidecar 的模式進行部署。

2、異構系統的統一治理：方便多語言的實施，解鎖升級帶來的困難。

3、價值：

（1）可觀察性：服務網格捕獲諸如來源、目的地、協議、URL、狀態碼、延遲、持續時間等線路資料；

（2）流量控制：為服務提供智慧路由、超時重試、熔斷、故障注入、流量映象等各種控制能力。

（3）安全性高：服務的認證、服務間通訊的加密、安全相關策略的強制執行；

（4）健壯性：支援故障注入，對於容災和故障演練等健壯性檢驗幫助巨大。

我們以Service Mesh的傑出代表Istio為例來聊聊最新的服務治理的架構，它對Service Mesh完全支援，架構清晰，拆分資料面、控制面；擁有通訊、安全、控制、觀察等功能，實現開放，且外掛化，多種可選實現。

Istio可結合K8S使用，K8S提供服務生命週期的管理，Istio在K8S之上透過服務治理的整體的功能的實現。

Istio的服務發現和負載均衡功能

圖注：Istio的服務發現和負載均衡功能

Pilot 從K8S平臺獲取服務發現資料，並提供統一的服務發現介面；Envoy 從Pilot獲取服務資料來實現服務發現，動態更新負載均衡池；然後根據負載均衡演算法選擇一個例項轉發請求。

它提供的負載均衡演算法有三大類：輪詢、隨即和最小連線數的負載均衡演算法。

Istio的服務熔斷

服務熔斷由兩種形式提供：

一是連線池管理：請求不超過配置的最大連線數時可以請求呼叫，一旦超過配置的閾值時在請求時被拒絕，以此來保證整個服務正常執行。

二是異常點的檢查，當允許呼叫的錯誤數超過一個閾值的時候，後端例項就會被移除掉，這樣在負載均衡合併列表時把它去掉，不再呼叫到具體的例項。例如，HTTP是連續返回5xx錯誤，TCP是連續出現連線超時，會被踢出服務池。但是踢除後有恢復檢查機制，如果能重新連線上或者重新呼叫，就能加到可用列表裡，如果繼續出錯的話，則繼續踢出，重複整體的過程。

圖注：Istio服務熔斷 VS Hystrix

Istio的灰度釋出

Istio提供了灰度釋出的兩種形式，一種是基於流量比；二是基於請求內容。

Istio的故障注入

透過申請一個YAML來實現故障注入，包括httpCode故障、超時故障等。

Istio的安全功能

安全功能的實現涉及到四個元件：第一個是Citadel，用於金鑰和證照的管理；第二是Proxy，實現客戶端與伺服器端安全通訊；第三是Pilot，將授權策略和安全命名資訊分發給代理；第四是Mixer，校驗授權和審計。

儘管Istio整體設計較先進，但在大規模落地時存在一些挑戰：

一是線上的挑戰——管理規模和效能，從管理規模上來講，還沒有經過大規模的場景驗證。從效能方面來說，多了一個Envoy中間層，在網路路徑和資源消耗上都會有效能損耗。

二是穩定性、可靠性需要提升，在實踐過程中遇到很多Bug。

三是微服務體系遷移的挑戰，現有的體系遷到Istio裡的話，怎麼最大程度降低程式碼的修改來實現遷移。

四是網格內外體系的互通，Service Mesh或者Istio不可能全部業務全部遷進去，這對整體的應用有很大風險，需保證網格內外應用正常訪問；Istio與K8S是強關聯，對其他平臺的支援還需要進一步的完善，比如對虛擬機器、裸金屬或者其他容器平臺。

4 Service Mesh的難題，京東智聯雲來解！

如上文所說，京東智聯雲內部開發環境複雜，所以在做服務治理時，京東智聯雲有自己的預期：

• 打造的服務治理框架能滿足各團隊的多種服務治理需求
• 儘量減少對產品線程式碼層面的改動
• 儘量減少對產品線呼叫方式的改動
• 儘量減少對產品線DevOps流程的變更
• 框架需要能滿足京東智聯雲每年10+倍的業務量增長
• 儘量控制服務框架的投入和風險

京東智聯雲部署最終實現的框架有容器、虛擬機器、雲翼等服務；能跨地域、多可用區；支援多種網路，包括經典網路+多個vpc網路；超大型的服務規模。

部署應用

京東智聯雲先是依賴於雲翼部署服務，部署後服務的註冊資料在當前的服務樹中進行整體註冊，然後把Istio控制皮膚部署在雲翼裡，整體使用的是原有的DevOps系統。另外，基於雲翼的agent來保證Envoy的存活，且虛擬機器是單對單的服務。

服務發現過程

1、先是部署完一個服務後，在服務樹裡記錄下它的資訊，例項資訊更新到DNS裡。

2、在服務呼叫時，透過DNS地址獲取服務的地址

3、發起呼叫時請求被劫持給Envoy。

4、Envoy獲取服務列表和策略。

5、根據策略得到實際呼叫地址。

服務降級

服務降級是指Envoy出現異常的情況，適配性的降級過程。當Envoy異常時，移除一些轉化規則；服務呼叫的過程中還保持原有的例項資訊更新到Service當中，根據Service資訊也就是DNS資訊獲得服務地址，DNS發起整體呼叫，拿到呼叫結果。

擴充套件安全功能

京東智聯雲研發token服務並整合到Envoy中；並研發黑白名單外掛，方便服務方更細緻的定義自己的安全策略。

擴充套件呼叫鏈功能

擴充套件呼叫鏈功能是服務治理過程中服務關係疏離的一個必不可少的功能。系統在Envoy當中整合呼叫鏈的採集和輸出。採用的是jaeger形式，把資料採集後放在ES中，依賴圖譜分析服務，讓使用者研發人員能看到呼叫關係及耗時。

網格內外互通

京東智聯雲研發了一套Istio的閘道器，來支援閘道器的互通。當一個請求過來時，透過閘道器放到已知的網格內。在把這個請求透過Envoy進行服務的發現和呼叫的過程，如果在網格內的話，透過純網格的呼叫下發到Envoy。如果是網格內找不到這個服務就會打到Istio閘道器，Istio直接呼叫網格外的服務來適配，這是網格內外的互通。

跨地域

Istio是不支援跨地域的，但京東智聯雲完美地解決這問題。透過建立核心叢集，華北跨3az叢集部署。每個機房獨立的部署一套Istiod的服務，多級快取來提高效能。服務發現是按照優先順序來分配，在一個服務呼叫另外一個服務過程中，首先是本az的呼叫，如果本az沒有的情況下，在當前區域進行呼叫，再是跨區域的呼叫，來實現跨地域。

最後，告訴大家一個好訊息， 京東智聯雲透過內部驗證相關的功能，如今向公有云輸出，公有云已具備了網格的基本功能，正在嘗試向大規模雲上輸出。

雲原生的時代已來，而你，也將成為這個新時代的構建者之一！

點選【 閱讀 】獲取更多相關課程影片！