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

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

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

服務部署在多個地域的多個機房，各類服務運行環境不少。開發語言繁多，例如京東智聯雲以Go、C++、Java、Node.js爲主，少許的Python和PHP，隨着業務線不一樣使用的技術框架不一樣。調用協議有rest，有非rest的HTTP等，還有自定義TCP協議的……

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

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

如下是精華分享內容，我們一塊兒來看看：

六週玩轉雲原生

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

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

1 服務治理演變史

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

1、單體架構

在服務治理的「史前」年代裏，無論是界面或是業務處理、數據處理都簡單粗暴地放在一個包裏，隨着業務的增加，給開發維護形成巨大的壓力。

2、分層架構

隨着業務的快速發展，開發者開始對業務系統進行拆分來解決併發問題，此時系統分爲前端和後端，出現了分層架構。其優勢是比單層架構下降了耦合性，增長協做性，缺點是重複開發，若是設計能力不足的話，一個接口設計問題還將影響總體系統。

3、分佈式架構

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

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

4、SOA架構

此時，AWS研發出新的架構——SOA（面向服務的架構），SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信。

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

基於此，國內巨頭互聯網公司採起「去中心化」的優化策略，ESB再也不作服務治理調用工做。去中心化的優勢是自動服務註冊和發現，服務列表自動推送，動態監控服務狀態，人爲控制服務狀態。

5、微服務架構

由於SOA是針對結構化的編程，缺乏熔斷、灰度等功能。隨着微服務架構的出現，提供配置管理、服務限流、鏈路跟蹤等豐富的服務治理功能。不過其缺點是當一套框架來支撐時，可支持的編程語言不足，且經過SDK集成的形式，形成升級困難。

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

一、從最初的純負載均衡形式，以Nginx或者VIP負載均衡爲表明，功能比較單一，靜態化配置，擴展比較困難。

二、發展到治理邏輯代碼單獨出現，業務代碼和治理邏輯總體耦合，但隨着服務增多，維護變得困難。

三、緊接着是治理邏輯獨立成代碼庫，以SDK的方式來提供，但其對多語言支持不足，若是SDK有問題升級較困難。

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

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

Spring Cloud利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，提供服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等部署。

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

Spring Cloud的優勢有：針對外部用戶的訪問提供了微服務網關；針對服務治理，提供服務發現和配置中心，包括監控體系和容錯等體系；針對底層中間件、數據層，提供消息總線、大數據驅動等功能。

Spring Cloud在物理機或虛擬機下的服務治理部署是：當一個請求進來時，先通過網關層，微服務網關從註冊中心獲取到請求要訪問的微服務實例地址，微服務實例啓動時從配置中心獲取相關配置，而後把自己的服務地址等參數寫入到註冊中心，微服務經過註冊中心獲取業務依賴的其餘微服務的地址進行調用。而後發現用戶的註冊中心，在配置中心進行公共配置。

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

一、Spring Cloud不支持灰度發佈；

二、服務網關：不支持動態路由，容易突破業務體系，需二次開發；

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

四、UI分散且簡陋；

五、只支持Java，不支持異構系統；

六、代碼入侵也嚴重，之後Spring Cloud V1升級到Spring Cloud V2時較困難。

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

一、微服務網關被K8S提供的ingress代替；

二、服務數據保存在K8S集羣的ETCD中，註冊發現經過K8S的APIServer提供；

三、配置中心換成了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的結構和特色，咱們能夠總結出其對於服務治理的理念：

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

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

三、價值：

（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的存活，且虛擬機是單對單的服務。

服務發現過程

一、先是部署完一個服務後，在服務樹裏記錄下它的信息，實例信息更新到DNS裏。

二、在服務調用時，經過DNS地址獲取服務的地址

三、發起調用時請求被劫持給Envoy。

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

五、根據策略獲得實際調用地址。

服務降級

服務降級是指Envoy出現異常的狀況，適配性的降級過程。當Envoy異常時，移除一些轉化規則；服務調用的過程當中還保持原有的實例信息更新到Service當中，根據Service信息也就是DNS信息得到服務地址，DNS發起總體調用，拿到調用結果。

擴展安全功能

京東智聯雲研發token服務並集成到Envoy中；並研發黑白名單插件，方便服務方更細緻的定義本身的安全策略。

擴展調用鏈功能

擴展調用鏈功能是服務治理過程當中服務關係疏離的一個必不可少的功能。系統在Envoy當中集成調用鏈的採集和輸出。採用的是jaeger形式，把數據採集後放在ES中，依賴圖譜分析服務，讓用戶研發人員能看到調用關係及耗時。

網格內外互通

京東智聯雲研發了一套Istio的網關，來支持網關的互通。當一個請求過來時，經過網關放到已知的網格內。在把這個請求經過Envoy進行服務的發現和調用的過程，若是在網格內的話，經過純網格的調用下發到Envoy。若是是網格內找不到這個服務就會打到Istio網關，Istio直接調用網格外的服務來適配，這是網格內外的互通。

跨地域

Istio是不支持跨地域的，但京東智聯雲完美地解決這問題。經過創建核心集羣，華北跨3az集羣部署。每一個機房獨立的部署一套Istiod的服務，多級緩存來提升性能。服務發現是按照優先級來分配，在一個服務調用另一個服務過程當中，首先是本az的調用，若是本az沒有的狀況下，在當前區域進行調用，再是跨區域的調用，來實現跨地域。

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

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

點擊【閱讀】獲取更多相關課程視頻！