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

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

 

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

 

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