日調(diào)度5萬億次騰訊云微服務(wù)架構(gòu)體系TSF深度解讀

xujin3 2018-06-10

展開全文

接收程序員的 8 點技術(shù)早餐

1 寫在前面

當前，傳統(tǒng)企業(yè)的 IT 系統(tǒng)以單體架構(gòu)為主，在面對互聯(lián)網(wǎng)業(yè)務(wù)的沖擊時，系統(tǒng)架構(gòu)的性能瓶頸逐漸顯現(xiàn)。云計算、Docker、DevOps、持續(xù)交付等概念的深入人心，以 Spring Cloud 為代表的微服務(wù)框架日漸興起，微服務(wù)架構(gòu)成為傳統(tǒng) IT 架構(gòu)轉(zhuǎn)型的集中趨勢。

在微服務(wù)化的行業(yè)洶涌浪潮里，騰訊云歷經(jīng)五年磨礪，整合外部開源框架和內(nèi)部 PaaS 平臺，完成了王者榮耀全球同服的毫秒級延時和春節(jié)紅包的高并發(fā)交易等性能需求，以日 5 萬億次的驚人調(diào)度次數(shù)，支撐騰訊內(nèi)部海量業(yè)務(wù)的構(gòu)建與發(fā)展。

微服務(wù)改造的核心思想，指通過 IT 架構(gòu)的微服務(wù)化，將復(fù)雜的單體架構(gòu)，重組為小而美的獨立服務(wù)，從而降低系統(tǒng)的復(fù)雜性，讓企業(yè)更便捷的構(gòu)建基于云計算的大規(guī)模分布式架構(gòu)。

本文結(jié)合騰訊云微服務(wù)架構(gòu)體系的構(gòu)建原理、技術(shù)選型和改造實踐，為你講講如何解決微服務(wù)部署、實施、監(jiān)控余位中面臨的難題。

2 傳統(tǒng)企業(yè) IT 架構(gòu)面臨的痛點

單體架構(gòu)通常在一個歸檔包里容納了所有功能的應(yīng)用程序，整個項目包含的模塊種類繁雜，模塊邊界界定模糊，每個模塊之間具有強耦合性，項目復(fù)雜。大多數(shù)傳統(tǒng)企業(yè)在上云的過程中，由于單體架構(gòu)的固定屬性，會面臨著 IT 系統(tǒng)復(fù)雜、升級迭代慢、運維擴展性差、海量用戶支撐能力薄弱、數(shù)據(jù)孤島等一系列問題。

如傳統(tǒng)企業(yè)在做電子政務(wù)、智能零售、工業(yè) 4.0 等智能化轉(zhuǎn)型，或者想要開發(fā)人臉識別 / 支付系統(tǒng)、關(guān)聯(lián)小程序等熱門應(yīng)用時，應(yīng)用體系的改變以及用戶量級的爆發(fā)式增長，都會對單體系統(tǒng)的性能瓶頸會提出極大的挑戰(zhàn)。

不同于構(gòu)建單一、龐大的應(yīng)用，微服務(wù)架構(gòu)以小型服務(wù)的方式開發(fā)獨立應(yīng)用系統(tǒng)，將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)，每個小型服務(wù)都運行在自己的進程中，各服務(wù)之間采用 HTTP 資源 API 輕量的機制進行通信。相對于單體架構(gòu)，微服務(wù)體系在迭代速度、系統(tǒng)吞吐量、擴展性以及技術(shù)棧的多樣性上均有明顯的優(yōu)勢。

由于單體架構(gòu)的缺陷日益明顯，越來越多的公司采用微服務(wù)架構(gòu)范式構(gòu)建復(fù)雜應(yīng)用。但在微服務(wù)的部署實施過程中，亦存在著架構(gòu)與運維復(fù)雜、部署實施難度較高、問題定位困難等挑戰(zhàn)。

運維要求較高。更多的服務(wù)意味著更多的運維投入，單體架構(gòu)中只需要保證一個應(yīng)用的正常運行；而在微服務(wù)中，需要保證幾十甚至幾百個服務(wù)的正常運行與協(xié)作；
分布式固有的復(fù)雜性。使用微服務(wù)構(gòu)建的是分布式系統(tǒng)，對于一個分布式系統(tǒng)，系統(tǒng)容錯、網(wǎng)絡(luò)延遲、分布式事務(wù)等對于開發(fā)者而言都是巨大的挑戰(zhàn)；
接口調(diào)整成本高。微服務(wù)之間通過接口進行通信，如果修改某個微服務(wù)的 API，可能所有使用了該接口的微服務(wù)都需要做調(diào)整；
重復(fù)勞動。很多服務(wù)可能都會使用到相同的功能。而這個功能并沒有達到分解為一個微服務(wù)的程度，這個時候，可能各個服務(wù)都會開發(fā)這一功能，導(dǎo)致代碼重復(fù)。

3 騰訊云微服務(wù)架構(gòu)體系及其技術(shù)選型策略

互聯(lián)網(wǎng)企業(yè)的微服務(wù)轉(zhuǎn)型經(jīng)驗，可為傳統(tǒng)行業(yè)開發(fā)者提供經(jīng)驗參考。騰訊云基于自身的海量業(yè)務(wù)需求，通過 IT 架構(gòu)的微服務(wù)化，將緊耦合的塔式架構(gòu)，重組為小而簡的獨立服務(wù)系統(tǒng)，打磨出一套可用的微服務(wù)架構(gòu)平臺和微服務(wù)構(gòu)建方法論，實現(xiàn)業(yè)務(wù)之間解耦和技術(shù)棧獨立，允許低成本試錯，使團隊迭代更敏捷。

微服務(wù)構(gòu)建的五大核心要素

微服務(wù)構(gòu)建的初衷不外乎實現(xiàn)敏捷迭代、靈活擴展、服務(wù)復(fù)用三大功能，騰訊云在構(gòu)建微服務(wù)的過程提煉出了以下五大方法論：

在線協(xié)同：對外的 API 文檔就是一份公共的說明，常有發(fā)布新的不兼容接口，因此，如何跨團隊協(xié)同、通知至關(guān)重要，這方面需要通過 swagger UI 做在線的接口定義，以此公共契約；
部署原則：在真實環(huán)境里，Docker 應(yīng)用還未完全普及，服務(wù)的部署耗時費力?？梢試L試提供批量的自動化工具，做微服務(wù)獨立打包，批量的部署，包括啟動、停止、升級、回滾、下線等操作；
拆分原則：如常見的線上房地產(chǎn)交易門戶商品中心，包含運營相關(guān)的子系統(tǒng)如二手房推薦系統(tǒng)等，服務(wù)拆分得過細會帶來不必要的分布式事務(wù)、調(diào)用環(huán)節(jié)冗長等問題。各系統(tǒng)的拆分原則上可強調(diào)“抓大放小”；
數(shù)據(jù)扁平化：服務(wù)升級過程中，要注重數(shù)據(jù)模型的統(tǒng)一。首先，各微服務(wù)的數(shù)據(jù)層要允許有完善的權(quán)限管理系統(tǒng)，支持多種數(shù)據(jù)格式轉(zhuǎn)換、數(shù)據(jù)清洗、數(shù)據(jù)同步等，便于業(yè)務(wù)高效地挖掘數(shù)據(jù)的價值；
漸進性架構(gòu)：大多企業(yè)和開發(fā)者很難從一開始高瞻遠矚，規(guī)劃處 3、5 年不變的微服務(wù)架構(gòu)，因此，需要有長期的演進迭代以及小規(guī)模團隊維護，允許小團隊技術(shù)棧獨立，來擁抱業(yè)務(wù)團隊的快速試錯。

騰訊云微服務(wù)中間件 TSF 框架解析

TSF 分布式框架，歷經(jīng)騰訊內(nèi)部最嚴苛、最復(fù)雜的生產(chǎn)級環(huán)境打磨，基于上述方法論，對其中核心性能的提煉，形成了一套具備無限擴展、高性能、高可靠的一站式微服務(wù)架構(gòu)解決方案，可以為云計算開發(fā)者提供極具價值的經(jīng)驗參考。

如下圖為騰訊云微服務(wù)中間件 TSF 一站式解決方案，最底層是云基礎(chǔ)資源平臺，包括云服務(wù)器、云數(shù)據(jù)庫、云存儲和專線加速幾大模塊，用作數(shù)據(jù)的存儲和調(diào)用；同時，作為圍繞微服務(wù)的 PaaS 平臺，TSF 服務(wù)框架底層也融合了騰訊云內(nèi)部大量的中間件服務(wù)，提供企業(yè)云化架構(gòu)所必需的消息隊列、Kafka、負載均衡、API 網(wǎng)關(guān)、全局配置服務(wù)等全套中間件。

在此之上，TSF 支持應(yīng)用的全生命周期管理功能，如對于虛擬機應(yīng)用，提供代碼包打包上傳，批量發(fā)布、變更，版本切換等產(chǎn)品生命周期功能；對于火熱的 Docker 應(yīng)用，提供基于行業(yè)主流編排框架 Kubernetes 的全流程自動化持續(xù)集成和持續(xù)交付。

對于已經(jīng)在使用 Dubbo 框架的用戶，可以通過修改 pom.xml 中的依賴，平滑地遷移到 TSF。其中，Dubbo 存量系統(tǒng)遷移方式包含兩種：

將業(yè)務(wù)發(fā)布包中的 dubbo-registry-zookeeper.jar 包替換為 tsf-registry-consul.jar 包；
修改 dubbo 配置項：adress 部分替換成騰訊云提供的 url 即可使用騰訊 TSF 服務(wù)。

另外，在微服務(wù)運行與治理框架方面，TSF 為應(yīng)用提供了自動注冊、發(fā)現(xiàn)、治理，隔離，調(diào)用分析等一系列微服務(wù)治理能力，用以屏蔽微服務(wù)系統(tǒng)帶來的復(fù)雜度。整個 TSF 框架基于 Spring Cloud，支持分布式服務(wù)發(fā)布與注冊、服務(wù)調(diào)用、服務(wù)鑒權(quán)、服務(wù)降級、服務(wù)限流、配置管理、調(diào)用鏈跟蹤等功能。

TSF 微服務(wù)框架技術(shù)選型策略

RPC 高性能服務(wù)框架

TSF 基于 Spring Cloud 生態(tài)，提供標準 restful 服務(wù)框架，同時，鑒于分布式服務(wù)框架對性能和可靠性等能力具有極高的要求，騰訊云 TSF 在設(shè)計之初，就基于 gRPC 提供高性能 RPC 服務(wù)框架，系統(tǒng)地考慮了分布式服務(wù)發(fā)現(xiàn)、路由管理、安全、負載均衡等細節(jié)問題，滿足 100 萬 +QPS 的服務(wù)壓力。

如上圖所示，TSF 服務(wù)注冊發(fā)現(xiàn)包括三個角色，服務(wù)提供者，服務(wù)調(diào)用者和服務(wù)注冊中心。服務(wù)提供者和服務(wù)調(diào)用者將地址信息注冊到服務(wù)注冊中心，并從服務(wù)注冊中心獲取所有注冊服務(wù)的實例列表。TSF 使用 Consul 作為服務(wù)注冊中心，提供金融級別的兩地三中心容災(zāi)部署能力。

構(gòu)建可視化控制臺

應(yīng)用是 TSF 管理的基本單位，支持 Java jar 包，docker 鏡像及其他語言應(yīng)用（通過 service mesh）等，一個應(yīng)用下面通常包含了多臺機器，TSF 提供了完整的可視化控臺，完善應(yīng)用的生命周期管理機制，對分布式系統(tǒng)應(yīng)用進行發(fā)布和管理，減少部署時間，提升部署效率。

在 TSF 控制臺上，可以設(shè)置自定義 JVM 參數(shù)。TSF 將每次操作記錄下來，用戶可以在應(yīng)用的變更記錄頁面中查看和搜索變更記錄。

通過控制臺發(fā)布應(yīng)用，包括創(chuàng)建、部署、啟動應(yīng)用，也支持查看應(yīng)用的部署狀態(tài)。
通過控制臺管理應(yīng)用，包括回滾應(yīng)用、手動擴容、縮容、刪除應(yīng)用。

全鏈路調(diào)用跟蹤

在監(jiān)控層面，TSF 采取的策略是通過全鏈路調(diào)用跟蹤技術(shù)打造一站式監(jiān)控平臺，以可視化的形式，準確掌握平臺各項指標。具體實現(xiàn)如下圖，通過對日志埋點的收集和分析，得到一次請求在各個服務(wù)間的調(diào)用鏈關(guān)系，幫助梳理應(yīng)用的請求入口與服務(wù)的調(diào)用來源、依賴關(guān)系。當遇到請求耗時較長的情況，通過調(diào)用鏈分析調(diào)用瓶頸，快速定位異常。

監(jiān)控方面包括 IaaS 基礎(chǔ)監(jiān)控和應(yīng)用監(jiān)控。IaaS 基礎(chǔ)監(jiān)控的指標有實例 CPU、內(nèi)存、網(wǎng)絡(luò)和磁盤等，應(yīng)用監(jiān)控的指標包括應(yīng)用的 QPS, 請求時間和請求出錯率等。

分布式調(diào)用鏈分析包括調(diào)用鏈查詢和調(diào)用鏈詳情。調(diào)用鏈查詢用于查看系統(tǒng)中的調(diào)用鏈路狀態(tài)，尤其是慢業(yè)務(wù)和出錯業(yè)務(wù)，避免后端雪崩；調(diào)用鏈詳情是為了定位在分布式鏈路調(diào)用過程中每個環(huán)節(jié)的耗時和異常，用戶可以根據(jù)時間范圍和服務(wù)名等條件來查詢一組調(diào)用鏈，有助于提前發(fā)現(xiàn)架構(gòu)的瓶頸點。

自研 TDTS 分布式事務(wù)服務(wù)

金融場景下，對數(shù)據(jù)一致性有著嚴苛要求，通常一筆交易將會跨多個業(yè)務(wù)集群。TSF 采用自研分布式事務(wù)服務(wù)中間件 TDTS，基于 TCC 模式，提供無業(yè)務(wù)侵入性、無改造數(shù)據(jù)庫改造成本的最終一致性中間件，保證每一筆交易可靠達成。

TCC 模式通過應(yīng)用層的兩階段提交，可以解決數(shù)據(jù)庫的兩階段并發(fā)性能差、數(shù)據(jù)庫對 XA 協(xié)議的支持可能不完善、以及部分情況下主業(yè)務(wù)系統(tǒng)智能間接操作數(shù)據(jù)庫等問題。其實現(xiàn)原理是先執(zhí)行 try, 再執(zhí)行 confirm；若 try 失敗，則執(zhí)行 cancel。具體事務(wù)執(zhí)行流程如下：

依次調(diào)用從業(yè)務(wù)系統(tǒng)的 Try 接口；
若 Try 階段成功，則依次調(diào)用從業(yè)務(wù)系統(tǒng)的 Confirm 接口；
若在 Try 階段出現(xiàn)失敗，則調(diào)用從業(yè)務(wù)系統(tǒng)的 Cancel 接口，對 Try 接口的操作進行恢復(fù)；
若在 Confirm 階段出現(xiàn)失敗，則重試，設(shè)置重試次數(shù)。若重試仍然失敗，則需要事后處理；
若調(diào)用 Cancel 接口失敗，也進行重試操作；

這里，值得一提的是，TSF 可以與騰訊云多款成熟中間件產(chǎn)品打通，包括騰訊云 API Gateway、消息隊列 CMQ 、CKafka 等。騰訊云微服務(wù) API Gateway 通過建立路徑到微服務(wù) ID 的映射方式，用以提供負載均衡、熔斷等能力。

4 TSF 在傳統(tǒng)企業(yè)的微服務(wù)改造實踐

騰訊云的 TSF 分布式微服務(wù)框架雛形可追溯至 2013 年，其初期以 Devops 服務(wù)系統(tǒng)的形式，支撐了包括財付通、騰訊游戲、手機 QQ 等內(nèi)部核心業(yè)務(wù)的架構(gòu)升級。2017 年，騰訊云整合內(nèi)部微服務(wù)體系，提煉出了具備金融級容災(zāi)能力，高性能、高可靠的微服務(wù)解決方案，幫助傳統(tǒng)企業(yè)快速解決在微服務(wù)改造過程中遇到的問題。此處以某房地產(chǎn)為例，簡單講述 TSF 在傳統(tǒng)企業(yè)的微服務(wù)改造實踐。

傳統(tǒng)房地產(chǎn)企業(yè)面臨的問題

傳統(tǒng)房地產(chǎn)企業(yè)在互聯(lián)網(wǎng)轉(zhuǎn)型升級過程中，IT 系統(tǒng)架構(gòu)極為復(fù)雜。因為單體 IT 架構(gòu)的固有屬性，其 IT 子系統(tǒng)各自為戰(zhàn)，標準不一，無法相互通信，如會員信息、訂單信息、消費者行為記錄等多套系統(tǒng)鏈接分散，一旦涉及到業(yè)務(wù)變更情況，經(jīng)常數(shù)百人加班參與，對后續(xù)的系統(tǒng)迭代帶來了巨大挑戰(zhàn)。

國家新型化城鎮(zhèn)化規(guī)劃出臺后，“城市配套服務(wù)商”的戰(zhàn)略一時引發(fā)熱潮，圍繞系列新業(yè)務(wù)，包括：裝修、社區(qū)教育、酒店、商辦（寫字樓）、長租公寓、養(yǎng)老地產(chǎn)、物流地產(chǎn)等系統(tǒng)協(xié)同發(fā)展，此時，傳統(tǒng)的 IT 架構(gòu)顯然已經(jīng)無法滿足新的業(yè)務(wù)發(fā)展需求。

騰訊云 TSF 微服務(wù)改造方案

騰訊云在原有的 IT 系統(tǒng)上，梳理出關(guān)鍵模塊和關(guān)鍵資源，同時，在云中間件的平臺上，搭建了系列抽象出來的中間件系統(tǒng)，包括負載均衡、API 網(wǎng)關(guān)服務(wù)、分布式配置、分布式事務(wù)、消息列隊服務(wù)、分布式數(shù)據(jù)庫以及騰訊云的 IaaS 能力，將獨立的 IT 系統(tǒng)通過微服務(wù)的方式進行管理，對于關(guān)鍵資源通過合并調(diào)用減少調(diào)用冊數(shù)，對于非關(guān)鍵資源同步異化處理，減少實施強依賴。

通過微服務(wù)改造，將房地產(chǎn)的業(yè)務(wù)拆分成一手房銷售系統(tǒng)、土地拍賣系統(tǒng)、營銷包裝系統(tǒng)與認籌系統(tǒng)，每個系統(tǒng)底下都有自己獨立的運行進程，各系統(tǒng)之間通過輕量級的方式進行通信，每個系統(tǒng)獨立而又相互連接。

此時，可以在公有云或者其他小程序上，根據(jù)自身業(yè)務(wù)需求，開發(fā)出新的應(yīng)用或者系統(tǒng)如管家微信小程序、在線家政預(yù)約服務(wù)等，因為每個系統(tǒng)的運行相互獨立，新的應(yīng)用即便呈現(xiàn)爆發(fā)式增長，也不會影響其他模塊的運行。

據(jù)悉，通過搭建分布式微服務(wù)中間件 TSF，該房地產(chǎn)的 IT 系統(tǒng)在 80 天內(nèi)完成微服務(wù)架構(gòu)改造上線，版本迭代平均周期從一個月變?yōu)閮芍? 當有新應(yīng)用時，可以快速上線互聯(lián)網(wǎng)應(yīng)用。目前，系統(tǒng)每天能夠穩(wěn)定處理超過 5000 萬次的系統(tǒng)查詢，超過 1000 萬次的訂單落地。

當然，這個項目的整體改造過程并非一蹴而就，前期主要是將一些核心系統(tǒng)遷移，當完成主體架構(gòu)搭建后，后期再根據(jù)需求進行適當?shù)牡透隆?/p>

因此，對于傳統(tǒng)企業(yè)的微服務(wù)架構(gòu)引入策略上，建議在開始時可以考慮引入部分合適的微服務(wù)架構(gòu)原則，對已有系統(tǒng)進行改造或新建微服務(wù)應(yīng)用，然后逐步探索及積累微服務(wù)架構(gòu)經(jīng)驗，而非全盤實施微服務(wù)架構(gòu)。