應用量化時代 | 微服務架構的服務治理之路

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

近些年來，伴随數字經濟的發展，在衆多企業的數字化轉型之路上，雲原生、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的出現不在于它實作了多少功能，而是它徹底把業務單元與業務支撐體系分離，完整貫徹了“術業有專攻”的思想理念。它允許業務人員聚焦業務實作，不再關心服務治理相關的内容。通過與容器技術結合，下沉至基礎設施，從通信協定的角度徹底接管業務通信互動過程，可謂微服務治理領域的後起之秀。

總而言之，服務治理的本質是針對業務與應用産生價值的收斂與回報，隻有不斷地回報和複盤才能建構出穩定、高效的應用形态。