Service Mesh 是近兩年比較火的微服務(wù)化新方式，也產(chǎn)生了一大批以 Istio 為代表的 Service Mesh 實(shí)現(xiàn)。

微博基于實(shí)際業(yè)務(wù)需求，打造并開(kāi)源了自己的 Weibo Mesh，并且內(nèi)部已經(jīng)在重點(diǎn)業(yè)務(wù)上進(jìn)行大規(guī)模落地。

本文將從如下幾個(gè)部分為大家詳細(xì)解讀 Weibo Mesh，希望可以為大家?guī)?lái)服務(wù)化方向上的一些靈感，更好的服務(wù)于自己的業(yè)務(wù)：

• 微博服務(wù)化挑戰(zhàn)
• 服務(wù)化新思路
• Weibo Mesh 方案介紹
• 生產(chǎn)實(shí)踐
• 總結(jié)

微博服務(wù)化挑戰(zhàn)

 

首先，為大家介紹下微博服務(wù)化面臨的挑戰(zhàn)。微博的形態(tài)比較特殊，除去常態(tài)午/晚高峰流量較高外，突發(fā)熱點(diǎn)事件的殺傷力更大。

熱點(diǎn)事件來(lái)襲時(shí)，流量極短時(shí)間內(nèi)呈現(xiàn)爆炸式增長(zhǎng)，并且往往事件爆發(fā)沒(méi)有任何征兆。這對(duì)于微博服務(wù)化及穩(wěn)定性均帶來(lái)了極大挑戰(zhàn)。

如果其中某一個(gè)環(huán)節(jié)掉鏈子，不能及時(shí)感知并作出應(yīng)對(duì)，極有可能會(huì)導(dǎo)致雪崩式宕機(jī)，導(dǎo)致全站掛掉。

那么怎么解決這種問(wèn)題呢?首先會(huì)想到自動(dòng)擴(kuò)縮容/降級(jí)建設(shè)，但是我們決策依賴是什么呢?又如何滿足系統(tǒng)可觀測(cè)性要求，以及如何評(píng)價(jià)系統(tǒng)可用性及冗余度呢?

究其本質(zhì)，系統(tǒng)的服務(wù)治理建設(shè)非常重要，它會(huì)直接影響到服務(wù)可用性。但是微博技術(shù)棧的多樣性又導(dǎo)致了在微服務(wù)化和服務(wù)治理方面困難重重。

 

從技術(shù)層面看，微博的典型服務(wù)調(diào)用大致如上圖，業(yè)務(wù)體系會(huì)調(diào)用平臺(tái)體系的多個(gè)接口，例如通過(guò)平臺(tái)接口獲取微博內(nèi)容。

平臺(tái)體系主要是 Java 技術(shù)棧，本來(lái)微服務(wù)相關(guān)解決方案也多，又因?yàn)榉?wù)化時(shí)間較早，平臺(tái)微服務(wù)體系建設(shè)相對(duì)比較完善，同時(shí)也產(chǎn)出了一些優(yōu)秀開(kāi)源框架，比如 Motan 微服務(wù)框架。

業(yè)務(wù)方的語(yǔ)言棧：多樣化，基本涵蓋了所有主流語(yǔ)言，其中 PHP 相關(guān)系統(tǒng)流量占比較大。

調(diào)用鏈路：通常情況下業(yè)務(wù)方和平臺(tái)使用 RestFul API 進(jìn)行交互。一次請(qǐng)求調(diào)用要經(jīng)過(guò) 4，7 層的層層調(diào)度，服務(wù)穩(wěn)定性還時(shí)常遭受網(wǎng)絡(luò)抖動(dòng)及 DNS 不穩(wěn)定的困擾，在中間層的消耗是不容忽視的。

另外，業(yè)務(wù)部門(mén)的語(yǔ)言種類(lèi)繁多，間接導(dǎo)致了各部門(mén)微服務(wù)體系建設(shè)參差不齊。

峰值流量應(yīng)對(duì)需要所有部門(mén)所有業(yè)務(wù)模塊的通力協(xié)助和聯(lián)動(dòng)，考驗(yàn)的是整站實(shí)力，我們需要所有模塊都能具備高水平的服務(wù)治理能力。因此我們迫切需要解決跨語(yǔ)言微服務(wù)化問(wèn)題。

 

上圖是微博平臺(tái)內(nèi)部的微服務(wù)體系支撐圖，平臺(tái)實(shí)現(xiàn)以 Motan 框架為核心的微服務(wù)治理體系 。

此外，還有自研的 Vintage 注冊(cè)中心及 Open DCP 智能彈性調(diào)度平臺(tái)以及 Graphite 實(shí)時(shí)監(jiān)控平臺(tái)，可以看出平臺(tái)微服務(wù)架構(gòu)有完善的 DevOps 支撐。

業(yè)界的大趨勢(shì)是云原生，微服務(wù)作為云原生重要的一環(huán)，是我們必須要突破的。

微博服務(wù)化新思路

跨語(yǔ)言服務(wù)治理嘗試

為了解決跨語(yǔ)言服務(wù)治理的問(wèn)題，我簡(jiǎn)單介紹一下我們嘗試過(guò)哪些解決方案。

 

這里有個(gè)大背景，Motan 由于是微博內(nèi)部使用已久，經(jīng)歷過(guò)重大考驗(yàn)并且開(kāi)源的優(yōu)秀框架，它積累了很多優(yōu)秀的服務(wù)治理經(jīng)驗(yàn)，所以我們服務(wù)化改造要充分考慮 Motan 的存在。

我們嘗試將 Motan 適配 Yar 這種 PHP 的 RPC 協(xié)議，PHP 可以與 Server 端的 Java 進(jìn)行通訊，但 PHP 并不能進(jìn)行服務(wù)發(fā)現(xiàn)。

于是我們?cè)?PHP 旁邊加一個(gè) Daemon 程序，也考慮過(guò)使用 Nginx，來(lái)做服務(wù)發(fā)現(xiàn)。

當(dāng)然問(wèn)題也是顯而易見(jiàn)的，這樣改造會(huì)導(dǎo)致業(yè)務(wù)侵入變高，成本變大，擴(kuò)展性也較差，何況并沒(méi)有解決 PHP 做 Server 端的服務(wù)治理問(wèn)題。

我們也嘗試過(guò) GRPC，當(dāng)然跨語(yǔ)言調(diào)用能解決，但是這里遇到幾個(gè)問(wèn)題，一個(gè)是如何進(jìn)行服務(wù)治理，另外一個(gè)是 PB 序列化問(wèn)題。

由于微博場(chǎng)景的內(nèi)容結(jié)構(gòu)體非常大，效率并不比 Json 高，業(yè)務(wù)變更導(dǎo)致 PB 文件的變更讓升級(jí)維護(hù)成本變得難以接受，另外序列化數(shù)據(jù)遇到問(wèn)題調(diào)試也變的困難。

 

此外 ，技術(shù)棧的多樣性也會(huì)引發(fā)一系列的問(wèn)題。即使我們解決了 PHP 到 Java 的調(diào)用問(wèn)題。但是相同的治理功能，不同的語(yǔ)言不可能再實(shí)現(xiàn)一遍。

Motan 框架積累下來(lái)的服務(wù)治理經(jīng)驗(yàn)是我們需要傳承和發(fā)揚(yáng)的，那如何均衡這些問(wèn)題及解決方案呢?

跨語(yǔ)言服務(wù)化本質(zhì)

 

我認(rèn)為跨語(yǔ)言服務(wù)化的本質(zhì)，總結(jié)下來(lái)有兩點(diǎn)：

• 數(shù)據(jù)交互
• 服務(wù)治理

數(shù)據(jù)交互設(shè)計(jì)要考慮跨語(yǔ)言及協(xié)議中立，服務(wù)治理設(shè)計(jì)要靈活全面且可擴(kuò)展。

 

上圖我列舉了跨語(yǔ)言服務(wù)化方式的優(yōu)缺點(diǎn)：

傳統(tǒng)的 HTTP 代理，可以解決不同服務(wù)之間的調(diào)用。HTTP 就是傳統(tǒng)的走網(wǎng)關(guān)，較容易實(shí)現(xiàn)，但因?yàn)閮?nèi)部的調(diào)用每個(gè)人都要加網(wǎng)關(guān)，這就增加了鏈路，導(dǎo)致擴(kuò)展能力低。

RPC 模塊或者 Agent 代理。RPC 框架業(yè)界有很多，大多 Java 棧的，功能也齊全，但跨語(yǔ)言維護(hù)成本非常之高。

Agent 代理是一個(gè)新的思路，Agent 代理的研發(fā)成本、維護(hù)成本、使用成本對(duì)比起來(lái)均比較折中，即我們獨(dú)立一個(gè) Agent 來(lái)專門(mén)解決我們遇到的跨語(yǔ)言服務(wù)化困擾。

那樣既能釋放傳統(tǒng)的業(yè)務(wù)端的服務(wù)治理壓力，又能傳承 Motan 框架的精髓，也不需要實(shí)現(xiàn)多語(yǔ)言服務(wù)治理邏輯，更可以讓業(yè)務(wù)和 Agent 互相獨(dú)立發(fā)展，可謂一舉多得。

這個(gè)思路最終也演化成了今天的 Weibo Mesh：

 

由此微博走向了 Service Mesh。微博走向 Service Mesh，并不是盲目追趕新的技術(shù)潮流。

我們立足于現(xiàn)狀，立足于解決實(shí)際業(yè)務(wù)問(wèn)題，并一步步探索過(guò)后，發(fā)現(xiàn)最終的解決方案與 Service Mesh 思路不謀而合。從側(cè)面也驗(yàn)證了 Service Mesh 思路解決服務(wù)化問(wèn)題的合理性和前瞻性。

 

上圖，我們可以用正交分解法來(lái)理解 Service Mesh，可以看到，原有的微服務(wù)被拆分成業(yè)務(wù)邏輯層和服務(wù)交互治理層，其中服務(wù)交互治理層抽象為 Service Mesh。

Service Mesh 把服務(wù)間的交互與治理邏輯從業(yè)務(wù)中進(jìn)行解耦，抽象獨(dú)立成一個(gè)專門(mén)的處理模塊。

通常 Mesh Agent 以 Sidecar 的形式和業(yè)務(wù)進(jìn)行本機(jī)部署，Agent(以下 Mesh Agent 簡(jiǎn)稱 Mesh 或 Agent)可以理解為服務(wù)的基礎(chǔ)設(shè)施層，業(yè)務(wù)無(wú)需關(guān)心服務(wù)間交互/治理細(xì)節(jié)，全部交由 Agent 統(tǒng)一處理。

Service Mesh 帶來(lái)的是微服務(wù)架構(gòu)思路的轉(zhuǎn)變，為業(yè)務(wù)開(kāi)發(fā)帶來(lái)了諸多架構(gòu)上的優(yōu)勢(shì)，Agent 及業(yè)務(wù)均可獨(dú)立發(fā)展，通常 Agent 交由運(yùn)維管理，業(yè)務(wù)開(kāi)發(fā)交由業(yè)務(wù)線，故整體可以做到持續(xù)開(kāi)發(fā)、持續(xù)集成。

Mesh 思路不光可以解決跨語(yǔ)言服務(wù)化的問(wèn)題，也可以解決資源服務(wù)化問(wèn)題，而這些改造基本都對(duì)業(yè)務(wù)方透明。

Weibo Mesh 方案介紹

 

下面具體介紹下 Weibo Mesh 的實(shí)現(xiàn)方案。上圖是 Weibo Mesh 架構(gòu)圖，除了必須的 Mesh Agent 外，考慮到業(yè)務(wù)遷移及實(shí)際落地需要，這里在業(yè)務(wù)代碼和 Mesh 之間增加了 Client。

 

這個(gè) Client 非常輕，其核心功能是封裝 Mesh 請(qǐng)求，方便業(yè)務(wù)進(jìn)行 Mesh 調(diào)用，盡可能降低業(yè)務(wù)遷移成本。

實(shí)際上在 Client 中我們也實(shí)現(xiàn)了其他一些對(duì)業(yè)務(wù)友好的功能，同時(shí)對(duì) Mesh 調(diào)用進(jìn)行了功能增強(qiáng)。

比如可以在 Client 中進(jìn)行跨語(yǔ)言的序列化，Mesh 故障轉(zhuǎn)移，請(qǐng)求多發(fā)，超時(shí)控制等。

當(dāng)然不同業(yè)務(wù)方可以進(jìn)行功能定制。Client 和業(yè)務(wù)相同的語(yǔ)言編寫(xiě)，其核心目的是幫助業(yè)務(wù)進(jìn)行平滑遷移。

Mesh 層實(shí)現(xiàn)了 Service Mesh 的核心功能，包括發(fā)現(xiàn)、交互、路由、治理。

Weibo Mesh 是由 Go 實(shí)現(xiàn)的，國(guó)內(nèi)各大廠商的 Mesh 數(shù)據(jù)平面也大多使用 Go 來(lái)實(shí)現(xiàn)。

Go 具有優(yōu)秀的性能及易用性，又是云時(shí)代比較推崇的語(yǔ)言，未來(lái) Mesh 層極有可能結(jié)合容器，沉淀成為容器的一個(gè)基礎(chǔ)設(shè)施層。

Weibo Mesh 數(shù)據(jù)面

剖析一個(gè) Service Mesh 服務(wù)，一般通過(guò)數(shù)據(jù)面和控制面。首先來(lái)看一下 Weibo Mesh 在數(shù)據(jù)平面的表現(xiàn)，包含五個(gè)核心模塊：

• Cluster(集群管理)，對(duì)分組下通過(guò)服務(wù)發(fā)現(xiàn)回來(lái)的的節(jié)點(diǎn)列表的抽象管理。
• HA(高可用策略)、LB(負(fù)載均衡)。
• Endpoint(服務(wù)節(jié)點(diǎn)的抽象)，本質(zhì)上是 IP 和端口，但從代碼層面看，它是服務(wù)節(jié)點(diǎn)的抽象，通過(guò) Endpoint 可以進(jìn)行直接的調(diào)用，可以理解為它是調(diào)用的一個(gè)單元。
• Protocol(Motan2/傳輸協(xié)議+Simple/序列化協(xié)議)。

下面一一介紹這些模塊。

①Cluster 模塊

 

調(diào)用方請(qǐng)求通過(guò)本機(jī)的 Mesh，在 Cluster 模塊處理中，首先經(jīng)過(guò)一系列集群粒度的 Filter Chain(過(guò)濾鏈，包含集群 Metric，熔斷，攔截，鑒權(quán)，分組切換等功能，它們以鏈?zhǔn)浇Y(jié)構(gòu)進(jìn)行組織調(diào)用，支持任意過(guò)濾功能擴(kuò)展)。

然后再經(jīng)過(guò)高可用策略跟負(fù)載均衡策略篩選出一個(gè)可用的 Endpoint，在 Endpoint 中又會(huì)進(jìn)行請(qǐng)求粒度的 Filter Chain(單機(jī)的日志記錄，Metric 等)，通過(guò)進(jìn)行請(qǐng)求序列化，根據(jù)傳輸協(xié)議進(jìn)行組裝，最終通過(guò) Endpoint 把請(qǐng)求發(fā)到對(duì)端的 Mesh 上。

②高可用策略

 

Weibo Mesh 中的高可用策略，支持一般的常用策略，比如 Failfast，F(xiàn)ailover 等，負(fù)載均衡支持權(quán)重輪巡，根據(jù)權(quán)重輪巡、隨機(jī)等常用策略。當(dāng)然也可以定制自己的 HA/LB 策略。

Weibo Mesh 中推薦采用的高可用策略是 Backup Request，又叫雙發(fā)。雙發(fā)繼承自 Motan 框架，是我們探索出來(lái)的比較高效可靠的機(jī)制。它可以有效解決長(zhǎng)尾問(wèn)題，同時(shí)能提升系統(tǒng)吞吐量。

傳統(tǒng)解決接口超時(shí)問(wèn)題可能通過(guò)重試，在一次請(qǐng)求發(fā)送之后等待指定的超時(shí)時(shí)間，如果沒(méi)有返回則再請(qǐng)求一次，最差情況下要消耗 2 倍的超時(shí)時(shí)間。

而雙發(fā)機(jī)制則不然，在發(fā)送一次請(qǐng)求后等待 P90(在 T1 時(shí)間內(nèi)有 90% 的請(qǐng)求都能返回則稱 P90=T1，通常系統(tǒng)的 P90 和程序設(shè)置的超時(shí)時(shí)間相比小很多)時(shí)間。

如果請(qǐng)求沒(méi)有返回則在此刻再次發(fā)送一次請(qǐng)求，在超時(shí)時(shí)間內(nèi)，這兩個(gè)請(qǐng)求中取最快返回的那個(gè)。

當(dāng)然，這里有個(gè)防雪崩機(jī)制，假如，超過(guò)一定數(shù)量的請(qǐng)求(比如 15%)都在進(jìn)行雙發(fā)，則認(rèn)為服務(wù)整體有問(wèn)題，會(huì)自動(dòng)停止雙發(fā)。實(shí)踐證明，雙發(fā)機(jī)制的去長(zhǎng)尾效果非常明顯。

③節(jié)點(diǎn)抽象

 

Endpoint 是調(diào)用方 Mesh 到對(duì)端 Mesh 的調(diào)用單元。當(dāng)我們啟動(dòng) Weibo Mesh，在初始化 Cluster 的同時(shí)，也會(huì)對(duì) Endpoint 進(jìn)行初始化，綁定 Filter Chain，并為每個(gè) Endpoint 保持一定數(shù)量的長(zhǎng)鏈接供選擇調(diào)用。

當(dāng)然這里還會(huì)有一些細(xì)節(jié)，如果某個(gè)節(jié)點(diǎn)的調(diào)用失敗，計(jì)數(shù)超過(guò)一定閾值則自動(dòng)摘除節(jié)點(diǎn)，并進(jìn)行定期探測(cè)等待可用，再重新加入可用節(jié)點(diǎn)列表。

④Motan2 傳輸協(xié)議

 

Weibo Mesh 整體沿用了 Motan 的協(xié)議設(shè)計(jì)，并進(jìn)行了升級(jí)。

Motan 支持 Java 的序列化，當(dāng)時(shí)考慮的是 Java 間相互通信，但是考慮到跨語(yǔ)言通信及未來(lái)擴(kuò)展需要，我們把協(xié)議設(shè)計(jì)分成序列化協(xié)議與傳輸協(xié)議。傳輸協(xié)議負(fù)責(zé)把序列化后的數(shù)據(jù)進(jìn)行傳輸，序列化協(xié)議是跨語(yǔ)言的關(guān)鍵。

Motan 傳輸協(xié)議是典型的三段式：

• Header
• Metadata
• Body

Header 中會(huì)標(biāo)記序列化類(lèi)型，消息類(lèi)型(心跳還是正常請(qǐng)求)，可以定義自己的 PB 序列化或是自研的 Simple 序列化。

在 Metadata 中會(huì)有一些方法名、屬性名、用戶參數(shù);在 Body 中存放的是經(jīng)過(guò)序列化后的請(qǐng)求/響應(yīng)體。

Simple 序列化：Simple 設(shè)計(jì)比較簡(jiǎn)單實(shí)用。目前 Simple 序列化支持了基礎(chǔ)類(lèi)型，包括 Bool、String、Int、Float，當(dāng)然它還會(huì)支持一些組合類(lèi)型，例如 String、Bool 組合成的 Map，Array 等。

 

上圖示例，type 是一個(gè)字節(jié)的數(shù)據(jù)類(lèi)型，比如 Bool、String，接下來(lái)是字節(jié)長(zhǎng)度，接下來(lái)是 UTF-8 字節(jié)流。Content 中可以進(jìn)行嵌套，下方就是進(jìn)行嵌套的例子。

 

協(xié)議轉(zhuǎn)換過(guò)程：從協(xié)議層面看 Weibo Mesh 請(qǐng)求流轉(zhuǎn)是調(diào)用方通過(guò)函數(shù)調(diào)用 Client，然后經(jīng)過(guò) Motan2 傳輸協(xié)議以及 Simple 序列化后，經(jīng)過(guò)本機(jī) Mesh，Mesh 層再轉(zhuǎn)發(fā)給對(duì)端的 Mesh。

對(duì)端 Mesh 上層可能是任意一種形式的服務(wù)，比如非 RPC 服務(wù)，所以這里我們有個(gè) Provider 模塊，可以代理 HTTP/CGI 等非標(biāo)準(zhǔn) Service Mesh 服務(wù)，它能把這些服務(wù)導(dǎo)出成一個(gè)具有 Motan 協(xié)議的 RPC 服務(wù)。

通過(guò) Provider 屏蔽了 Server 端服務(wù)的真實(shí)協(xié)議。Provider 外面是標(biāo)準(zhǔn)的 Motan 協(xié)議服務(wù)，內(nèi)部是原有協(xié)議的服務(wù)，這樣對(duì) Server 端來(lái)說(shuō)，遷移到 Weibo Mesh 成本極低。

Weibo Mesh 控制面

控制面主要分兩方面：

①策略擴(kuò)展

 

Cluster 和 Endpoint 都有相應(yīng)的 Filter Chain，他們實(shí)現(xiàn)了不同緯度或者粒度的調(diào)用控制策略。

Filter Chain 包括訪問(wèn)日志記錄、Metric、熔斷、限流、降級(jí)等。折中調(diào)用效率和耦合程度，它們都是以插件形式存在于 Weibo Mesh 中，也可以自由定制 Filter 策略及調(diào)用順序。

②流量調(diào)度

 

Weibo Mesh 的流量調(diào)度基于注冊(cè)中心。注冊(cè)中心不僅為 Mesh 提供了服務(wù)的注冊(cè)和發(fā)現(xiàn)，也提供了服務(wù)的配置下發(fā)，Mesh 在訂閱注冊(cè)中心的同時(shí)，也需要訂閱相關(guān)的配置項(xiàng)。

比如我們把 A 機(jī)房的流量都路由到 B 機(jī)房去，我們?cè)?Mesh 只要支持這條指令就可以。

生產(chǎn)實(shí)踐

典型場(chǎng)景

 

上圖是網(wǎng)關(guān)，Mesh 在微服務(wù)架構(gòu)中的整體分布圖。一般情況下網(wǎng)關(guān)架設(shè)在服務(wù)邊緣，邊緣節(jié)點(diǎn)主要把控宏觀的流量調(diào)度控制問(wèn)題。

在內(nèi)部，各微服務(wù)之間構(gòu)建 Weibo Mesh，來(lái)有效提高服務(wù)間通信質(zhì)量、可觀測(cè)性等要求。

遷移成本的考量：

• 真正將 Service Mesh 引入到業(yè)務(wù)場(chǎng)景中時(shí)，需要考慮一些問(wèn)題點(diǎn)，比如業(yè)務(wù)部署模式是非云，混合云還是云原生?像微博是混合云，場(chǎng)景不同，因此架構(gòu)也不盡相同。
• Weibo Mesh 要適配注冊(cè)中心。
• 各語(yǔ)言要適配 Client，目前已經(jīng)支持 PHP/C++/C/Python/Lua 等主流語(yǔ)言，Java/Go 原生支持。
• 要適配相應(yīng)的 DevOps 建設(shè)。需要相應(yīng)的監(jiān)控/統(tǒng)計(jì)等平臺(tái)支撐，任何架構(gòu)改造都要有足夠的 DevOps 支撐。

接下來(lái)為大家介紹 Weibo Mesh 正反向代理實(shí)踐。

正向 Mesh

 

上圖是 Weibo Mesh 場(chǎng)景下的正向代理流程。Server 端服務(wù)進(jìn)行注冊(cè)，被調(diào)用方訂閱到，調(diào)用方請(qǐng)求經(jīng)過(guò) Client，再經(jīng)過(guò)本機(jī) Mesh，最終到對(duì)端的 Mesh。需要注意的是虛線部分是故障轉(zhuǎn)移的流程。

假如本機(jī) Mesh Agent 掛掉，Client 會(huì)通過(guò)服務(wù)發(fā)現(xiàn)回來(lái)的節(jié)點(diǎn)快照選擇可用節(jié)點(diǎn)進(jìn)行調(diào)用，達(dá)到故障轉(zhuǎn)移的目的。

反向 Mesh

 

上圖是 Weibo Mesh 場(chǎng)景下的反向代理流程。一般我們的服務(wù)類(lèi)型是 HTTP/CGI，或者其他私有協(xié)議。

反向 Mesh 的亮點(diǎn)在于，不需要 Server 端做任何架構(gòu)的改造，直接架 Weibo Mesh 就可以了。

Mesh Agent 通過(guò) Provider，將原有協(xié)議導(dǎo)出成 Motan2 協(xié)議的服務(wù)對(duì)外進(jìn)行暴露，只需要把導(dǎo)出的服務(wù)注冊(cè)到注冊(cè)中心即可提供服務(wù)。

同時(shí)也不會(huì)影響原有服務(wù)的提供。這里如果你需要把私有協(xié)議導(dǎo)出成 Motan2 協(xié)議服務(wù)，可以自行擴(kuò)展開(kāi)發(fā)。默認(rèn)支持 http/php-cgi 服務(wù)的導(dǎo)出。

反向 Mesh 特色：

• 提供 HTTP/cgi provider，可定制擴(kuò)展。
• HTTP 框架自動(dòng)轉(zhuǎn) RPC，業(yè)務(wù)無(wú)需開(kāi)發(fā)新 RPC 框架。
• Mesh 對(duì) Server 改造無(wú)侵入。

總結(jié)

治理模式的差異

 

傳統(tǒng)服務(wù)調(diào)用，中間可能經(jīng)過(guò)網(wǎng)關(guān)或者 RPC。服務(wù)治理只能存在于一端，一般在 Server 端進(jìn)行服務(wù)治理。

但是 Mesh 服務(wù)，由于 Agent 本機(jī)部署，封裝了服務(wù)治理，可以實(shí)現(xiàn) Client 端或 Server 端的雙向治理，這是 Mesh 服務(wù)的一大特色。

Weibo Mesh 優(yōu)勢(shì)

 

實(shí)戰(zhàn)效果如下圖：

 

上圖可以看到，Mesh 服務(wù)的 Client 端 RT 曲線逼近 Server 端的 RT，這說(shuō)明點(diǎn)對(duì)點(diǎn)的 Mesh 調(diào)用，由于沒(méi)有中間層的損耗，再加上合適服務(wù)治理手段，兩端性能也比較接近。而 HTTP 服務(wù)則有較多的中間層損耗。

右圖可以看到雙發(fā)的 p999 曲線相對(duì)比較直，這說(shuō)明雙發(fā)起到有效削長(zhǎng)尾功能，間接也對(duì)系統(tǒng)性能有提升。

Weibo Mesh 集群

 

目前，微博內(nèi)幾個(gè)核心業(yè)務(wù)之間調(diào)用已經(jīng) Mesh 化，并經(jīng)歷過(guò)重大事件以及春晚的考驗(yàn)，支撐流量還是相當(dāng)大的。

和 Istio 的區(qū)別

 

從控制層面看，Weibo Mesh 把類(lèi)似 Istio 中的 Mixer 和 CA 的功能以插件化的形式放到 Filters 里面。

Istio 服務(wù)需要通過(guò) Pilot 來(lái)做服務(wù)發(fā)現(xiàn)，而 Weibo Mesh 是直接通過(guò)注冊(cè)中心，Istio 用 Envoy 做 Sidecar，而我們基于 Motan 打造了全新的 Agent。

Istio 有一個(gè)特色，上面每個(gè)模塊都可以理解為一個(gè)微服務(wù)，都可獨(dú)立拆分部署。

但是 Weibo Mesh 為了效率和內(nèi)部落地的方便，更多的進(jìn)行了插件式耦合，整體性能相比 Istio 也會(huì)更好。

 

上圖可以看到 Istio 通過(guò)云平臺(tái)適配各種 API，來(lái)進(jìn)行服務(wù)發(fā)現(xiàn)，Weibo Mesh 則是適配注冊(cè)中心。

Istio 更強(qiáng)調(diào)依據(jù)容器層面的發(fā)現(xiàn)(直奔云原生)，Weibo Mesh 則可支持通用注冊(cè)中心比如 Consul、ZK 等。

 

Weibo Mesh 通過(guò) Client 攔截 Mesh 請(qǐng)求，模塊化耦合部分功能。高定制化時(shí)，并不能對(duì)服務(wù)做到完全透明。而 Istio 通過(guò) IPtables 流量攔截實(shí)現(xiàn)了業(yè)務(wù)完全無(wú)感知。

WM 進(jìn)行中

 

我們知道 Mesh Agent 并不關(guān)心代理轉(zhuǎn)發(fā)的是什么服務(wù)，所以就有一個(gè)新方向，即資源服務(wù)化，讓資源存儲(chǔ)層也能進(jìn)行服務(wù)化。

Weibo Mesh 解決跨語(yǔ)言服務(wù)化的思路也同樣適用于服務(wù)與資源之間的調(diào)用問(wèn)題。微博服務(wù)有很多資源依賴，MC、Redis、MySQL、MCQ 等。

我們可以在資源層架設(shè) Agent，同樣可以達(dá)到資源即服務(wù)，也就是泛服務(wù)化。目前我們內(nèi)部也已經(jīng)有基于 Weibo Mesh 的資源服務(wù)化使用場(chǎng)景。

WM 未來(lái)發(fā)展方向

 

未來(lái) Weibo Mesh 主要有兩個(gè)方向，一個(gè)是繼續(xù)推進(jìn)云原生，一個(gè)是在易用性方面繼續(xù)打磨。

Weibo Mesh 打通云平臺(tái)和注冊(cè)中心推進(jìn)云原生，結(jié)合容器編排在服務(wù)治理上進(jìn)行優(yōu)勢(shì)互補(bǔ)。

此外，我們也會(huì)積極努力推進(jìn)，讓 Mesh 整合進(jìn) L5 這一層。我們還會(huì)繼續(xù)進(jìn)行探索解決業(yè)務(wù)方接入不方便的地方，比如說(shuō)更加方便的流量攔截方式;更廣泛的語(yǔ)言支持…

Weibo Mesh 始終推崇落地簡(jiǎn)單、功能高效可靠，隨著 Mesh 更大規(guī)模的推廣，場(chǎng)景越來(lái)越極端，性能要求越來(lái)越高，我們?cè)谶@方面也會(huì)持續(xù)打磨。歡迎大家一起加入 Weibo Mesh!

作者：丁振凱

出處：轉(zhuǎn)載自微信公眾號(hào)：壹佰案例。

[[259944]]

 

丁振凱，微博搜索架構(gòu)師。曾先后就職于 360，藝龍等公司。目前主要負(fù)責(zé)微博搜索泛前端架構(gòu)工作，主導(dǎo)熱搜體系峰值流量應(yīng)對(duì)及穩(wěn)定性解決方案，以及微服務(wù)方案的落地。在 Web 系統(tǒng)架構(gòu)方面擁有比較豐富的實(shí)踐和積累，倡導(dǎo) DevOps 和 Service Mesh。2017 年十一鹿晗關(guān)曉彤事件中一不小心成為網(wǎng)紅工程師，并成功登上自家熱搜榜。