Weibo Mesh的發展

初代Motan

微博從2013年開發了Java語言的Motan RPC框架，基於此完成了服務化改造。Motan從2013年上線至今經歷過每一個熱點事件，三節高峯的挑戰，穩定性和可靠性都獲得了實際場景的驗證。這些經歷之下微博Motan也積累了一套服務治理型RPC的服務化體系。

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

上面是微博平臺技術體系概貌，是一個基於Open DCP彈性雲計算平臺和Motan RPC的服務化架構，通過幾年的運營和考驗，咱們已經在混合雲和服務化方向有了豐富的經驗和積累。在解決了微博內部服務高可用，高性能的問題後，業務方平臺服務調用的問題開始顯現出來。好比調用鏈路過長，致使坑多性能差，好比每一個服務自己須要作高可用和服務治理，這些事情平臺已經有了豐富積累，你們在作一遍重複嚴重且浪費資源。平臺但願將平臺技術服務到業務方時，須要一個跨語言的解決方案。從2016年起，咱們開始了跨語言服務化改造之路。

跨語言RPC要點

異構系統之間如何作到服務化的解決方案呢？

將原有Java體系積累的經驗加以總結，給其餘技術棧業務賦能，更好的維護微博總體的穩定性和高可用。

上面是跨語言RPC的幾個技術要點，最下面是可靠性和易用性，好比咱們Motan有Cluster的概念，每次調用都從這個Cluster裏面經過負載均衡策略來找出可用節點endpoint，再經過高可用策略完成調用。整個過程各類理念可複用，各類語言按章實現就好。各類策略能夠按需根據實際狀況進行擴展。而傳輸，IO，進程線程模型等各類語言不同，須要根據語言特色來選擇實現。

協議和序列化是跨語言比較重要的一點，由於要讓不一樣語言互相理解，互相溝通。

Motan解決的是微博內部Java服務之間的調用，所以Motan1協議時，其實沒有考慮到跨語言的問題，用的是對Java友好的Hessian。後期在跨語言方面，Motan1的協議顯然對跨語言不友好，Motan2對協議就給了一個足夠容易理解的協議，是一個簡單的TCP描述。好比，請求一些方法，服務的分組，或者Body，請求發過去，對方收到語言後，怎樣讓這個語言理解呢？關鍵一點在於序列化。

如今Motan使用簡單序列化方式，只支持幾種簡單的類型，不過也一直在迭代中。本質上，它仍然是簡單協議，會盡可能保證它的簡單。只有足夠的簡單，才能在跨語言上下降成本，開發成本還好，主要是語言溝通起來解析成本，好比，編譯型語言有各類明確的強類型，而解釋型語言不須要強類型約束，如何讓他們很好的溝通，就須要取捨。

Weibo Mesh是基於Motan來作的，須要對Motan有個總體的瞭解。

Weibo Mesh最開始支持Java，如今支持Golang，Openresty，Php。

基於Motan-Go的Weibo-Mesh

我認同Service Mesh是下一代微服務，系統若是很複雜，服務化到必定程度，因爲微服務的粒度和規模慢慢增大，出現依賴複雜度增長帶來的流量交錯，難以管控及難以治理等一系列問題。爲了解決這些就須要一個東西很好的管控這些服務和流量，這就是Mesh。

看一看Mesh Istio怎麼玩的，Istio有一個基於Envoy的數據傳輸層，另外是控制面板，Istio經過這個控制面板完成流量調度，鑑權，服務治理等工做。這是Istio如今的玩法。

Weibo Mesh最開始只是想作跨語言，解決調用鏈路長的問題。以前的請求須要到註冊中心尋找目標服務，經過HA作服務路由，繞了一大圈，鏈路特別長，咱們但願跨語言的Motan RPC，Client對Server發起直連，經過點對點的通訊來解決鏈路過長的問題。

最開始作跨語言想GRPC已經作好了，就想經過Motan支持GRPC協議方式來實現Motan實現跨語言調用。 後來改完以後準備對接Php，發現須要大範圍的改代碼，並且性能沒有宣傳的那麼好。若是經過GRPC作跨語言，服務治理怎麼作呢？

以Php爲例，每一次請求過來過程就結束了，沒有一個常駐內存可用於存儲每次請求狀態的地方來實現服務發現，服務治理之類的事情。

咱們嘗試在本機的後臺進程作服務發現，或者在Nginx上基於OpenResty的timer來實現服務發現，併發送結果寫到Php的$_SERVER變量中，讓Php能直接使用等，但效果並不理想。

因此總體用GRPC作跨語言的方案並不理想，後來咱們想既然解釋型語言的跨語言服務化因爲語言自己特性和特殊場景下，不適合直接經過語言自己實現，這樣，不如作個代理。這個代理就是Weibo Mesh的雛形，相似於Service Mesh中的SideCar。

好比Java啓動一個服務，這種狀況下，Java Client訪問這個服務是這樣的流程：

• Java Client啓動時會根據配置去註冊中心訂閱本身要訪問的服務；
• 請求過程當中會有一個線程不斷從註冊中心發現當前可用的節點列表回來；
• 針對於Php就給它一個Go Agent，服務發現，訂閱，治理這些事情就讓Motan Go Agent來作，其餘都同樣。

若是Php要作Server呢？

Php要作Server，咱們使用Motan Go Agent來幫助Php的服務導出，因此Motan Go Agent既要作服務發現，也要負責Php服務的註冊，Motan Go Agent更像一個Motan Server。 啓動時須要導出Php的服務，並保持註冊中心狀態的上報更新。同時須要把請求轉發給後段Php作處理，他們之間可能基於CGI或是Http協議完成。

這樣咱們須要的服務治理方式，高可用等保障，經過邏輯封裝實現起來就容易多了。

針對於Java，Golang這種方便實現服務化的語言，用Motan實現，其餘的語言經過Motan Go導出服務。

改造後性能符合預期，規模大了以後，節點多了以後，經過擴展註冊中心功能來解決。

Istio中經過一些請求的Header數據，經過一些規則基於Iptables的流量轉發，而Weibo Mesh不須要轉發，由於服務都是經過發現回來的，調用時明確的，不須要轉發，同時爲了流量更均勻，更好的控制流量，須要一個自動流量調度和彈性擴容。

Weibo Mesh改造收益

將來的架構

在Service Mesh中沒有了Client和Server的概念，都是Service。