大家好，我今天的分享主要圍繞以下幾點，首先跟大家簡要介紹一下微博服務化的演進過程，其次是微博自研跨語言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.