導(dǎo)語

?

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

作者簡介

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

騰云憶想產(chǎn)品架構(gòu)師

多年分布式、高并發(fā)電子商務(wù)系統(tǒng)的研發(fā)、系統(tǒng)架構(gòu)設(shè)計經(jīng)驗，擅長主流微服務(wù)架構(gòu)技術(shù)平臺的落地和實施
目前專注于微服務(wù)架構(gòu)相關(guān)中間件的研究推廣和最佳實踐的沉淀，致力于幫助企業(yè)完成數(shù)字化轉(zhuǎn)型。

微服務(wù)和服務(wù)治理

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

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

那么，在微服務(wù)架構(gòu)于企業(yè)中落地越來越多的當下，微服務(wù)架構(gòu)的規(guī)模越來越大、服務(wù)和實例數(shù)量越來越多，也相應(yīng)的產(chǎn)生了更高階的服務(wù)治理需求。所以，服務(wù)治理逐漸成為了新的關(guān)注重點和研究對象。

TSF和服務(wù)治理

TSF作為騰訊云針對微服務(wù)架構(gòu)管理而設(shè)計的平臺型產(chǎn)品，服務(wù)治理是平臺建設(shè)的核心價值點之一。

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

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

準備動作和落地思路

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

現(xiàn)在是否是引入服務(wù)治理的好時機？

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

引入服務(wù)治理前需要做什么準備？

?開發(fā)針對服務(wù)指定治理規(guī)則之前，還有幾項工作要提前準備，包括但不限于系統(tǒng)調(diào)研、確定立項、組織分工。

系統(tǒng)調(diào)研

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

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

確定立項

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

組織分工

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

TSF服務(wù)治理藍圖

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

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

1：標簽化管控

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

2：語言框架兼容

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

3：屏蔽底層差異

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

兩意：我們把服務(wù)治理分解為 “治”和“理”兩部分，以治作為配置手段，以理作為監(jiān)管手段。通過主動的治和被動的理的配合，形成治理規(guī)則不斷優(yōu)化和監(jiān)控效果不斷提高的正向循環(huán)，讓服務(wù)治理能力融入企業(yè)的研發(fā)流程中。

1：治

治是主動的管理動作，包括針對安全的服務(wù)鑒權(quán)，針對流量的服務(wù)限流、服務(wù)路由、服務(wù)熔斷，針對可用性的服務(wù)容錯，針對配置的應(yīng)用配置、日志配置等。

2：理

理是被動的監(jiān)控分析，包括對已運行服務(wù)指標的監(jiān)控、服務(wù)間的依賴拓撲關(guān)系、拓撲鏈路與業(yè)務(wù)日志的聯(lián)動、業(yè)務(wù)日志搜索及監(jiān)控、API統(tǒng)一管理、各類事件的匯總及告警等。

TSF-SDK通訊機制

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

TSF-SDK服務(wù)治理規(guī)則、分布式配置、網(wǎng)關(guān)規(guī)則等配置的實時更新，依賴TSF-SDK定時發(fā)起的長輪訓(xùn)機制。

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

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

結(jié)語

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

本系列技術(shù)文章將持續(xù)更新，歡迎關(guān)注，技術(shù)內(nèi)容！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。