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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

于是我們在 PHP 旁邊加一個 Daemon 程序，也考慮過使用 Nginx，來做服務(wù)發(fā)現(xiàn)。

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

Agent 代理是一個新的思路，Agent 代理的研發(fā)成本、維護成本、使用成本對比起來均比較折中，即我們獨立一個 Agent 來專門解決我們遇到的跨語言服務(wù)化困擾。

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

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

 

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

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

 

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

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

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

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

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

Weibo Mesh 方案介紹

 

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

 

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

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

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

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

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

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

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

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

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

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

下面一一介紹這些模塊。

①Cluster 模塊

 

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

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

②高可用策略

 

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

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

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

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

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

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

③節(jié)點抽象

 

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

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

④Motan2 傳輸協(xié)議

 

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

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

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

• Header
• Metadata
• Body

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

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

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

 

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

 

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

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

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

Weibo Mesh 控制面

控制面主要分兩方面：

①策略擴展

 

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

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

②流量調(diào)度

 

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

比如我們把 A 機房的流量都路由到 B 機房去，我們在 Mesh 只要支持這條指令就可以。

生產(chǎn)實踐

典型場景

 

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

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

遷移成本的考量：

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

接下來為大家介紹 Weibo Mesh 正反向代理實踐。

正向 Mesh

 

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

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

反向 Mesh

 

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

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

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

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

反向 Mesh 特色：

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

總結(jié)

治理模式的差異

 

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

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

Weibo Mesh 優(yōu)勢

 

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

 

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

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

Weibo Mesh 集群

 

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

和 Istio 的區(qū)別

 

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

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

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

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

 

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

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

 

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

WM 進行中

 

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

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

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

WM 未來發(fā)展方向

 

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

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

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

Weibo Mesh 始終推崇落地簡單、功能高效可靠，隨著 Mesh 更大規(guī)模的推廣，場景越來越極端，性能要求越來越高，我們在這方面也會持續(xù)打磨。歡迎大家一起加入 Weibo Mesh!

作者：丁振凱

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

[[259944]]

 

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