用友雲服務治理平臺 助力企業微服務架構落地

本文主要闡述使用微服務架構時，治理框架或者平臺須要解決的主要問題，微服務落地實施過程當中所遇到的關鍵問題和對應解決方案。同時，文章也介紹用友雲旗下的微服務治理平臺的核心功能和技術架構，以及微服務治理平臺在用友雲一些產品下的實踐，下一步的發展計劃和趨勢。

用友雲微服務治理平臺由來

伴隨互聯網、雲計算、大數據等技術的快速發展，愈來愈多的企業在信息化以後，將企業上雲和數字化提上日程。軟件架構的微服務方式重構、應用的自動化運維、容器化等需求強烈，催生出了衆多的PaaS平臺。同時，針對微服務，也涌現除了許多RPC框架和微服務治理平臺，各個框架和平臺都有各自的優點和自身獨特的適應場景。

 

 

 

相比於單體應用和SOA架構，微服務的小團隊開發運維、複雜度可控制、獨立擴縮、可靈活組合等等優點也逐漸凸顯，被廣大架構師和技術人員引入和推崇。但同時也引出了配置繁雜、事務不可控等諸多問題，如何恰當的解決微服務中暴露出的各類問題，成爲各微服務治理平臺的重點和難點。

軟件架構在微服務以前，各個服務經過RestFul接口或者RPC進行互聯和調用，進行功能的服務化和解耦，諸多成熟的RPC框架被引入，例如：

 

 

RPC調用是微服務治理的基礎，但單單RPC不能稱爲微服務，微服務的核心功能還應該包含服務註冊、發現，動態和可視化配置，限流熔斷，鏈路追蹤、分析，異步調用，數據一致性處理，API網關等等。

 

 

上文中所介紹的不一樣廠商的框架和產品，都圍繞着以上核心功能，進行了實現和融合。各個產品都有不一樣的複雜度和侷限性，並和自身廠商的其它產品聯繫密切。

用友雲主要面向企業級應用，在TOB領域有獨特的技術特點和要求，且用友雲下的微服務治理須要和自身的DevOps平臺、容器雲平臺及數據平臺進行協同和能力聚合。在借鑑和吸取其餘產品的優點的同時，用友雲微服務治理平臺團隊針對自身產品須要作了完善和適配，充分的和用友雲開發者中心、數據平臺、租戶中心、用戶中心等結合，推出了更適合自身的用友雲微服務治理平臺，平臺具備如下鮮明的特點：

 

 

用友微服務治理平臺從2015年立項以來，通過團隊的不斷打磨，已經發展了幾個版本，推出了較爲成熟的多個版本，例如2.3.1-RELEASE、3.0.1-RELEASE，並在3.5後進行了類隔離機制和插件機制的加強，推出3.5.2-RELEASE、5.0.0-RELEASE. 並在資金雲、人力雲、財務雲、協同雲等多個產品，中建、中廣核、DIWORK等大型項目中獲得了驗證。

平臺的主要功能和技術架構

（1）功能架構：

服務治理平臺提供RPC調用框架、異步調用框架、服務註冊發現、配置中心、元數據、一致性框架等基礎中間件，並預留了插件機制的擴展，方便開發者使用和集成；也從中間件容器層面提供類隔離和組件加載機制，儘可能避免和業務應用引用的三方組件版本衝突；提供統一的門戶入口，可視化的管理和查看遠程服務的接口信息、調用鏈路日誌、統計信息、評價信息，動態的控制具體接口和方法的權限和流量限制；提供限流、鏈路追蹤等組件保證服務的穩定和可用性。

同時，在外圍還支持和服務網關API Link的對接，支持使用IDE進行微服務的編排和一鍵發佈。

 

 

（2）技術架構

服務治理平的幾大核心技術模塊包含註冊中心，元數據、控制檯、配置中心、基礎SDK、鏈路計算、限流熔斷、異步調用和一致性適配組件，IUAP和DUBBOX適配組件等，大體能夠分爲兩類：微服務SDK（middleware）和後端支撐服務。

微服務SDK：

SDK主要可分爲啓動和加載（helix），基礎的RPC調用（iris），配置中心sdk（proteus）、限流（sentinel）、鏈路（yyeye）、監控（ms-monitor）、異步調用和可靠消息（eos-spring-support）、數據最終一致性（cctrans-springsupport）、IUAP上下文支持（iuap-support）、dubbox適配（dubbox-support）等。

各個組件經過核心的插件機制和類加載機制整合在一塊兒，造成總體對外提供服務，具備兩大鮮明特性：

1：支持SPI方式擴展的插件機制，靈活組合，易於擴展；

2：基於ClassLoder的類隔離機制，組件分離，避免衝突；

經過服務治理平臺的SDK，業務方能夠簡單快速的集成微服務的能力到業務工程，達到技術架構的微服務化的目的。

後端支撐：

後端支撐較爲核心的包括註冊中心、元數據、控制檯和鏈路計算、監控、配置中心、權限管控等。

·註冊中心源於springcloud體系下的eureka，在其基礎上增長了多租戶和權限校驗機制，和用友雲的租戶機制和驗證機制有機結合；

·元數據服務記錄了業務服務中暴露出的遠程RPC接口和方法，爲可視化的管控及數據分析打好基礎；

·統一控制檯提供服務治理平臺的UI交互的對接，支持用戶可視化的管控接口、權限、鏈路，查看統計信息和監控信息；

·鏈路計算經過隊列接收調用信息，使用數據平臺的存儲和分析機制統一計算和管理；

·監控服務收集各個應用和實例的基礎配置、權限限流配置、端口和域名信息、接入和輸出列表、調用基本統計等並統一展現；

·配置中心統一存儲各個應用的各類配置信息，動態管理和下發全局配置、權限配置、限流配置等；

 

 

EDAS是阿里雲平臺推出的分佈式服務調用和管控平臺，其依賴其自身雲平臺的配置中心、調度中心、基礎資源管理、核心容器、監控中心、權限中心等服務，構建總體服務對外提供服務，功能強大但相對複雜，總體技術棧對阿里雲體系的其餘產品強依賴，不易專屬化的實施落地。

 

 

用友雲平臺的微服務治理團隊也對其架構進行分析和對比，借鑑其優點的同時，結合自身特色，對各個模塊進行拆分，並在異步調用、多套環境支持、去容器依賴等方面進行了針對性的適配；同時在支持與開發者中心、用戶中心、權限中心等服務結合方面作了擴展，支持輕量化的獨立部署，爲平臺的專屬化減輕了負擔。

關鍵問題點和解決方案

服務治理平臺的幾大核心功能包含基礎的RPC框架、註冊中心元數據、配置中心、鏈路追蹤、異步和一致性、限流熔斷等；

服務治理平臺在實現和落地微服務的幾個核心功能的過程當中，也遇到一些難點，這也是衆多廠家和平臺共同的難點。針對這些關鍵點，服務治理平臺提出了適合自身場景的多種合理的解決方案並實現，較爲關鍵的幾點簡單說明以下：

（1）類隔離機制和插件機制：

JAVA 版的SDK，在和各類業務應用整合的同時，會遇到不少三方組件版本衝突的問題，給業務整合方帶來了困擾。服務治理平臺自3.5 版本開始對其進行了優化，引入了類隔離機制，推出了冰山（iceberg）思想，內部自身加載其依賴的三方組件，不對外部的業務三方引用形成衝突，大大簡化了集成的難度。

 

 

同時，服務治理平臺各個組件使用插件（plugin）機制進行組合，爲後續的擴展和能力加強打好基礎。

（2）動態配置：

業務應用的微服務化拆分，使得業務工程的配置文件更加繁多和分離，微服務的權限和流量的實時控制，也須要動態的管理各項配置。因此配置中心的後端服務和前端SDK體現出更重要的做用。

 

 

服務治理平臺的SDK爲每一個使用的客戶端，內置了配置中心的SDK，其使用長輪詢的方式，近實時的感知遠程配置文件的變化，從而及時的響應變化。雲端的操做提供RestFul接口和可視化界面，操做簡單實用。

 

 

（3）異步調用數據最終一致性：

異步調用框架提供可靠消息組件，完善了隊列的權限認證體系，簡化了異步調用的開發方式，業務開發只須要簡單配置和註解，便可完成異步操做。同時，異步事務控制檯能夠在雲端可視化的下發命令，提供錯誤事務的重試機制。

 

 

服務治理平臺的SDK，將eos、cc等適配組件有機結合，一體化對外提供服務：

 

 

上述幾個關鍵點只是服務治理平臺的部分問題的解決方案，還有更多的技術點，本文在這裏不作更深層次的闡述。經過雲平臺和支持和服務治理平臺團隊的共同努力，咱們攻克了許多難題並給出了比較合理的解決方案且落地實現，爲雲平臺及其餘產品的微服務化鋪平了道路。

服務治理平臺在用友雲的實踐和落地

微服務治理平臺自推出以來，經歷了多個版本的迭代和屢次升級完善，目前已經相對穩定。線上支持的應用數量已達到900多個，API數量已經接近三萬個。

目前，使用服務治理平臺的雲產品和組織包括資金雲、財務雲、人力雲、協同雲、用友審計、用友能源等，支持的大型項目包括中建、中廣核、DIWORK等。感謝各個平臺和產品的支持，也但願微服務治理平臺在對各產品和項目的微服務拆分及落地提供更多更有效的服務。

 

 

下圖爲線上監控系統分析出的各個產品和模塊的調用依賴圖，隨着各個產品和服務的接入，用友雲服務間的調用層級、依賴關係會愈來愈清晰，咱們也能從中提煉出更多的價值。

 

微服務治理髮展趨勢和展望

服務治理平臺通過長時間的發展和磨練，已經在分佈式服務調用、運維管控和服務治理、生命週期管理和統一控制檯、數字化監控和運營、開發支持擴展和兼容等等大方面有沉澱和輸出。咱們也和其餘成熟的產品及框架進行對比，吸取和優化，構建和完善自身的微服務能力體系。

 

 

隨着產品的發展，服務治理平臺也總結了自身的幾個重要階段，咱們從基礎的調用框架走來，增強了權限和安全的管控，加入了服務穩定性保證，這些功能已經能覆蓋大部分的業務需求。

 

 

但同時，咱們要把握好技術的發展趨勢，站在發展的前沿。服務治理平臺下一步的發展規劃，包括支持服務搜索和集市、對服務編排和網關更有效的組合、服務網格、服務監控等。

各個產品和服務間的調用數據已經收集，如何更好的更充分的利用這些數據，挖掘出有價值的信息，是服務治理平臺的一個重要課題，咱們能夠借鑑京東雲的思路，從這些數據中發掘出相似知識搜索、服務評價、調用圖譜等，不只從技術上，也從業務和流程上給出有價值的分析結果。

 

 

同時，線上應用變得更多，調用關係變的更復雜後，微服務監控的重要性就更加凸顯。有效和及時的監控到各個服務和實例的參數、指標，能更有針對性的進行問題問題的排查和解決。下一階段，微服務監控也是咱們須要重點、大力投入的。

咱們但願構建一個統一的可視化微服務監控體系，能夠從中直觀的獲取到各種監控信息，譬如運行時環境、全局配置、異步調用配置、一致性組件的配置等，連接、端口、域名、躍點等，還有服務接口的調入、調出列表和統計信息，調用出錯的鏈路和堆棧信息等等。有效的服務監控必將在開發和運維的不一樣階段體現出更大的做用。

能力聚合、生態鏈、協同發展

服務治理平臺的發展並不是原生和獨立的，其成功推出也伴隨着其餘產品和技術的支撐，雲平臺的DevOps、容器雲的發展和微服務的發展相輔相成，有機組合，數據平臺的大數據存儲和分析爲鏈路追蹤和分析提供了可能。

微服務治理平臺、DevOps平臺、容器雲平臺協力，成爲各個雲產品和服務成功上雲的三把尖刀，爲其底層的技術支撐提供了強有力的保障。相信三把尖刀也會在技術中臺中體現出愈來愈重要的價值。

 

 

對內有機整合，對外須要擴展和延伸，服務治理平臺和API Link、服務編排等在微服務外圍合理組合，使得微服務的利用率更高、可組合性更強。

 

 

可是，咱們清楚，服務治理平臺的各個技術架構和數據分析機制，依賴於各個業務平臺的數據，只有各個業務線的數據不斷完善，總體的用友雲調用鏈路不斷完整，服務治理才更加能突出治理和協調的做用，服務的分析和評價才更能落地。

各個業務的雲化和微服務化須要技術中臺的有力支撐，技術平臺的發展也須要各個業務的有力配合，但願服務治理平臺和開發者中心可以構建出愈來愈穩定和完善的服務，更多的雲產品和項目接入進來，構建更爲完整的用友雲生態。

服務治理平臺，做爲用友雲平臺下 3+2戰略 （技術中臺、業務中臺、數據中臺 + 混合雲、生態鏈）下的技術中臺核心產品，也必將展現出更強的戰鬥力。