TARS立刻要成立基金會了，這款微服務框架適合你麼？

20世紀90年代中期開始，分佈式架構開始流行起來，面向服務的架構(SOA)愈來愈占主導地位。在21世紀初，微服務開始出現，一系列基於微服務架構的框架涌現，而近日，爲構建微服務開源生態， TARS項目也將成立基金會。本文邀請騰訊雲高級工程師田甜老師帶你們瞭解開源微服務框架現狀，詳細闡述TARS、gRPC、以及騰訊雲Service Mesh的不一樣優點和特色，但願能與你們一同交流~

引言

目前開源界的微服務框架大致能夠分爲如下四個種類。

第一類是無服務治理的，這一類基本能夠看作是一個RPC框架。RPC發展到如今已經有幾十年的時間了，主要表明爲gRPC、BRPC、Thrift，它們也都有對外開源的代碼。

第二類是帶治理功能，可是語言比較單一，主要的表明是以Java爲主的Spring Cloud、dubbo等。

第三類就是Service Mesh，主要表明產品是Linkerd和ISTIO，這是將來的發展方向。

最後就是TARS，不只支持多語言，還附帶一些服務治理相關的功能產品。

1、TARS 架構體系

1. TARS簡介

TARS是騰訊從2008年到今天一直在使用的後臺邏輯層的統一應用框架TAF（Total Application Framework），目前支持C++、Java、PHP、Nodejs、Go語言。該框架爲用戶提供了涉及到開發、運維、以及測試的一整套解決方案，幫助一個產品或者服務快速實現開發、部署、測試，以及上線。

它集可擴展協議編解碼、高性能RPC通訊框架、名字路由與發現、發佈監控、日誌統計、配置管理等於一體。經過它能夠快速用微服務的方式構建本身的穩定可靠的分佈式應用，並實現完整有效的服務治理。

2. TARS總體架構

TARS的架構以下圖所示：

Devops相關方面，主要有代碼管理、代碼編譯和自動化測試等等，底層還有OSS的服務治理。支持協議方面，主要基於自身的TARS協議，另一些其餘自定義的協議也能夠支持。服務治理的功能較爲豐富，包括你們經常使用的服務註冊、負載均衡、熔斷、服務配置等等，這些都是在咱們線上作分佈式服務管理的時候要作的。

TARS支持五大編程語言，其中包括C++和JAVA、nodejs和PHP和GO，也能夠擴展其它語言。

3. 服務治理

對於服務治理，其實最重要就在於客戶端和服務端之間的調用。咱們的客戶端調用服務端是經過registry 來實現的，registry 中文名字叫作主控。客戶端在調用的時候會去 registry 作請求，後端有一個 SDK 管理全部的協議，這個 SDK 能夠對服務進行監控統計，所有自動完成。

（1） 自動區域感知

調用 logsvr 的時候，用戶請求主控拿到節點列表並直連。這裏須要指出，基於路由的規則，咱們須要把網段註冊成一個地區，從而實現自動區域感知。

這是由於在線上業務當中，會出現一些問題。若是一個服務部署到同一地區的不一樣區域之後，它的跨機房時延在4毫秒左右。若是是跨城市、省份的話可能高達到40毫秒，因此若是咱們同機房有部署的話，就會盡可能訪問本身機房，這樣能夠提升性能，減小訪問耗時。

綜上，常規的負載均衡方式面對跨地區或者跨機房部署的服務，會由於網絡緣由形成延時增大，使用不一樣服務名來解決該問題時也會帶來繁重的運維工做，而經過 Registry 和開發框架配合實現自動區域感知能夠自動完成相關的工做。

（2） SET模型

SET模型是騰訊運用比較普遍的體系，由於當容量大到必定程度以後，一個服務發佈的過程當中也許能影響到全區的服務。例如手機QQ的用戶基數上億，一點微小的變更都會產生深遠的影響，所以咱們設計了SET模型。

如上圖所示，假設該模型有300萬的容量。若是單個地區容量過大會致使整個容量過載，因此將它分紅三組，6個服務，每一個服務自我調用。可是這種服務開發成本相對比較高，若是要再擴增100萬容量的話，須要建更多組服務才能夠實現。

經過框架處理能夠很好解決上述問題，爲了以示區別，咱們在服務A、B前加上標識Set。經過縱向割裂，將300萬以100萬/個SET的單位分紅3組，每個SET負責100萬的容量，將來業務容量超過了300萬接近400萬時就只須要加一個SET就能夠了。該場景主要是防止故障擴散，若是其中一個場景在迭代的時候出現了問題，只會影響指定SET的100萬的用戶，不會影響到其餘200萬的客戶。

（3）流量控制

關於流量控制，其實在分佈式架構方面也會存在一些問題。好比說，咱們常常發佈節點，若是按照節點一個一個發佈的話，即便服務部署得很是多，但由於流量較大，單個節點存在的用戶也會比較多。

這時能夠經過權重設置作到無損發佈，例如經過權重指定某一個節點的流量只有10%，以此來控制流量。在發佈的時候，常常會出現重啓致使流量丟失的現象。面對這種狀況，咱們能夠先把流量調爲0，發佈完成以後，再調回來，這樣就能夠實現部分按需流量的控制，這也是在大規模線上應用比較經常使用的解決方案。

（4）分佈式跟蹤

當有用戶反饋說某項服務訪問比較慢的時候，咱們就須要知道用戶相應的用能耗時。這種狀況下，若是隻是經過相應的數據去排查的話，是比較困難的。

由於在一個微服務下面，一個請求可能會跳屢次，因此沒法預測到一個服務具體走的跳數，這時候就須要經過分佈式跟蹤來進行鏈路追蹤。TARS有一套比較完整的體系，從接入到存儲均可以自我實現。

(5) 服務配置管理

關於服務配置管理，咱們分了四級，分別是應用級配置、SET配置、服務配置和節點配置。

作分佈式架構，最難的點就是運維可視化。這樣作不只能讓部署和發佈更加方便，還能將開發和運維分離，不須要開發接入，一些流程化操做能夠尋求外包人員，這樣也減輕了人力成本。

TARS的產品應用比較完善，在某些技術上甚至處於領先地位，目前應用在不少大規模應用上也不多出問題。

2、gRPC架構體系

gRPC主體是一個RPC框架，一樣也定義了負載均衡策略。

gRPC主要基於Protocol Buffers 框架，Protocol Buffers 是Google出品的序列化的框架，與開發語言和平臺都無關，具備良好的可拓展性，可用於數據存儲和通信協議。

gRPC官方介紹雖然簡單，但實際在線上應用時須要腳本和參數。因此咱們作了一個腳手架，經過這個參數生成代碼。由於gRPC線上只提供了標準的接口，並不直接提供代碼。不少服務治理的服務，好比日誌、ACL這些全都得本身實現。

gRPC能夠實現多數語言的代碼客戶端生成，可是若是想要使用的話還須要作出一些改造，完成相應協議的互轉，最後還須要開發經常使用內部服務SDK來下降使用成本。

服務的實現主要依賴於gRPC攔截器的實現，經過攔截器能夠實現遠程日誌、監控上報、鏈路追蹤等服務。gRPC能夠在RPC調用前觸發註冊的攔截器，在調用前能夠執行遠程日誌上報等等功能，經過多種攔截器串行，實現一個攔截器鏈路，最終實現各類插件。

關於Protocol Buffers插件系統，它能夠作到一些簡單的加強。咱們在本身的項目中把Protocol Buffers做爲一個描述語言，當接口完成時，經過Protocol Buffers的插件功能將開發文檔轉成swagger，這樣的話與前端互通就會變得很是方便，這些代碼和文檔就能夠一會兒自動生成。

關於gRPC的周邊生態，它主要依賴於Protocol Buffers，擁有龐大的插件集合，能夠轉換出任何的語言，包含Tars協議。gRPC如今應用的場景也已經很是普遍，主要是在雲原生方面。

gRPC也和TARS同樣，存在着一些問題，就是它們須要用戶改造過之後才能使用。這樣的話就會產生用戶的學習成本，須要把總體架構改形成符合RPC框架思路的架構，形成比較多的麻煩。

3、Service Mesh的探索

咱們知道騰訊遊戲的數量很是繁多，架構每每並不統一。各個團隊都跟着本身的思路走，想用什麼就用什麼，慢慢得各類框架和問題也隨之出現。爲了探索解決這一問題，咱們引入了一個新的思路：Service Mesh。

Service Mesh 是一個相對底層的架構，做爲咱們微服務的底層。兩大主要產品是linkerd和Istio，它們能夠直接從底層作一些鏈路追蹤方面的事情，經過應用下沉提升了系統的適用性。

以下圖所示，左邊展現的是TARS和gRPC，他們的主要思路在於無性能損耗的交用，把全部的東西都執行到RPC裏面，侵入性較強。右邊是Service Mesh的架構，Service Mesh會把業務的服務作得很薄，基本上沒有什麼業務邏輯，而把全部微服務治理的東西所有放到下層，從而作到整個服務的流量控制，這樣就組成了一個個小方格，互相之間能夠互聯。

這樣的方式能夠將框架作得很是薄，甚至不要均可以。整個架構很是清晰，至關於單體調用經過Service Mesh能夠直接變爲分佈式的架構。

咱們去年在王者榮耀裏面也作了一些應用，最後發現這些架構很是方便。當咱們給王者榮耀作活動使用的時候，雖然流量很大，可是性能很是穩定。每一個服務下面都有一個Proxy，Proxy就是Sidecar，用於處理服務網格中全部服務的全部入站和出站流量。Proxy把全部的頭轉給Mixer，Mixer是負責提供策略控制和遙測收集的組件服務，這一塊是作數據平面的一些操做。接着是Adapter，爲Mixer提供擴展服務的獨立服務，好比作一些遠程負載均衡的流量控制。以這一套架構做爲分佈式體系的一部分，能大幅度下降許多單體應用的開發成本。

Pilot主要職責是向 Sidecar 發現服務、信息和各類流量管理和路由規則，Galley服務提供配置的校驗、各類配置之間統籌，爲 Istio 提供配置管理服務，Citadel用於密鑰管理和證書管理，下發到Sidecar等負責通信轉發的組件。

經過測試數據能夠看到，Istio在打開Mixer狀況下單邊延遲增長1ms 左右，雙邊延遲增長2ms左右，對服務影響較小，關閉Mixer延遲能夠更低。

若是以絕對數字來看的話，至關於增長了一倍的耗時。可是在咱們正式應用當中，大部分服務耗時都是在50毫秒左右，若是咱們只增長了1毫秒，其實影響並不大。可是若是對於一些底層存儲應用，自己的耗時是比較低的，若是再用這套架構把它變成分佈式架構就會很是困難，由於性能損耗會變得很是大。

將來騰訊雲會在設置一個統一的Istio管理平臺，在容器管理平臺裏面會提供Istio的服務網格技術，在上面一層能夠經過一些控制平面，服務咱們上面的一些管控體系，經過Istio的應用管理平面來實現，底層能夠訪問咱們的外部存儲的，這個就是咱們一套比較完整的應用架構。

下圖所示的是 Service Mesh 和咱們微服務框架的對比，在語言支持方面，它是跟語言無關的的底層架構，因此具備很高的拓展性。將來咱們將會逐步完善總體生態建設，社區如今的活躍度也維持在較高水平。

最後給你們總結一下，咱們的傳統框架將來還會存在，可是它的功能會愈來愈業務化，治理相關的一些功能會逐漸下沉，更加註重是業務化的功能。

若是在應用當中，你尚未配置一些框架的服務體系的話，那使用TARS是很是合適的。TARS使用的是完整的微服務體系，很是方便快捷。若是使用gRPC則須要本身建設周邊的體系。咱們將來將會以Service Mesh爲主，慢慢替代原有框架。若是你們還在作框架開發相關的業務，能夠慢慢地抽出來往Service Mesh上面靠，由於框架開發將來會慢慢以業務開發爲主，治理這一塊將再也不是重點。

4、Q&A

Q：對於Service Mesh，Service Mesh至關於將全部的服務治理都單元化集成到某個應用中，那麼每個單元的負載均衡或者是流量控制，是如何控制的呢？

A：負載均衡其實就是將流量轉化成IP列表，分發給不一樣的IP。這裏須要經過Sidecar？由於Sidecar會知道你的流量往哪邊走，目前是經過iptables劫持流量指向Sidecar。當你的服務經過Sidecar以後，Sidecar獲取到目的地址，經過控制面板上的數據，搭配一些策略，而後作映射，把你相應的請求分發到多個節點中去從而實現均衡。

講師簡介

田甜，騰訊高級工程師，對分佈式架構與容器化技術有深刻研究，具備豐富的分佈式架構設計開發與項目實踐經驗。目前專一TARS-GO框架開發，是TARS-GO早期發起人和最核心開發成員之一，也是騰訊遊戲數據研發工程師，致力於在數據服務場景中應用微服務架構。