寫在前面

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

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

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

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

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

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

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

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

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

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

騰訊云微服務架構體系及其技術選型策略

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

微服務構建的五大核心要素

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

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

騰訊云微服務中間件TSF框架解析

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

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

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

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

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

<dubbo:registry id="×××1" address="×××://ip:port":/> <!--定義注冊中心-->

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

TSF微服務框架技術選型策略

• RPC高性能服務框架

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

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

• 構建可視化控制臺

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

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

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

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

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

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

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

• 自研TDTS分布式事務服務

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

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

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

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

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

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

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

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

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

騰訊云TSF微服務改造方案

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

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

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

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

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

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

 

來自：http://www.infoq.com/cn/news/2018/02/deep-interpretation-TSF-cloud-mi

 

標簽： 安全 代碼 服務器 服務商 公有云 互聯(lián)網(wǎng) 互聯(lián)網(wǎng)企業(yè) 互聯(lián)網(wǎng)業(yè)務 金融 開發(fā)者 權限 權限管理 數(shù)據(jù)庫 搜索 通信 網(wǎng)絡 云服務 云服務器 云計算 云計算開發(fā)

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。