本文主要闡述使用微服務架構時，治理框架或者平臺需要解決的主要問題，微服務落地實施過程中所遇到的關鍵問題和對應解決方案。同時，文章也介紹用友雲旗下的微服務治理平臺的核心功能和技術架構，以及微服務治理平臺在用友雲一些產品下的實踐，下一步的發展計劃和趨勢。
用友雲微服務治理平臺由來
伴隨網際網路、雲端計算、大資料等技術的快速發展，越來越多的企業在資訊化之後，將企業上雲和數字化提上日程。軟體架構的微服務方式重構、應用的自動化運維、容器化等需求強烈，催生出了眾多的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戰略 （技術中臺、業務中臺、資料中臺 + 混合雲、生態鏈）下的技術中臺核心產品，也必將展示出更強的戰鬥力。