當前，傳統企業的 IT 系統以單體架構為主，在面對互聯網業務的沖擊時，系統架構的性能瓶頸逐漸顯現。云計算、Docker、DevOps、持續交付等概念的深入人心，以 Spring Cloud 為代表的微服務框架日漸興起，微服務架構成為傳統 IT 架構轉型的集中趨勢。
在微服務化的行業洶涌浪潮里，騰訊云歷經五年磨礪，整合外部開源框架和內部 PaaS 平臺，完成了王者榮耀全球同服的毫秒級延時和春節紅包的高并發交易等性能需求，以日 5 萬億次的驚人調度次數，支撐騰訊內部海量業務的構建與發展。
微服務改造的核心思想，指通過 IT 架構的微服務化，將復雜的單體架構，重組為小而美的獨立服務，從而降低系統的復雜性，讓企業更便捷的構建基于云計算的大規模分布式架構。
本文結合騰訊云微服務架構體系的構建原理、技術選型和改造實踐，為你講講如何解決微服務部署、實施、監控余位中面臨的難題。
傳統企業 IT 架構面臨的痛點
單體架構通常在一個歸檔包里容納了所有功能的應用程序，整個項目包含的模塊種類繁雜，模塊邊界界定模糊，每個模塊之間具有強耦合性，項目復雜。大多數傳統企業在上云的過程中，由于單體架構的固定屬性，會面臨著 IT 系統復雜、升級迭代慢、運維擴展性差、海量用戶支撐能力薄弱、數據孤島等一系列問題。
如傳統企業在做電子政務、智能零售、工業 4.0 等智能化轉型，或者想要開發人臉識別 / 支付系統、關聯小程序等熱門應用時，應用體系的改變以及用戶量級的爆發式增長，都會對單體系統的性能瓶頸會提出極大的挑戰。
不同于構建單一、龐大的應用，微服務架構以小型服務的方式開發獨立應用系統，將應用拆分為一套小且互相關聯的服務，每個小型服務都運行在自己的進程中，各服務之間采用 HTTP 資源 API 輕量的機制進行通信。相對于單體架構，微服務體系在迭代速度、系統吞吐量、擴展性以及技術棧的多樣性上均有明顯的優勢。
由于單體架構的缺陷日益明顯，越來越多的公司采用微服務架構范式構建復雜應用。但在微服務的部署實施過程中，亦存在著架構與運維復雜、部署實施難度較高、問題定位困難等挑戰。
- 運維要求較高。更多的服務意味著更多的運維投入，單體架構中只需要保證一個應用的正常運行；而在微服務中，需要保證幾十甚至幾百個服務的正常運行與協作；
- 分布式固有的復雜性。使用微服務構建的是分布式系統，對于一個分布式系統，系統容錯、網絡延遲、分布式事務等對于開發者而言都是巨大的挑戰；
- 接口調整成本高。微服務之間通過接口進行通信，如果修改某個微服務的 API，可能所有使用了該接口的微服務都需要做調整；
- 重復勞動。很多服務可能都會使用到相同的功能。而這個功能并沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這一功能，導致代碼重復。
騰訊云微服務架構體系及其技術選型策略
互聯網企業的微服務轉型經驗，可為傳統行業開發者提供經驗參考。騰訊云基于自身的海量業務需求，通過 IT 架構的微服務化，將緊耦合的塔式架構，重組為小而簡的獨立服務系統，打磨出一套可用的微服務架構平臺和微服務構建方法論，實現業務之間解耦和技術棧獨立，允許低成本試錯，使團隊迭代更敏捷。
微服務構建的五大核心要素
微服務構建的初衷不外乎實現敏捷迭代、靈活擴展、服務復用三大功能，騰訊云在構建微服務的過程提煉出了以下五大方法論：
- 在線協同：對外的 API 文檔就是一份公共的說明，常有發布新的不兼容接口，因此，如何跨團隊協同、通知至關重要，這方面需要通過 swagger UI 做在線的接口定義，以此公共契約；
- 部署原則：在真實環境里，Docker 應用還未完全普及，服務的部署耗時費力?？梢試L試提供批量的自動化工具，做微服務獨立打包，批量的部署，包括啟動、停止、升級、回滾、下線等操作 ；
- 拆分原則：如常見的線上房地產交易門戶商品中心，包含運營相關的子系統如二手房推薦系統等，服務拆分得過細會帶來不必要的分布式事務、調用環節冗長等問題。各系統的拆分原則上可強調“抓大放小”；
- 數據扁平化：服務升級過程中，要注重數據模型的統一。首先，各微服務的數據層要允許有完善的權限管理系統，支持多種數據格式轉換、數據清洗、數據同步等，便于業務高效地挖掘數據的價值 ；
- 漸進性架構：大多企業和開發者很難從一開始高瞻遠矚 ，規劃處 3、5 年不變的微服務架構，因此，需要有長期的演進迭代以及小規模團隊維護，允許小團隊技術棧獨立，來擁抱業務團隊的快速試錯。
騰訊云微服務中間件 TSF 框架解析
TSF 分布式框架，歷經騰訊內部最嚴苛、最復雜的生產級環境打磨，基于上述方法論，對其中核心性能的提煉，形成了一套具備無限擴展、高性能、高可靠的一站式微服務架構解決方案，可以為云計算開發者提供極具價值的經驗參考。
如下圖為騰訊云微服務中間件 TSF 一站式解決方案，最底層是云基礎資源平臺，包括云服務器、云數據庫、云存儲和專線加速幾大模塊，用作數據的存儲和調用；同時，作為圍繞微服務的 PaaS 平臺，TSF 服務框架底層也融合了騰訊云內部大量的中間件服務，提供企業云化架構所必需的消息隊列、Kafka、負載均衡、API 網關、全局配置服務等全套中間件。
在此之上，TSF 支持應用的全生命周期管理功能，如對于虛擬機應用，提供代碼包打包上傳，批量發布、變更，版本切換等產品生命周期功能；對于火熱的 Docker 應用，提供基于行業主流編排框架 Kubernetes 的全流程自動化持續集成和持續交付。
對于已經在使用 Dubbo 框架的用戶，可以通過修改 pom.xml 中的依賴，平滑地遷移到 TSF。其中，Dubbo 存量系統遷移方式包含兩種：
- 將業務發布包中的 dubbo-registry-zookeeper.jar 包替換為 tsf-registry-consul.jar 包；
- 修改 dubbo 配置項：adress 部分替換成騰訊云提供的 url 即可使用騰訊 TSF 服務。
<dubbo:registry id="×××1" address="×××://ip:port":/> <!-- 定義注冊中心 -->
另外，在微服務運行與治理框架方面，TSF 為應用提供了自動注冊、發現、治理，隔離，調用分析等一系列微服務治理能力，用以屏蔽微服務系統帶來的復雜度。整個 TSF 框架基于 Spring Cloud，支持分布式服務發布與注冊、服務調用、服務鑒權、服務降級、服務限流、配置管理、調用鏈跟蹤等功能。
TSF 微服務框架技術選型策略
- RPC 高性能服務框架
TSF 基于 Spring Cloud 生態，提供標準 restful 服務框架，同時，鑒于分布式服務框架對性能和可靠性等能力具有極高的要求，騰訊云 TSF 在設計之初，就基于 gRPC 提供高性能 RPC 服務框架，系統地考慮了分布式服務發現、路由管理、安全、負載均衡等細節問題，滿足 100 萬 +QPS 的服務壓力。
如上圖所示，TSF 服務注冊發現包括三個角色，服務提供者，服務調用者和服務注冊中心。服務提供者和服務調用者將地址信息注冊到服務注冊中心，并從服務注冊中心獲取所有注冊服務的實例列表。TSF 使用 Consul 作為服務注冊中心，提供金融級別的兩地三中心容災部署能力。
- 構建可視化控制臺
應用是 TSF 管理的基本單位，支持 JAVA jar 包，docker 鏡像及其他語言應用（通過 service mesh）等，一個應用下面通常包含了多臺機器，TSF 提供了完整的可視化控臺，完善應用的生命周期管理機制，對分布式系統應用進行發布和管理，減少部署時間，提升部署效率。
在 TSF 控制臺上，可以設置自定義 JVM 參數。TSF 將每次操作記錄下來，用戶可以在應用的變更記錄頁面中查看和搜索變更記錄。
- 通過控制臺發布應用，包括創建、部署、啟動應用，也支持查看應用的部署狀態。
- 通過控制臺管理應用，包括回滾應用、手動擴容、縮容、刪除應用。
- 全鏈路調用跟蹤
在監控層面，TSF 采取的策略是通過全鏈路調用跟蹤技術打造一站式監控平臺，以可視化的形式，準確掌握平臺各項指標。具體實現如下圖，通過對日志埋點的收集和分析，得到一次請求在各個服務間的調用鏈關系，幫助梳理應用的請求入口與服務的調用來源、依賴關系。當遇到請求耗時較長的情況，通過調用鏈分析調用瓶頸，快速定位異常。
監控方面包括 IaaS 基礎監控和應用監控。IaaS 基礎監控的指標有實例 CPU、內存、網絡和磁盤等，應用監控的指標包括應用的 QPS, 請求時間和請求出錯率等。
分布式調用鏈分析包括調用鏈查詢和調用鏈詳情。調用鏈查詢用于查看系統中的調用鏈路狀態，尤其是慢業務和出錯業務，避免后端雪崩；調用鏈詳情是為了定位在分布式鏈路調用過程中每個環節的耗時和異常，用戶可以根據時間范圍和服務名等條件來查詢一組調用鏈，有助于提前發現架構的瓶頸點。
- 自研 TDTS 分布式事務服務
金融場景下，對數據一致性有著嚴苛要求，通常一筆交易將會跨多個業務集群。TSF 采用自研分布式事務服務中間件 TDTS，基于 TCC 模式，提供無業務侵入性、無改造數據庫改造成本的最終一致性中間件，保證每一筆交易可靠達成。
TCC 模式通過應用層的兩階段提交，可以解決數據庫的兩階段并發性能差、數據庫對 XA 協議的支持可能不完善、以及部分情況下主業務系統智能間接操作數據庫等問題。其實現原理是先執行 try, 再執行 confirm；若 try 失敗，則執行 cancel。具體事務執行流程如下：
依次調用從業務系統的 Try 接口；若 Try 階段成功，則依次調用從業務系統的 Confirm 接口；若在 Try 階段出現失敗，則調用從業務系統的 Cancel 接口，對 Try 接口的操作進行恢復；若在 Confirm 階段出現失敗，則重試，設置重試次數。若重試仍然失敗，則需要事后處理；若調用 Cancel 接口失敗，也進行重試操作；
這里，值得一提的是，TSF 可以與騰訊云多款成熟中間件產品打通，包括騰訊云 API Gateway、消息隊列 CMQ 、CKafka 等。騰訊云微服務 API Gateway 通過建立路徑到微服務 ID 的映射方式，用以提供負載均衡、熔斷等能力。
TSF 在傳統企業的微服務改造實踐
騰訊云的 TSF 分布式微服務框架雛形可追溯至 2013 年，其初期以 Devops 服務系統的形式，支撐了包括財付通、騰訊游戲、手機 QQ 等內部核心業務的架構升級。2017 年，騰訊云整合內部微服務體系，提煉出了具備金融級容災能力，高性能、高可靠的微服務解決方案，幫助傳統企業快速解決在微服務改造過程中遇到的問題。此處以某房地產為例，簡單講述 TSF 在傳統企業的微服務改造實踐。
傳統房地產企業面臨的問題
傳統房地產企業在互聯網轉型升級過程中，IT 系統架構極為復雜。因為單體 IT 架構的固有屬性，其 IT 子系統各自為戰，標準不一，無法相互通信，如會員信息、訂單信息、消費者行為記錄等多套系統鏈接分散，一旦涉及到業務變更情況，經常數百人加班參與，對后續的系統迭代帶來了巨大挑戰。
國家新型化城鎮化規劃出臺后，“城市配套服務商”的戰略一時引發熱潮，圍繞系列新業務，包括：裝修、社區教育、酒店、商辦（寫字樓）、長租公寓、養老地產、物流地產等系統協同發展，此時，傳統的 IT 架構顯然已經無法滿足新的業務發展需求。
騰訊云 TSF 微服務改造方案
騰訊云在原有的 IT 系統上，梳理出關鍵模塊和關鍵資源，同時，在云中間件的平臺上，搭建了系列抽象出來的中間件系統，包括負載均衡、API 網關服務、分布式配置、分布式事務、消息列隊服務、分布式數據庫以及騰訊云的 IaaS 能力，將獨立的 IT 系統通過微服務的方式進行管理，對于關鍵資源通過合并調用減少調用冊數，對于非關鍵資源同步異化處理，減少實施強依賴。
通過微服務改造，將房地產的業務拆分成一手房銷售系統、土地拍賣系統、營銷包裝系統與認籌系統，每個系統底下都有自己獨立的運行進程，各系統之間通過輕量級的方式進行通信，每個系統獨立而又相互連接。
此時，可以在公有云或者其他小程序上，根據自身業務需求，開發出新的應用或者系統如管家微信小程序、在線家政預約服務等，因為每個系統的運行相互獨立，新的應用即便呈現爆發式增長，也不會影響其他模塊的運行。
據悉，通過搭建分布式微服務中間件 TSF，該房地產的 IT 系統在 80 天內完成微服務架構改造上線，版本迭代平均周期從一個月變為兩周, 當有新應用時，可以快速上線互聯網應用。目前，系統每天能夠穩定處理超過 5000 萬次的系統查詢，超過 1000 萬次的訂單落地。
當然，這個項目的整體改造過程并非一蹴而就，前期主要是將一些核心系統遷移，當完成主體架構搭建后，后期再根據需求進行適當的迭代和更新。
因此，對于傳統企業的微服務架構引入策略上，建議在開始時可以考慮引入部分合適的微服務架構原則，對已有系統進行改造或新建微服務應用，然后逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。
