摘要：為了解決這一系列問題，微博從年開發了語言的框架，并基于此完成了服務化改造。這些經歷之下微博也積累了一套服務治理型的服務化體系。的版，所要解決的是微博平臺內部服務之間的調用，因此協議時，其實并沒有考慮到跨語言的問題，用的是對比較友好的。

大家好，我今天的分享主要圍繞以下幾點，首先跟大家簡要介紹一下微博服務化的演進過程，其次是微博自研跨語言RPC 框架 Motan 實現的一些關鍵技術要點，主要是跨語言方面，再次，結合目前市面上的一些Service Mesh 實現對比，給出基于 Motan-Go 的更符合微博場景的Weibo Mesh 實現。

最后，是我個人對于面向未來泛服務化架構的一些思考。一些同學對Service Mesh比較感興趣，也想在生產上做一些實踐，如果沒有歷史包袱，新開發一個項目用什么架構，怎么實現都是可以的。由架構去取舍，看我們更迫切需要的是什么，所追求的是性能還是其它高擴展性等等，目前也有一些現成的解決方案。但是如果沒有做任何服務化，或者服務化過程中歷史包袱比較重，可能很難找到一種可以直接實施的現成方案，因為需要考慮的往往會更多。本次分享更多是關于操作性內容，希望對大家有一定的借鑒意義。

微博平臺服務化演進

我們先看微博平臺服務化的演進過程。

微博2009年上線，在業務高速發展的初期是傳統的模塊化單體服務，每個小的業務都有可能隨時爆發成長為一個核心業務。我們的目標很簡單，就是滿足業務快速發展的需求，并且在突發流量增長時保證服務的高可用。隨著業務的擴張，單體架構各個模塊嚴重耦合，致使相互的影響越來越大，請求成功率得不到保障，長尾問題嚴重。為了解決這一系列問題，微博從 2013 年開發了Java 語言的 Motan RPC 框架，并基于此完成了服務化改造。Motan 從2013年上線至今經歷過每次熱點事件、三節高峰的嚴峻考驗，穩定性和可靠性都得到了實際場景的驗證。這些經歷之下微博 Motan 也積累了一套服務治理型 RPC 的服務化體系。

除了Motan，2015年開始，為了應對越來越猛的流量洪峰，更合理的對資源進行整合利用，開發了Open DCP 彈性云計算平臺。實現了動態的彈性擴縮容，告別了以往花費動輒幾千萬的資源成本，以及節前幾個月就要開始的勞民傷財為三節做準備的日子，也不需要在為了一個個的熱點事件提心吊膽。

上圖是當時微博平臺技術體系的概貌，是一個基于 Open DCP 彈性云計算平臺和 Motan RPC 的服務化架構，經過幾年的運營和考驗，我們已經在混合云的服務化方向有了豐富的經驗和積累。但在解決了微博平臺內部服務高可用、高性能的問題后，業務方平臺服務調用的問題開始顯現出來。比如調用鏈路過長，導致坑多性能差，又比如，每個業務方都需要做高可用和服務治理，而這些事情平臺已經有豐富的積累，大家都再做一遍特別重復且浪費。當想把在平臺上的技術積累服務到微博更多的業務方時，平臺內部基于 Java 的服務化體系已經不能完成任務，所以我們需要一個跨語言的解決方案。從2016年起，我們開始了跨語言服務化改造之路。

跨語言RPC要點

異構系統如何做整體服務化的解決方案，也是今天探討的一個主題。

服務化經歷了前面幾個階段后，需要構建一個跨語言的服務化體系，將原來在 Java 體系積累的經驗加以總結，給其它的技術棧業務賦能，更好的維護微博整體的穩定和高可用。

上圖我簡單列舉跨語言 RPC 的幾個技術要點，最下面是可靠性和易用性，比如我們的 Motan 有 Cluster 的概念，每次調用都是從這個 Cluster 里面通過負載均衡（LB）策略來找出可用的節點（Endpoint），再通過一種高可用的策略（HA）完成調用。整個過程的各種理念可復用，各種語言照章實現就好。各種策略也是可以按需根據實際情況進行擴展的。而傳輸、I/O、進程線程模型等各個語言都不一樣，需要根據語言自身的特性來選擇。

協議和序列化，這是解決跨語言比較重要的一點，因為要讓各種語言互相理解對方，互相溝通。

上圖的故事大家可能都有所耳聞，人類很狂妄地說，我要建一個塔直通到天堂。但是上帝聽到以后覺得很不爽，所以讓人類說不同的語言。因為語言不通，導致塔建歪了，整個工程就失敗了，這是說交流的重要性。要做跨語言服務化，負責數據通信的RPC 框架跨語言是重中之重的基礎設施。而協議和序列化如何取舍，很關鍵。

Motan的Java版，所要解決的是微博平臺內部 Java 服務之間的調用，因此 Motan1 協議時，其實并沒有考慮到跨語言的問題，用的是對Java比較友好的 Hessian。后期在跨語言方面，motan1的協議顯得對跨語言不是很友好，motan2 的協議就給了一個足夠容易理解的協議，是一個簡單的TCP描述。比如，要請求一些方法、服務的分組，或Body，請求發過去，對方語言收到后，怎么樣讓這個語言理解呢？關鍵一點就在于序列化。

現在 Motan 使用簡單序列化的方式（Simple），只支持幾種簡單的類型。不過我們一直都在迭代中，也正在以前支持更復雜的類型上做擴充。但本質上，它仍是簡單的協議，我們會盡量保證它的簡單。只有足夠的簡單，才能在跨語言上降低成本，開發成本還好，主要是語言溝通起來解析的成本，比如，編譯型語言往往有各種明確的強類型，而解釋性語言往往并不需要強制類型約束，如何讓他們很好的溝通，這就需要做取舍。

這里給出一個 MotanRPC 框架簡圖，微博有一個自研的注冊中心叫 Vintage，也支持其它像ZK等一些注冊中心。圖中給出了 Motan RPC 關鍵的一些組件和他們之間的調用關系。如果對Motan 感興趣的，歡迎大家到GitHub 搜索關注，我們有更詳細的文檔，大家也可以網上搜索。為什么要說這些？因為Weibo Mesh 是基于Motan來做的。希望大家對Motan有個整體的認識。

現有實現跨語言，支持不同語言的Motan，最下面是Java版，就是最開始的一版，現在支持Golang（Motan-go）、Openresty-Lua（Motan-OpenResty）、PHP（Motan-PHP）。

基于 Motan-Go的 Weibo-Mesh

下一個話題：基于motango的Weibo-Mesh。數人云敖小劍老師扛著ServiceMesh大旗已經沖了一段時間了。剛開始我們也看到這一點，其實大家的想法都一樣，因為需求和痛點基本是一樣的。所以我們嚴重認同ServiceMesh是下一代微服務，當然不同人都有自己的理解，通過初步的實踐，如果一個很復雜的架構，大家在做服務化，服務化到一定程度，會由于微服務的力度和規模慢慢增大，出現依賴復雜度的增加帶來流量交錯，難以管控以及服務治理更加困難等一序列的問題。為了解決這些就需要一個東西很好的管控這些服務和流量，這就是為什么會有Mesh。

看一下現在業界公認最牛的 Mesh Istio是怎么玩的。這里我希望大家關注兩點，一個是 Istio 有一個基于Envoy 的數據傳輸層，另外是控制面板，Istio 通過這個控制面板來完成流量調度，鑒權，服務治理等工作。這是 Istio 現在的做法，那微博怎么做的呢？

首先，我們從2016年開始做跨語言的服務化改造，那時還沒有 Service Mesh ，剛開始很簡單，只想做跨語言，想解決跨語言調用鏈路過長的問題。比如，原來所有的跨語言服務都是通過 Restful 接口提供的，每個請求都需要層層轉發，尤其現在是混合云的架構。舉個極端又及其常見的例子 ， A 機房的服務依賴一個Restful 接口，請求發出后，內部 DNS 解析說這個域名在 B 機房提供服務，你到B 機房后，HA 告訴你，這個請求應該去C 機房的一個Member 上去完成，繞了一大圈，很有可能發現那個 C 機房在公有云上，鏈路特別長。所以，希望通過實現跨語言的 Motan RPC，Client 對Server 發起直連，通過點對點的通信來解決鏈路過長的問題。而后來的演進，后面再細說。

今天講的這個可能比較簡單，目的是希望大家能更好的入戲，更好的理解。可以用直連的方式，或用任何其它方式，像我們用了 Motan。

微博從2016年開始做這個事情踩了很多坑 。微博做跨語言，剛才在后面跟老師們交流大家還說 GRPC 把跨語言帶跑偏了，當時做跨語言的時候就是想GRPC已經做的很好，就想通過Motan支持GRPC 協議的方式來實現Motan的跨語言調用。大家可以去翻 Motan 的開源，里面是有GRPC支持的，現在也還有（不過最早支持的是PHP，對接的是鳥哥寫的那個Yar的RPC框架, 最早 Motan還支持Yar協議。）。

所以當時想法很簡單，想依托GRPC來解決跨語言的問題，所以是上面這樣的一個結構，用GRPC來搞。

這個結構出來以后，我們開始拿線上的業務來摸索改造。發覺需要把原來的Restful 接口完全重寫成GRPC的服務，這樣的改造避免不了大范圍的代碼重寫。硬著頭皮改了一些后，發覺性能也沒有像宣稱的那么好。

大家平時可能都會上微博，我們一條微博數據里面可能有百十個字段，所以基于GRPC 改造就需要把這些字段和服務都用PB 進行定義，完了以后發現最終的Proto文件寫下來一大坨。雖然說請求過程并不需要傳遞這些proto 數據，但是請求數據回來以后需要解析組裝。跨語言的時候，比如說PHP來解析那個對象，性能就比較差了，所以這種方案應對微博這種場景最終被淘汰了，而且就算勉強接受性能的損失，這里也只是基于GRPC 解決了跨語言的部分。那另外一個很重要的部分 --- 服務治理呢？

因為我們多年服務化演進，Motan整個體系在服務治理方面做了很多工作，有很多積累。但是基于 Motan 支持GRPC 協議來完成跨語言的服務化的服務治理怎么做呢？比如說這個時候PHP 怎么去做服務發現？PHP 每一個過來，都是一次處理整個過程就結束了，沒有一個常駐的可用存儲每次請求狀態的地方來實現服務發現、服務治理這類似的事情。

但是我們也做了很多嘗試，比如通過一個本機的后臺進程來做服務發現，或者在Nginx 上基于OpenResty 的timer 來實現服務發現，并發結果寫到PHP 的$_SERVER 變量中，讓PHP 能直接使用（上面右圖那樣）等，但是實踐的效果并不理想。

所以整體通過 GRPC 來做跨語言這個方案做下來，效果不是很理想，這并不適合我們的場景。所以我們就走到WeiboMesh的原形（如下圖），我們想既然解釋性語言的跨語言服務化由于語言本身的特性和我們的特殊場景（主要是改造成本、性能等方面的考量）下，并不適合直接通過語言本身來實現，那這樣的話，還不如去做一個代理。這個代理可能就是WeiboMesh的一個雛形，類似現在ServiceMesh 中的SideCar。

比如說Java啟動一個服務，通常情況下，比如 Java Client 訪問這個服務是這樣的一個流程：Java Client 啟動的時候會根據配置去注冊中心訂閱自己需要訪問的服務，請求過程中會有一個線程不斷的從注冊中心去發現當前可用的節點列表回來，組成Client 端的一個Cluster而完成的調用（如前面Motan 請求處理簡圖所示的那樣），而如果是PHP 需要通過Motan RPC 訪問這個服務呢？PHP沒法做服務發現，它就把它的請求扔給Go Agent，服務訂閱、發現、治理這些事情讓Motan Go Agent 來做，其他的都一樣。我們做這個的時候，還沒有ServiceMesh這個東西呢，所以一路踩了很多坑。

繼續往下想，如果反過來 PHP要做server的時候呢？之前說 RPC 跨語言所要解決的一堆技術問題，比較重要的是傳輸模型，怎么選一個比較靠譜的模型來作為Server 處理請求呢？現在也有很多很好的現成的解決方案，但是我們沒有從中選哪一套來做。主要因為微博業務實在是很龐雜，里面有很多 PHP 的業務，如果把原來基于 LNMP 的服務架構改成 PHP 直接做Server的話，涉及到排山倒海的業務重寫，PHP 同學可能會要了我們的命，他們是不會接受的（我要是他們，我也不會干）。所以我們就想，怎么能更簡單的把這個事情做了，因為已經有了前面 PHP 通過 Motan Go Agent 去請求RPC 服務，我們就繼續在上面擴展了一下。

PHP 要做SERVER，我們使用Motan-Go-Agent來幫助PHP做服務的導出，這個就不是簡單的請求調通了，因為 Motan-Go-Agent 除了負責請求的連通，還負責Server 端 PHP 服務的注冊。Motan-Go-Agent的角色更像是是一個Motan Server。啟動的時候他會把需要導出的PHP的服務，比如注冊中心完整導出，并保持像注冊中心服務狀態的上報更新。導出后，假如說一個Java的Client 需要調動這個服務，Java-Client 會訂閱這些服務，請求過程中會通過服務發現回來的節點對它發起調用。Motan-Go-Agent 接到請求后，它把這個請求轉給后端的PHP 處理，它之間可能是基于CGI或者是HTTP協議完成的，回來這個請求就完成了。

服務化以后，最直接的感受，原來服務調用時依賴一些 lib 庫、Jar 包，或者Restful接口，現在變成依賴一些服務。在服務調用時，不再是倒入某個包或者Curl 某個接口，而是直接去注冊中心訂閱和發現某個服務，這是一個本質的改變。

這個本質的改變提高了服務依賴和復用的效率，但是原來的很多服務都通過這種方式暴露了，也直接提升了服務治理的復雜度，服務治理成本變得相對較高。

但是這一切都是值得的，因為這一來我們統一了服務治理的方式，高可用等各種保障，通用邏輯的封裝等實現起來都更輕松自然。

我們基于 Motan-Go-Agent提出對像 PHP 這樣不方便實現服務化的語言，通過正向、反向代理的方式來實現跨語言服務化，Java、Golang這樣很方便實現服務化的語言，有簡單的Motan實現，或者也可以直接通過Motan-Go 導出服務，這樣就只需要實現一個簡單的Motan-Client 來完成服務調用即可。

我們服務化做到這個階段，發現性能已經符合預期，但是當想擴大規模的時候，發現節點和服務數量少。服務化規模很小的時候，比如平臺提供幾個服務，供幾個業務方來調用，可能人工確認，事先配好就沒問題。但服務化規模大了之后，就沒法人工確認來解決，我們的做法是通過擴展注冊中心的功能來解決。

在我們一籌莫展的時候，發現Service Mesh這個概念出現了，而且解決的問題和面臨的挑戰都一樣，都是解決跨語言服務化的問題，也都面臨流量、服務管控和治理復雜化的挑戰。而且，那么多大牛公司在后面做背書，所以我們就馬上轉到這個方向上來，希望實現一套更符合微博現狀的Weibo Mesh。

要更符合微博現狀，首先我們在 Motan RPC、服務治理上有很多積累，這是已有的，不想拋棄的，這是寶貴的技術資源。另一個目標，要做跨語言。所以，一體化的解決方案更符合微博的結構。

另外，微博是混合云架構，彈性云計算平臺已經有了。如果新起一個項目，沒有任何歷史包袱，任何方案都可以。但假如有歷史包袱，就不一樣了。

這就是基于微博現狀做的 Weibomesh。這里給大家詳細的說一下，一個是Mesh，跟Istio就很像。但是不一樣的地方是說，微博體系里除了一些編譯型語言，還有一些解釋型語言。只有解釋型語言需要走用Mesh來導出服務的方式。比如Java 就不需要，因為有比較好的原生積累。Istio宣稱不需要業務方改任何一行代碼。但是我們這里需要一個簡單的薄薄的client層，算是我們對自己業務的一點犧牲，對后面的收益極大。

其它都一樣，包括服務注冊、發現、調用。另外，決策系統好比 Istio 里的控制面板一樣，負責發指令。跟Istio不一樣的地方是，Istio 中是通過一些請求的 Header 的數據，通過一些規則來做基于 iptables 的流量轉發，而Weibo Mesh不需要轉發，因為服務都是通過發現回來的，要調什么服務，就發現什么服務。調用是明確的，出門之前就知道自己要去哪兒，不需要轉發。只是有一點，可能發現回來是一堆節點，需要把控的是怎么讓流量更均勻，更好的控制流量，所以有一個自動流量調度和彈性擴容。

彈性擴容本身就有，為了應對峰值流量，應對節日。比如原來為了過年，要提前三個月準備好幾千萬的服務器。

服務治理是Motan體系的積累，服務傳輸就是通過它來收發請求，流量過來，因為請求都經過Mesh層，所以通過時時調用的信息，來時時調配流量，對整體系統進行保障。

這就解決了剛才說的，如果微服務力度大，服務劃分很細，Services 規模大到一定程度，多個服務之間，怎么互聯互通。

這是微博自動臺調動體系，分為幾個關鍵點。容量評估模型、是自動化壓測容量評估系統。彈性調動要解決的問題，一個是調配集群的流量，一個是控制集群的規模。怎么調配？首先要度量，度量系統包括：它什么時候是正常的，健康的，什么時候是冗余的。一個系統的冗余度是怎么度量出來的。

通過上面這個公式來度量集群的冗余度，還評估了集群是否需要擴容，流量是否需要調動。

下面這里有幾條水位線的概念，一個是安全線，一個是警戒線，一個是危險線，紅色的就是危險線，這個時候就需要擴容了。大家可以理解為水庫，一個水庫能蓄多少水，什么時候水位上來，扛不住了就會發生洪災。

通過對整個集群的流量評估，可以知道這個集群是否空閑，是否安全。當集群流量扛不住，是否把這些流量切到其它集群，支撐整個彈性調動和動態容量調動。

Weibo Mesh改造收益

WeiboMesh改造，通用于任何異構系統。有些操作比如解釋型語言，因為某些語言特性，不能實現那個功能，但是用Mesh的方式，可以在 Mesh 層實現。比如， PHP 請求一個接口，如果接口響應慢，通常的做法是重試，這樣會帶來危險，因為原來走的都是集群的轉發。但是如果直連，如果一個節點慢了，一直重試可能就試掛了。如果重試三次不可以，就不再往這里調了，把它從可用節點里摘掉，解決宕機的問題。

監控里會經常看到一些長尾的調動，發現系統性很好。但是真正跑起來，因為網絡或者機器的因素，可能會導致后面的長尾特別長，特別占資源。如果在 Mesh上，時間長于某一個閾值的時候，就再給發一個，如果后發的請求響應先回來的話，可以把前面的請求拋掉。

體系化是說，不需要在每一套語言里都實現一套。這跟通用的ServiceMesh方案一樣，大家都是為了通用和統一。

這是微博搜索，接入這個系統之后生產當中的一些數據，也經過了一些實驗的驗證。比如，這是薛之謙和前妻復合事件，這個圖同事在很多場合都講過，原來運營發一個 PUSH ，大家都提心吊膽。在新浪如果遇到爆炸性的新聞，運營在發 PUSH 之前，都要通知到所有技術。但是現在不需要這樣，比如說那次運營發了一個PUSH，大家可以想象一下山洪爆發，調動系統發現已經過了黃色警戒線了，已經需要擴容了，它就自動擴了，冗余就上來了，這是動態擴容。彈性調動也是如此，用的同一個技術體系。

面向未來架構，重新定義服務化

在開發過程中會遇到很多問題，原來做服務化，所提供的是一些Lib、Jar包或是像接口之類的，但是現在已經不再依賴那些，現在依賴的是服務，Service Mesh 里甚至都沒有Client和Server的概念了，都是Service。但是在Motan里面，是有Client和Server的。它有兩端，因為要去發調動，兩端的處理不一樣。調動不是通盤都按Service來講的，是通過服務發現，然后對Server 發起直連。這個過程導致需要每一個實現跨語言的地方，都需要一些特殊的處理。

首先通用性方面，使用Motan來刻畫一個服務，現在不再依賴包，而依賴于服務。提供的時候，告訴這個服務，注冊到那個分組下，調動那個分組下面的服務就可以了，一個很簡單的RPC服務調用的方式，上面會有協議，節點和版本號類似的數據，用URL來唯一刻畫一個服務。

微博有歷史包袱，希望已有的系統不要改動太多，以最小的成本得到最大的收益。所以，我們對原來基于 Jersey 開發的 Cedrus Restful 框架進行了適配，在Motan框架層面把原來所有的Restful 接口自動導出為Motan RPC 服務，通過這種方式減少改造的成本。原來改造的時候，需要把所有 Restful 服務都重寫成RPC服務，成本特別高。

支持協議，比如支持GRPC，前面有GPRC可以去調，現在支持HTTP，HTTP對等的是Cedrus（其實就是Servlet）。它其實中間傳輸的是Motan協議，但是可以按照HTTP的方式調動一個Motan服務，這樣的話，Client也不需要改任何一行代碼。

我們對WeiboMesh 的一些思考，Weibo Mesh 跟通常的Service Mesh 有本質的不同，我們對服務的調用是通過服務發現后直連的，不是通過攔截和轉發。通常Service Mesh 不能直接滿足我們的需求，可能大家也有很多類似的場景。所以這些思考希望能給大家一些借鑒的意義。

Weibo Mesh的服務調用需要更輕薄的Motan Client，一個原因是降低已有架構的改造成本，一個是泛服務化的概念。比如訪問微博，需要調動用戶的服務、微博的服務，評論的服務，但是后端的底層資源，比如說MC，Kafka等的資源都是服務，如果把這些資源用 Motan 協議來實現資源服務化，只需要一個Client就能完成所有的服務調用。而且服務治理體系，流量管控體系都可以復用，解決了大家在開發的時候面對各種資源的不同Client實現而各種調研，選型。微博基于OpenResty 實現了 Motan-OpenResty 版本，就是想以此來對OpenResty 社區在資源服務化方面實現復用，提供更多更方便的服務。

基于泛服務化理念，通過輕薄的Client，就可以調所有服務。雖然改造的時候需要改一點代碼。泛服務化跟 Istio的思路不一樣之處還在于，泛服務化不止針對自己開發的應用級服務，還有一些底層服務，資源的服務。他們都可以通過封裝為簡單的 Motan2 協議來進行簡單的訪問，所有功能都是可編程可擴展的。用過Motan的人都知道，Motan在做擴展的時候特別簡單，比如說要加一個通用的邏輯，無論是擴展一個Filter 還是新增一種HA策略，這個架構是一個可編程，泛服務化的架構。

Weibo Mesh后期規劃

微博是混合云架構，如果是新的公司可能就直接上云了，所以我們后期也考慮在云原生計算方面做一些支持。出于微博本身的技術需要，我們還會在服務治理的整體方案方面做更多的嘗試。我們也希望Weibo Mesh 能做成更通用化的服務方案，讓更多團隊受益。

另外，Motan還有Motan—Openresty 版本。出于我個人對OpenResty的理解，我認為OpenResty 可能是目前唯一稱得上服務器應用開發平臺，把Nginx 作為一個開發平臺，在上面開發各種服務，而且是基于極其簡單、表現力極強的Lua開發。最令人欣喜若狂的是，重啟維護的Stream-lua 模塊讓OpenResty不止能開發 HTTP 服務，同樣能開發 TCP、UDP 服務。基于此的 Motan-OpenResty 可以復用 OpenResty 積累的一切，我希望能在Openresty方面做一些事情。

因為就Mesh體系來講，大家可能都是有包袱的。當有既有技術體系的時候，Java應用或者其他應用，前面都掛著Nginx，從Nginx 到OpenResty 的遷移成本幾乎為零。在整個流量分發當中，它起到比較關鍵的作用，如果能在這一層上做一些事情，那是不是把很多改造的工作又減輕掉了，平臺自己來解決很多問題，應用級別就不需要搞，因為現在比Istio，感覺需要強化一點在于說，有一個Client，需要大家改一點代碼，但是又希望能不能更少的成本，所以我需要做這樣的一些事情，這是我自己后期的一個摸索的方向。希望同樣對這種思路感興趣的同學能一起參與，本身整個體系都是開源的，歡迎大家有什么想法或者是有什么問題提出來，一起來做。

因為覺得在這個方面走的也不算特別早，也不晚，現在在業務場景上真正落地的Mesh的，微博應該是比較早的，而那個Motan-Openresty版本可能是基于最新的Openresty Stream模塊開發的。那個現在也作為Openresty社區比較標準版的Stream模塊開發樣板項目，也希望大家多多的關注，我今天的分享就到這，謝謝大家。

關注Service Mesh中文網公眾號(賬號ID：servicemesh），回復1216，即可下載本次演講實錄PPT.