技術隨業務而生，業務載技術而行。

近些年來，伴隨數字經濟的發展，在眾多企業的數字化轉型之路上，雲原生、DevOps、微服務、服務治理等成為行業內不斷被探討的新話題。人們在理解和接受這些新型概念的同時，也不斷地思考其可能的落地形態。需求是創造發生的原動力，於是一批代表性的開源技術或者框架湧現而出：Kubernetes，Spring Cloud，Service Mesh，Serverless…… 它們炙手可熱，大放異彩。然而在具體落地過程中卻步履維艱，磕磕絆絆。

本文試圖結合企業業務的核心訴求，以應用形態發展歷程為背景，幫助企業梳理應用面向雲原生、微服務轉型中涉及的各種服務治理問題，以及服務治理的發展趨勢。

什麼是服務治理？

服務治理（SOA governance），按照Anne Thomas Manes的定義是：企業為了確保事情順利完成而實施的過程，包括最佳實踐、架構原則、治理規程、規律以及其他決定性的因素。服務治理指的是用來管理SOA的採用和實現的過程。

由定義可知，服務治理關鍵因素在於：應用形態、資料採集、資訊分析、管控策略和協議規範五個方面。使用者群體只有從這五個層次出發，才能構建出符合企業規範與要求的服務治理平臺，從而進一步為企業創造商業價值。

01 “微觀”塑形，服務一小再小

世界上唯一不變的是變化本身。----By 斯賓塞.約翰遜

萬理同此，縱觀應用形態發展歷程，從單機到網路、從單體到服務化、到微服務、到Serverless，再到未來，應用的形態隨著業務驅動和技術演化，一直在不斷變化。隨之而來的是業務需求的複雜化與多樣化，企業IT面臨著大規模、高併發、應用快速創新等新難題，彈性與敏捷成為企業IT的迫切需求。

在IT行業內有兩個“不成熟”的理論：第一，每增加一行程式碼就會帶來N種風險；第二，任何問題都可以採取增加一層抽象的方式解決。因此面對企業IT複雜的環境，“小而精”逐漸取代“大而全”，成為構建企業服務的首選方式，這也導致軟體設計原則中的“高內聚，低耦合”又開始成為不斷被高調吟誦的主角，微服務理念因此大行其道。

微服務架構為業務單元可獨立開發和獨立部署，使服務具備靈活的動態處理機能，同時依賴高度抽象化的元件工具和多元化的通訊機制，向用戶遮蔽所有服務之間的通訊細節的這種思想提供了最佳落地實踐。微服務的出現有效地縮短了服務上線週期，並且允許企業快速響應客戶反饋，為客戶提供所期望的可靠服務。

然而隨著企業業務的發展與擴張與微服務的深入，服務數量向不可控的規模增長，服務數量的爆發式增長，為服務管理以及線上治理帶來了極大的挑戰。服務治理應運而生，成為構建微服務架構系統的必備“良藥”。

02 “量化”管控，服務無可遁形

數字永遠不會說謊。

如今，微服務已經成為軟體架構的實際指導思想，而以Docker和Kubernetes為代表的容器技術的延伸，也有效解決了微服務架構下多個服務單元的編排部署問題。然而，微服務架構下也隱藏著容易被忽視的風險：面臨規模巨大的服務單元，如何對其進行有效合理的管控與治理？

服務治理領域開始被行業與使用者所重視，期望能夠獲得有效的思維方式和技術手段，應對由於不斷激增的服務單元帶來的服務治理挑戰。關於服務治理，我們看到的更多的是其功能集合：服務註冊發現、服務配置、服務熔斷、閘道器、負載均衡、服務跟蹤、日誌採集、監控平臺等。但當我們拋開這些名詞解釋，重新審視服務治理的時候，這些名詞並沒有完整的解釋我們的困惑：如何設定負載均衡策略？採集日誌格式是什麼？服務配置如何生效？服務跟蹤如何進行精確定位？

顯然單單通過這些功能名詞無法滿足我們構建服務治理平臺的需求，但從這些功能中我們總結出一些規律與方法，我們將從功能場景的橫向切面和技術手段的縱深層次，進行如何構建一個有效的服務治理平臺的分析探討。 

首先，我們從服務治理功能場景的橫向切面來看，其可以抽象為四個層面：量化，追蹤，管控，規範。

量化

量化包括服務資料採集、資料過濾和資料聚合三個層次。資料採集進一步細分為業務資料和效能資料，業務資料主要包括方法響應週期、服務內資源消耗規模、業務異常檢測、方法呼叫次數、服務執行日誌等；效能資料包括服務間響應時長、服務整體資源消耗等。

服務本身需要依賴不同的特性，構建不同的agent，來蒐集服務執行時產生的資料。資料過濾針對採集的資料按照一定的格式規範進一步加工處理，例如基於kafka對原始的日誌資料進行標準化處理後，匯入日誌系統。

資料聚合需要對獨立的服務資料進行聚合操作，例如服務呼叫鏈呈現。

通過服務量化能夠清晰的記錄服務執行時產生的所有資料，為服務跟蹤呈現和服務管控策略制定並提供強有力的資料支撐。

追蹤

追蹤能夠有效量化服務呼叫鏈路上發生的事情，具體來講，可以劃分為：服務間的鏈路跟蹤和服務內部的方法呼叫鏈路跟蹤。追蹤的本質，不僅僅是為了呈現服務鏈路及服務路由資訊，更重要的是呈現服務間請求，以及服務內部請求的響應延遲，異常反饋，能夠快速定位服務以及服務內在程式碼存在的問題。

管控

管控依賴於量化採集的聚合資料。管控允許運維人員聚焦某個服務單元的執行時狀態，為服務設定一定的控制策略，從而保證服務穩定可靠的執行。例如熔斷策略，負載策略，流量控制，許可權控制等。

規範

規範更多針對服務通訊而言，例如通訊協議規範，無論針對哪種協議，例如http，tcp，rpc等都能夠提供相應的檢測手段。與此同時，規範也能夠清晰定義服務名稱和管控策略，使得服務在不同環境之間進行遷移的時候，依舊平穩可靠。

綜上所述，在服務單元遵循一定規範標準的前提下，基於服務單元資料量化、服務呼叫跟蹤以及服務策略管控的方式，才能構建出符合要求的服務治理平臺。

接下來，我們從縱深的角度考慮構建服務治理平臺過程中涉及的技術理論基礎。服務治理之所以困難，原因在於構建業務系統採用的技術棧成多元化的方式存在。從目前行業內採用的技術而言可以劃分為三大學派：程式碼整合、agent探針、流量劫持。

程式碼整合

程式碼整合往往需要業務開發人員的支援，在業務系統中嵌入資料採集程式碼，用來採集服務執行時服務產生的各種業務指標及效能指標，並將資料傳輸到雲端治理平臺。平臺依據資料資訊，通過配置動態下發，從而影響業務響應動態，完成服務治理功能。

優點：治理深入，端到端監控

缺點：維護繁瑣，語言版本眾多，影響業務效能

Agent探針

Agent探針是對程式碼整合的進一步提煉。Agent探針將需要整合的監控程式碼，高度提取、抽象、封裝成可以獨立整合的SDK，並且以“弱旁路”的方式與程式碼整合在一起，從而完成資料採集工作。雲端治理平臺，同樣以採集的資料資訊作為治理策略制定的依據，下發各種治理策略，從而達到服務治理功能。

優點：治理深入，端到端監控

缺點：語言版本眾多，影響業務效能

流量劫持

流量劫持與前兩者相比，與程式碼整合不同。它從網路通訊作為切入點，以proxy的方式，代理業務單元所有的IN/OUT流量，並且proxy內部可以對請求資料進行一定的策略控制。從而完成服務通訊的治理功能。

優點：無關語言差異性，維護簡單

缺點：治理略淺，影響業務效能

綜上所述，目前服務治理的技術棧或多或少都存在一些缺陷，在構建服務治理平臺時往往需要採用結合的方式，才能做到物盡其才。

03 “百家爭鳴”，成就未來

競爭成就未來。

從目前行業發展來看，微服務奠定了服務構建的基礎方式，容器引擎以及編排技術解決了服務編排上線的困惑，下一個“兵家必爭”的場景必將在服務治理。那目前行業內又有哪些專案聚焦在服務治理領域？

SpringCloud

SpringCloud作為Spring社群的重要佈局之一，在微服務落地伊始就逐漸發力，當下已經成為Java體系下微服務框架的代名詞，SpringCloud 以 Netfilx 全家桶作為初始化基礎，為開發人員提供業務單元服務支撐框架的同時，也開發出一系列的服務治理SDK，供開發人員選用。在微服務發展背景下，SpringCloud可謂如日中天。

Dubbo

Dubbo原為阿里巴巴開源的 rpc 遠端呼叫框架，初始設計初衷在於解決以 rpc 協議為標準的遠端服務呼叫問題，隨著阿里巴巴重啟Dubbo，其也開始在服務治理領域發力，成為很多以rpc協議作為通訊基礎系統平臺的首選。粗略而言，Dubbo和SpringCloud已成為Java體系下的服務治理“雙槍”。

gRPC

gRPC與Dubbo類似，最初是由Google開源的一款遠端服務呼叫框架。gRPC憑藉HTTP/2和 RrotoBuf 服務定義方式以及多語言支援的特性，加之其易於定製與開發，能夠方面開發人員進行快速擴充套件和靈活發揮，從而也成為眾多使用者的選擇之一。

Service Mesh

Service Mesh的出現不在於它實現了多少功能，而是它徹底把業務單元與業務支撐體系分離，完整貫徹了“術業有專攻”的思想理念。它允許業務人員聚焦業務實現，不再關心服務治理相關的內容。通過與容器技術結合，下沉至基礎設施，從通訊協議的角度徹底接管業務通訊互動過程，可謂微服務治理領域的後起之秀。

總而言之，服務治理的本質是針對業務與應用產生價值的收斂與反饋，只有不斷地反饋和覆盤才能構建出穩定、高效的應用形