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

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

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

微博平臺服務化演進

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

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

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

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

跨語言RPC要點

異構(gòu)系統(tǒng)如何做整體服務化的解決方案，也是今天探討的一個主題。

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

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

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

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

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

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

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

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

基于 Motan-Go的 Weibo-Mesh

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

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

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

今天講的這個可能比較簡單，目的是希望大家能更好的入戲，更好的理解?？梢杂弥边B的方式，或用任何其它方式，像我們用了 Motan。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

服務治理是Motan體系的積累，服務傳輸就是通過它來收發(fā)請求，流量過來，因為請求都經(jīng)過Mesh層，所以通過時時調(diào)用的信息，來時時調(diào)配流量，對整體系統(tǒng)進行保障。

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

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

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

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

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

Weibo Mesh改造收益

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

監(jiān)控里會經(jīng)?？吹揭恍╅L尾的調(diào)動，發(fā)現(xiàn)系統(tǒng)性很好。但是真正跑起來，因為網(wǎng)絡或者機器的因素，可能會導致后面的長尾特別長，特別占資源。如果在 Mesh上，時間長于某一個閾值的時候，就再給發(fā)一個，如果后發(fā)的請求響應先回來的話，可以把前面的請求拋掉。

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

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

面向未來架構(gòu)，重新定義服務化

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

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

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

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

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

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

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

Weibo Mesh后期規(guī)劃

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

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

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

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

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