腾云忆想技术干货|TSF微服务治理实战系列(一)——治理蓝图
導(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: python battleship_一个
- 下一篇: 关于浮点型误差的解决方法