導語

?

隨著對微服務架構的不斷深入探索，越來越多的企業加入到了微服務架構中，體驗微服務架構在開發、運維、測試等方面帶來的優勢。同時，隨著企業中落地微服務架構的案例越來越多，管理的服務、實例數量越來越大，微服務架構的一些問題也隨之而來。本系列文章將通過對服務治理這一專題的藍圖描繪和單獨介紹，與讀者一起探討微服務治理能力在諸多場景中的實戰應用。

作者簡介

崔凱? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

騰云憶想產品架構師

多年分布式、高并發電子商務系統的研發、系統架構設計經驗，擅長主流微服務架構技術平臺的落地和實施
目前專注于微服務架構相關中間件的研究推廣和最佳實踐的沉淀，致力于幫助企業完成數字化轉型。

微服務和服務治理

微服務架構大約在2011年威尼斯的一個軟件架構會議上被提出，到2014年由Martin Fowler、James Lewis共同發表文章《Microservices:a definition of this new architectural term》讓微服務紅極一時，到今天已10年有余。

在這段發展進程中，微服務從被人質疑到成為當前云原生趨勢中不可或缺的角色，從一個概念到擁有相對完善的落地體系和方法論，其中都包含著對微服務架構不斷的探索和堅持。

那么，在微服務架構于企業中落地越來越多的當下，微服務架構的規模越來越大、服務和實例數量越來越多，也相應的產生了更高階的服務治理需求。所以，服務治理逐漸成為了新的關注重點和研究對象。

TSF和服務治理

TSF作為騰訊云針對微服務架構管理而設計的平臺型產品，服務治理是平臺建設的核心價值點之一。

本實戰系列主要討論范圍包括TSF平臺中服務路由、服務鑒權、服務限流、服務熔斷容錯、服務可觀測性、服務配置等服務治理核心能力（如下圖“微服務框架”中所示）。

通過針對上述內容的介紹，可以系統性地幫助讀者了解TSF在服務治理方面的核心能力，及針對企業自身場景應如何選擇匹配的場景和動作。如針對電商大促的場景如何進行限流、針對灰度版本如何進行全鏈路灰度發布等，幫助TSF平臺使用者實際解決服務治理相關的流量管控、鏈路排障、配置管理等一系列問題。

準備動作和落地思路

在詳細了解TSF服務治理各項能力之前，有幾個問題需要“捫心自問”。

現在是否是引入服務治理的好時機？

服務治理并不是銀彈，服務規模和流量都比較小的初創企業，適用服務治理的場景并不多。而對于一些中大型企業，服務及實例的數量、并發數及流量、DB數據量等都開始爆發性增長，服務治理才有其存在的必要性。另外，系統要基本完成微服務架構的轉型，這個轉型包括面向團隊、管理、中間件平臺等的轉變，最好也已完成容器化，這樣可以借助容器平臺來提高治理效率。

引入服務治理前需要做什么準備？

?開發針對服務指定治理規則之前，還有幾項工作要提前準備，包括但不限于系統調研、確定立項、組織分工。

系統調研

在開展服務治理工作之前，要對系統的必要信息充分了解，需要從一線最了解的同學那里匯總，如下表示例所示：

調研事項	調研內容
業務簡介	簡單介紹業務的功能和業務邏輯
應用架構	通過應用架構圖闡述代碼、模塊間關系及服務間依賴等，使用的開發框架、語言等
物理架構	展示物理部署圖、調用關系圖
數據量及并發	描述當前數據量及并發量的峰值、均值及如何發展
當前治理方式	描述當前已經使用了哪些服務治理框架、工具
中間件	限流、路由等一些治理能力需要兼容MQ、Redis等一些中間件
支撐平臺	DevOps、容器平臺、監控告警平臺等
現存問題	描述在流量控制、配置管理等服務治理方面現存的客戶痛點問題

確定立項

管理者與研發團隊完成對服務治理目標、面對的挑戰和成本等方面的討論，確定服務治理項目組并立項。其中，服務治理目標的確定應盡量務實，以是否解決實際問題入手，而不是“把這些高大上的治理能力都用上”。對于服務治理的成本預估，除了選型的沉沒成本、學習成本、開發成本，還有關鍵的上線成本，一定關注開發的review和測試的準入準出，避免開發人員和測試人員對非功能性需求“不自覺的松懈”。

組織分工

細化服務治理工作，從項目管理條線和技術開發條線分別規劃。項目管理條線需要依次確認服務治理階段及階段目標，將服務治理劃分為各專項小組并確立接口人和匯報方式，制定從開發、測試、投產保障、運維監控到培訓賦能的服務治理落地計劃，確保服務治理的功能真正能在企業中用起來。技術條線除了完成服務治理上線所需的代碼改動和發布，還需要逐步完善《服務治理FAQ》《服務治理規范手冊》等一系列知識沉淀，與《服務治理待辦清單》共同形成迭代閉環，使得服務治理建設可持續優化。

TSF服務治理藍圖

?在完成了前期的準備工作之后，需要先簡單介紹一下TSF服務治理的藍圖，以便能對服務治理有個大致全面的概覽。雖然TSF服務治理涉及到很多方面，但總體來說，小編將它概括為 “三心兩意”。

三心：所有的服務治理能力都是基于標簽化管控、語言框架兼容、屏蔽底層差異三個核心來設計的。

1：標簽化管控

?指針對TSF服務治理各項能力針對不同的管控場景，提供了粗粒度的系統標簽和細粒度的自定義標簽兩種管控粒度。系統標簽根據TSF自身設計原語劃分，如部署組、服務、應用、版本等；自定義標簽根據用戶自身業務屬性劃分，將控制粒度細化到每一個請求上，如用戶ID、時間、地域、用戶類別等。通過不同的管控粒度，平衡治理的成本和收益。

2：語言框架兼容

?由于使用了不同的語言、開發框架、通訊協議，就需要不同版本的SDK、不同形態的框架對接代碼、不同的調用方式，這種凌亂的形式給整個研發團隊帶來了巨大的負擔。比如SDK升級，首先要針對不同語言開發SDK，其次要針對不同開發框架做兼容，最后在升級的時候還要協調各個團隊的升級時機，挑戰非常巨大。TSF通過統一的管控平臺，同時兼容Spring Cloud、Service Mesh及Dubbo框架，兼容HTTP、gRPC等多種協議，拉平了語言、框架、協議方面的差異，讓用戶專注于業務本身。

3：屏蔽底層差異

?TSF作為一套通用的微服務技術平臺，在各行各業都有不少落地案例。這就要求TSF必須具備適配客戶各類硬件資源、操作系統及已有架構，才能幫助客戶完成快速落地的目標。TSF可以適配目前主流的虛擬機、容器平臺，甚至某些場景下的物理機，國產及騰訊云自研操作系統，以及一些舊有的架構體系。通過屏蔽這些差異，避免曾經在各種平臺間切來切去的煩惱，讓用戶體驗“同一套平臺，同一種感受”。

兩意：我們把服務治理分解為 “治”和“理”兩部分，以治作為配置手段，以理作為監管手段。通過主動的治和被動的理的配合，形成治理規則不斷優化和監控效果不斷提高的正向循環，讓服務治理能力融入企業的研發流程中。

1：治

治是主動的管理動作，包括針對安全的服務鑒權，針對流量的服務限流、服務路由、服務熔斷，針對可用性的服務容錯，針對配置的應用配置、日志配置等。

2：理

理是被動的監控分析，包括對已運行服務指標的監控、服務間的依賴拓撲關系、拓撲鏈路與業務日志的聯動、業務日志搜索及監控、API統一管理、各類事件的匯總及告警等。

TSF-SDK通訊機制

TSF-SDK各項服務治理能力總體上依賴了同一套架構，下圖以Spring Cloud應用為示例。整個通訊過程主要包括租戶端的TSF-SDK，管控端的consul接入層、服務治理組件、瀏覽器。TSF-SDK通過pom引用內嵌在JAVA應用中，consul接入層負責與租戶端各服務的TSF-SDK連通，服務治理組件為提供各項服務治理邏輯的無狀態組件，瀏覽器主要供管理員通過控制臺頁面創建各類服務治理規則和配置。

TSF-SDK服務治理規則、分布式配置、網關規則等配置的實時更新，依賴TSF-SDK定時發起的長輪訓機制。

TSF-SDK的整個監聽過程分為兩種情況：阻塞時有內容更新、阻塞時無內容更新。在服務（應用）完成注冊發現之后，TSF-SDK向Consul接入層發起一個長輪詢請求，以便應用側可以實時上報數據，同時實時接收管控端下發的規則、應用配置等數據。當在長輪詢請求有效期內發生了治理規則推送，那么長輪詢請求立刻返回被更新的內容給TSF-SDK；當長輪詢請求持續等待直到超過了最大等待時間，請求也會返回，同時發起下次長輪詢請求，以避免連接無限期等待帶來的風險。

當TSF-SDK拿到治理規則或配置后，實時更新本地內容，并根據SDK內邏輯進行服務路由、服務鑒權、服務限流等一系列操作。整體流程基本相似，只是下發內容和SDK處理邏輯不同。

結語

服務治理并不適用于所有場景，尤其不同的業務場景需要對應的治理規則和參數配置，用的不好反而會成為業務的累贅。本實戰系列的目的也在于此，通過深入TSF各項服務治理能力和落地場景，讓讀者朋友了解TSF服務治理的正確打開方式，實現構建完整的服務治理體系的目標，通過治理手段提高業務可用性，幫助企業降本增效。

本系列技術文章將持續更新，歡迎關注，技術內容！

總結

以上是生活随笔為你收集整理的腾云忆想技术干货|TSF微服务治理实战系列（一）——治理蓝图的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。