自從去年 10 月份搜狗正式被騰訊合并以后，我一直想給大家講講騰訊內(nèi)部目前開發(fā)在用的一些技術(shù)棧，我想這對(duì)同學(xué)們有很高的學(xué)習(xí)價(jià)值。但苦于公司內(nèi)部有明確的規(guī)定，不允許私自對(duì)外分享和發(fā)布未經(jīng)公開的信息。一經(jīng)發(fā)現(xiàn)，高壓線開除處理！所以一直遲遲都沒有動(dòng)手。

最近我在騰訊的 TechoDay 技術(shù)開放日活動(dòng)中了解到內(nèi)部在使用的微服務(wù)核心北極星（Polaris-Mesh）和一站式微服務(wù)開發(fā)框架 Spring Cloud Tencent 都已經(jīng)對(duì)外開放了。

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

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

那我今天就可以結(jié)合它們來給大家簡單聊聊騰訊內(nèi)部在用的微服務(wù)體系了。

一、為什么要擁抱微服務(wù)

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

在 web 網(wǎng)頁的時(shí)代，上面兩套技術(shù)棧切切實(shí)實(shí)火了很長的時(shí)間。但隨著移動(dòng)互聯(lián)網(wǎng)的爆發(fā)，要開發(fā)的服務(wù)越來越多，功能也越來越雜，團(tuán)隊(duì)開發(fā)人員也不斷地?cái)U(kuò)張，發(fā)布頻率越來越高。傳統(tǒng)的單體服務(wù)的架構(gòu)就逐漸呈現(xiàn)出了這么幾個(gè)問題。

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

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

團(tuán)隊(duì)協(xié)作成本高 當(dāng)有多個(gè)人負(fù)責(zé)同一個(gè)服務(wù)的時(shí)候，難免就會(huì)出現(xiàn)提交代碼互相影響的情況，發(fā)布也是得商量著來。另外就是每次版本發(fā)布前的測(cè)試工作也是得需要很全面才行。

在后來，就慢慢衍生出了服務(wù)的概念。把單體應(yīng)用拆分成多個(gè)不同的服務(wù)獨(dú)立進(jìn)行部署和發(fā)布。比如我當(dāng)年負(fù)責(zé)的搜狗手機(jī)助手，在后臺(tái)就是分成了應(yīng)用推薦列表、應(yīng)用檢查更新、搜索、精準(zhǔn)推薦、云端控制、地址定位等等多個(gè)獨(dú)立的服務(wù)出來。

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

業(yè)界圍繞容器技術(shù)又進(jìn)行了一系列的演化和迭代，逐步演化出了今天的微服務(wù)架構(gòu)。微服務(wù)的熱度在 2017 年后突然爆發(fā)，各大一線互聯(lián)網(wǎng)公司也紛紛將這一技術(shù)引入并在實(shí)際業(yè)務(wù)中落地，騰訊也不例外。

二、騰訊的微服務(wù)引擎

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

在騰訊也好，業(yè)界也罷。微服務(wù)架構(gòu)雖然在細(xì)節(jié)的技術(shù)選型上會(huì)有所差異。但基本上都可以如下一張微服務(wù)架構(gòu)圖來表示。

在這個(gè)微服務(wù)架構(gòu)中，左右兩側(cè)分別都是微服務(wù)的基礎(chǔ)設(shè)施，中間是開發(fā)框架。在這些基礎(chǔ)組件中，我覺得最重要和核心的就屬上圖左側(cè)的網(wǎng)關(guān)、名字服務(wù)北極星、以及配置中心。這也正是騰訊對(duì)外的云微服務(wù)引擎（Tencent Cloud Service Engine，TSE）所對(duì)外開放的能力。

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

2.1 云網(wǎng)關(guān)

在單體應(yīng)用時(shí)代，在接入層的做法一般就是申請(qǐng)一個(gè)外網(wǎng)域名，然后在接入層按照域名將請(qǐng)求分發(fā)到不同的業(yè)務(wù)服務(wù)器上。

在微服務(wù)架構(gòu)中，網(wǎng)關(guān)仍然是流量的入口。不過到了微服務(wù)時(shí)代后，服務(wù)的數(shù)量比之前要多很多。再也無法直接按照一個(gè)域名一個(gè)服務(wù)的方式進(jìn)行配置了，而且微服務(wù)場(chǎng)景下對(duì)路由、監(jiān)控配置管理等方面的需求更為強(qiáng)烈。

所以這時(shí)就需要一個(gè)微服務(wù)網(wǎng)關(guān)，作為所有 API 接口的總?cè)肟凇＞W(wǎng)關(guān)對(duì)后端的微服務(wù)進(jìn)行封裝，通過 API 網(wǎng)關(guān)統(tǒng)一暴露服務(wù)。在網(wǎng)關(guān)中提供統(tǒng)一的安全、路由、流控、監(jiān)控等服務(wù)。當(dāng)有流量到達(dá)的時(shí)候，網(wǎng)關(guān)進(jìn)行一些預(yù)處理后實(shí)現(xiàn)根據(jù)不同的服務(wù)名進(jìn)行流量的分發(fā)。

2.2 服務(wù)治理中心

騰訊的服務(wù)治理組件叫北極星。該項(xiàng)目最早是騰訊內(nèi)部開源協(xié)同共建的統(tǒng)一名字服務(wù)組件，用于解決 RPC 調(diào)用的服務(wù)注冊(cè)、動(dòng)態(tài)路由、負(fù)載均衡和容錯(cuò)問題。

現(xiàn)在北極星不但部署到了騰訊云上對(duì)外提供服務(wù)能力，而且還入駐了開源社區(qū)。該項(xiàng)目一上線就受到了業(yè)界的廣泛關(guān)注。

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

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

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

在微服務(wù)架構(gòu)里，首先要解決的一個(gè)問題就是如何找到你要調(diào)用的服務(wù)。在一家大公司里，可能線上有成千上萬個(gè)服務(wù)同時(shí)在運(yùn)行。那么當(dāng)你的服務(wù)想調(diào)用某個(gè)服務(wù)的時(shí)候，如何正確找到對(duì)應(yīng)的服務(wù)并進(jìn)行訪問呢？

這個(gè)問題就是通過北極星 Polaris Mesh 的服務(wù)注冊(cè)與發(fā)現(xiàn)機(jī)制來解決。服務(wù)提供方在啟動(dòng)時(shí)會(huì)向 Polaris Mesh 注冊(cè)自己的服務(wù)名以及服務(wù)地址。當(dāng)調(diào)用方需要調(diào)用的通過在進(jìn)程內(nèi)部內(nèi)嵌的 Proxy 代理先到 Polaris Mesh 獲取要調(diào)用的服務(wù)地址，找到后直接發(fā)起調(diào)用。

一般情況下服務(wù)提供方都是有多個(gè)實(shí)例的，那么到底該選擇哪一個(gè)來進(jìn)行訪問呢？有這么兩種不同的使用場(chǎng)景。

一種使用場(chǎng)景是分組，比如你的服務(wù)調(diào)用方和服務(wù)提供方可能是多地部署的，在Linux 網(wǎng)絡(luò)性能的 15 個(gè)優(yōu)化建議！一文中我們提到過最好是在同機(jī)房內(nèi)部來進(jìn)行服務(wù)調(diào)用。要避免跨機(jī)房調(diào)用。因?yàn)檫@會(huì)導(dǎo)致過長的耗時(shí)。再比如你可能需要單獨(dú)部署測(cè)試環(huán)境，和灰度環(huán)境等等。

還有一種應(yīng)用場(chǎng)景是負(fù)載均衡，即使是同環(huán)境同機(jī)房，可能各個(gè)服務(wù)提供實(shí)例方的 CPU 等配置不一樣，也需要合理調(diào)度請(qǐng)求流量。

這兩種實(shí)際應(yīng)用場(chǎng)景都需要通過合理的路由規(guī)則來解決。

我們?cè)倭牧南蘖鳌Ｔ诜?wù)的響應(yīng)能力里有一個(gè)詞叫做雪崩。雪崩指的是一種自然現(xiàn)象，雪山上堆積了很多雪，但都還算穩(wěn)定。但當(dāng)最后一片雪花落下的時(shí)候，整個(gè)雪山就崩塌了。服務(wù)也存在類似的現(xiàn)象，假如說你的服務(wù)每秒可能最大可以正常處理 1000 個(gè)請(qǐng)求，但是如果到了 1001 個(gè)請(qǐng)求，整個(gè)服務(wù)將崩潰，連 1 個(gè)請(qǐng)求也沒辦法正常處理了。這就是服務(wù)中的雪崩。

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

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

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

在使用上，我覺得騰訊云提供的配置工具比我們內(nèi)部用的還方便。路由規(guī)則、熔斷規(guī)則、限流規(guī)則都可以在界面上直接進(jìn)行配置。用起來非常的方便。

2.3 配置中心

在傳統(tǒng)的單體服務(wù)時(shí)代，配置往往都是寫在一個(gè)叫配置文件的東東里的。但是到了微服務(wù)時(shí)代，由于服務(wù)數(shù)量的爆炸，一大堆的各類配置項(xiàng)，各種不定時(shí)的修改需求會(huì)讓整個(gè)工作過程顯得混亂不堪。過于分散的配置文件加大了管理的難度。

所以在微服務(wù)時(shí)代里，配置中心都成為了標(biāo)配。思路就是把項(xiàng)目中所有參數(shù)、開關(guān)等配置性的信息，全部都放到一個(gè)集中的地方進(jìn)行統(tǒng)一管理，并提供一套標(biāo)準(zhǔn)的接口。當(dāng)某個(gè)服務(wù)需要獲取配置的時(shí)候，調(diào)用接口拉取。當(dāng)有配置更新的時(shí)候，配置中心會(huì)通知到各個(gè)服務(wù)時(shí)期動(dòng)態(tài)加載。

在業(yè)界，已經(jīng)有多種常用的解決方案了，包括 Zookeeper、Eureka、Nacos、Consul、Apollo 等等。在騰訊云 TSE 中以上幾種主流配置中心解決方案全部都支持，而且對(duì)功能進(jìn)行了增強(qiáng)，提供可視化的控制臺(tái)、服務(wù)管理、日志、監(jiān)控、告警、鑒權(quán)等一系列原方案所不具備的功能。

在部署上，不再需要自己的運(yùn)維團(tuán)隊(duì)進(jìn)行部署。一鍵就可以部署出支持多活、持久化等高可用的配置中心集群。

在可視化的控制臺(tái)中，可以非常方便地對(duì)配置中心進(jìn)行數(shù)據(jù)管理、日志查看、運(yùn)行監(jiān)控等日常操作。

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

2.4 開發(fā)框架

對(duì)于 Java 開發(fā)者來說，還可以直接使用 Spring Cloud Tencet 開發(fā)框架。該框架實(shí)現(xiàn)了Spring Cloud 標(biāo)準(zhǔn)微服務(wù) SPI，它依托北極星 polaris，實(shí)現(xiàn)各種分布式微服務(wù)場(chǎng)景。

Spring Cloud Tencent 所有組件都已上傳到 Maven 中央倉庫，只需要引入依賴即可。

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

三、總結(jié)

微服務(wù)架構(gòu)是目前比較流行的技術(shù)。搭建一套微服務(wù)基礎(chǔ)架構(gòu)往往需要組裝一系列的微服務(wù)中間件，例如服務(wù)注冊(cè)中心、配置中心、日志中心等等。這個(gè)初期的成本投入是很高的。一般大公司有有專門的人力和財(cái)力來搭建微服務(wù)所需要的這些基礎(chǔ)輪子。

對(duì)于中小公司，甚至是個(gè)人開發(fā)者來說，如果全盤從 0 自己部署微服務(wù)所依賴的這些基礎(chǔ)組件，光是部署就足夠折騰好久的了。而且微服務(wù)中還存在多種技術(shù)選型，比如配置中心就有 Zookeeper、Eureka、Nacos、Consul、Apollo 等很多種。學(xué)習(xí)和運(yùn)維難度都比傳統(tǒng)的開發(fā)模式要復(fù)雜的多。

但是作為中小公司或者個(gè)人開發(fā)者來說，如果不接觸微服務(wù)架構(gòu)又會(huì)慢慢地與時(shí)代脫節(jié)。好在現(xiàn)在公有云廠商都提供了微服務(wù)基礎(chǔ)設(shè)施。我在 Techo Day 上體驗(yàn)下來的感覺，就是太方便了，開箱即用。

回想起我剛開始折騰 Zookeeper、Consul 的時(shí)候，光編譯和安裝就浪費(fèi)了很多時(shí)間。現(xiàn)在一鍵部署就能使用，實(shí)在很方便。而且我感覺騰訊對(duì)外的產(chǎn)品使用體驗(yàn)上的打磨做的更好，其實(shí)很多地方比我們內(nèi)部的工具用起來都好用。