20世紀90年代中期開始，分布式架構開始流行起來，面向服務的架構(SOA)越來越占主導地位。在21世紀初，微服務開始出現，一系列基于微服務架構的架構湧現，而近日，為建構微服務開源生态， TARS項目也将成立基金會。本文邀請騰訊雲進階工程師田甜老師帶大家了解開源微服務架構現狀，詳細闡述TARS、gRPC、以及騰訊雲Service Mesh的不同優勢和特點，希望能與大家一同交流~
引言
目前開源界的微服務架構大體可以分為以下四個種類。
第一類是無服務治理的，這一類基本可以看做是一個RPC架構。RPC發展到現在已經有幾十年的時間了，主要代表為gRPC、BRPC、Thrift，它們也都有對外開源的代碼。
第二類是帶治理功能，但是語言比較單一，主要的代表是以Java為主的Spring Cloud、dubbo等。
第三類就是Service Mesh，主要代表産品是Linkerd和ISTIO，這是未來的發展方向。
最後就是TARS，不僅支援多語言，還附帶一些服務治理相關的功能産品。
一、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的産品應用比較完善，在某些技術上甚至處于領先地位，目前應用在很多大規模應用上也很少出問題。
二、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架構思路的架構，造成比較多的麻煩。
三、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上面靠，因為架構開發未來會慢慢以業務開發為主，治理這一塊将不再是重點。
四、Q&A
Q：對于Service Mesh，Service Mesh相當于将所有的服務治理都單元化內建到某個應用中，那麼每一個單元的負載均衡或者是流量控制，是如何控制的呢？
A：負載均衡其實就是将流量轉化成IP清單，分發給不同的IP。這裡需要通過Sidecar？因為Sidecar會知道你的流量往哪邊走，目前是通過iptables劫持流量指向Sidecar。當你的服務通過Sidecar之後，Sidecar擷取到目的位址，通過控制台上的資料，搭配一些政策，然後做映射，把你相應的請求分發到多個節點中去進而實作均衡。
講師簡介
田甜，騰訊進階工程師，對分布式架構與容器化技術有深入研究，具有豐富的分布式架構設計開發與項目實踐經驗。目前專注TARS-GO架構開發，是TARS-GO早期發起人和最核心開發成員之一，也是騰訊遊戲資料研發工程師，緻力于在資料服務場景中應用微服務架構。
海量技術實踐經驗，盡在雲加社群！
https://cloud.tencent.com/developer