自從去年 10 月份搜狗正式被騰訊合并以后，我一直想給大家講講騰訊內部目前開發在用的一些技術棧，我想這對同學們有很高的學習價值。但苦于公司內部有明確的規定，不允許私自對外分享和發布未經公開的信息。一經發現，高壓線開除處理！所以一直遲遲都沒有動手。

最近我在騰訊的 TechoDay 技術開放日活動中了解到內部在使用的微服務核心北極星（Polaris-Mesh）和一站式微服務開發框架 Spring Cloud Tencent 都已經對外開放了。

北極星 Github：https://github.com/polarismesh

Spring Cloud Tencent：https://github.com/Tencent/spring-cloud-tencent

那我今天就可以結合它們來給大家簡單聊聊騰訊內部在用的微服務體系了。

一、為什么要擁抱微服務

我是 2011 年進入騰訊的，那個時候使用的技術棧主要是 LAMP（linux + Apache + MySQL + php）。當時業界還有另外一套流行的技術棧是 MVC（Spring + iBatis/Hibernate + Tomcat）。無論是 LAMP 還是 MVC，都是為單體因共用架構而設計的。開發出來的服務也是部署在物理服務器上，一般都是由運維來部署的。

在 web 網頁的時代，上面兩套技術棧切切實實火了很長的時間。但隨著移動互聯網的爆發，要開發的服務越來越多，功能也越來越雜，團隊開發人員也不斷地擴張，發布頻率越來越高。傳統的單體服務的架構就逐漸呈現出了這么幾個問題。

部署服務效率低下：傳統的單體服務直接部署在物理機或虛擬機上，服務運行所依賴的軟件都得由運維手工去安裝和配置。

機器資源很難被復用：現代的服務器配置都是非常的高，但是要運行的單體服務很少有一個服務就能把 CPU、內存等資源都充分利用起來的，會有大量的閑置。但為了保證服務之間的隔離，又往往不敢把多個不想干的服務部署在一起。

團隊協作成本高 當有多個人負責同一個服務的時候，難免就會出現提交代碼互相影響的情況，發布也是得商量著來。另外就是每次版本發布前的測試工作也是得需要很全面才行。

在后來，就慢慢衍生出了服務的概念。把單體應用拆分成多個不同的服務獨立進行部署和發布。比如我當年負責的搜狗手機助手，在后臺就是分成了應用推薦列表、應用檢查更新、搜索、精準推薦、云端控制、地址定位等等多個獨立的服務出來。

在 2014 年開始， Docker 容器開始大行其道，虛擬化程度相比較之前的 KVM 有了質的飛越。一個容器鏡像就可以將服務所依賴的軟件環境全部打包在一起，最小的情況下只要十幾 M 就搞定，分發起來非常自由和方便。啟動更是秒級就可以啟動起來。

業界圍繞容器技術又進行了一系列的演化和迭代，逐步演化出了今天的微服務架構。微服務的熱度在 2017 年后突然爆發，各大一線互聯網公司也紛紛將這一技術引入并在實際業務中落地，騰訊也不例外。

二、騰訊的微服務引擎

很早騰訊內部各個部門就不同程度地開始試水微服務了。在 2020 年又在公司內部將之前的多套微服務框架進行整合，誕生出了現在的以 tPRC 為核心的微服務框架。現在絕大部分的服務和接口幾乎都已經切到了基于容器的微服務架構上了。

在騰訊也好，業界也罷。微服務架構雖然在細節的技術選型上會有所差異。但基本上都可以如下一張微服務架構圖來表示。

在這個微服務架構中，左右兩側分別都是微服務的基礎設施，中間是開發框架。在這些基礎組件中，我覺得最重要和核心的就屬上圖左側的網關、名字服務北極星、以及配置中心。這也正是騰訊對外的云微服務引擎（Tencent Cloud Service Engine，TSE）所對外開放的能力。

所以接下來我就這三個展開了給大家講一講。

2.1 云網關

在單體應用時代，在接入層的做法一般就是申請一個外網域名，然后在接入層按照域名將請求分發到不同的業務服務器上。

在微服務架構中，網關仍然是流量的入口。不過到了微服務時代后，服務的數量比之前要多很多。再也無法直接按照一個域名一個服務的方式進行配置了，而且微服務場景下對路由、監控配置管理等方面的需求更為強烈。

所以這時就需要一個微服務網關，作為所有 API 接口的總入口。網關對后端的微服務進行封裝，通過 API 網關統一暴露服務。在網關中提供統一的安全、路由、流控、監控等服務。當有流量到達的時候，網關進行一些預處理后實現根據不同的服務名進行流量的分發。

2.2 服務治理中心

騰訊的服務治理組件叫北極星。該項目最早是騰訊內部開源協同共建的統一名字服務組件，用于解決 RPC 調用的服務注冊、動態路由、負載均衡和容錯問題。

現在北極星不但部署到了騰訊云上對外提供服務能力，而且還入駐了開源社區。該項目一上線就受到了業界的廣泛關注。

Github 地址：https://github.com/polarismesh

該項目不僅僅是把源碼全部開源出來了，而且還配置了詳細的使用文檔。

我接下來給大家介紹一下這個開源項目 Polaris Mesh 解決的問題和所提供的能力。

在微服務架構里，首先要解決的一個問題就是如何找到你要調用的服務。在一家大公司里，可能線上有成千上萬個服務同時在運行。那么當你的服務想調用某個服務的時候，如何正確找到對應的服務并進行訪問呢？

這個問題就是通過北極星 Polaris Mesh 的服務注冊與發現機制來解決。服務提供方在啟動時會向 Polaris Mesh 注冊自己的服務名以及服務地址。當調用方需要調用的通過在進程內部內嵌的 Proxy 代理先到 Polaris Mesh 獲取要調用的服務地址，找到后直接發起調用。

一般情況下服務提供方都是有多個實例的，那么到底該選擇哪一個來進行訪問呢？有這么兩種不同的使用場景。

一種使用場景是分組，比如你的服務調用方和服務提供方可能是多地部署的，在Linux 網絡性能的 15 個優化建議！一文中我們提到過最好是在同機房內部來進行服務調用。要避免跨機房調用。因為這會導致過長的耗時。再比如你可能需要單獨部署測試環境，和灰度環境等等。

還有一種應用場景是負載均衡，即使是同環境同機房，可能各個服務提供實例方的 CPU 等配置不一樣，也需要合理調度請求流量。

這兩種實際應用場景都需要通過合理的路由規則來解決。

我們再聊聊限流。在服務的響應能力里有一個詞叫做雪崩。雪崩指的是一種自然現象，雪山上堆積了很多雪，但都還算穩定。但當最后一片雪花落下的時候，整個雪山就崩塌了。服務也存在類似的現象，假如說你的服務每秒可能最大可以正常處理 1000 個請求，但是如果到了 1001 個請求，整個服務將崩潰，連 1 個請求也沒辦法正常處理了。這就是服務中的雪崩。

那在服務治理中為了杜絕這種現象的產生，就誕生出了一種限流功能。你可以配置某個服務實例的最大處理能力，當超過這個處理能力時后面就不要再過來新的請求了，以保證服務還能正常運行。限流方式有兩種，一是快速失敗，直接拒絕掉多出來的請求。二是均勻地排隊，讓服務慢慢地處理。就像地鐵站里的限流欄一樣。

這兩種限流能力在 Polaris Mesh 中都可以非常方便地進行配置。

除了上面的能力以外，Polaris Mesh 還包括熔斷規則、訪問鑒權、可觀測等等特性。在接入方式上不但提供了 JAVA / Go / C++ / Node.js / PHP 的 SDK 接入，而且還支持 Spring Cloud / gRPC 、服務網格、K8s 服務治理等多種主流客戶端。完整的接入方式參見下圖：