螞蟻金服大規模微服務架構下的Service Mesh探索之路

小螞蟻說：

本文是根據螞蟻金服 Service Mesh 布道師敖小劍在 Service Mesher社群進行的第一次 Meetup 上分享的《大規模微服務架構下的 Service Mesh 探索之路》現場演講内容實錄整理編輯而成，希望能給關注 Service Mesh 産品的朋友們帶來幫助和了解。

講師PPT下載下傳位址：

https://github.com/servicemesher/meetup-slides

視訊直播回放：

http://www.itdks.com/eventlist/detail/2311

▲ 螞蟻金服Service Mesh 布道師敖小劍

前言

今天給大家帶來的内容叫做Service Mesh探索之路，但是在前面加了一個定語：大規模微服務架構下。之是以加上這個詞，是因為我們這個體系是在螞蟻金服這樣一個大的架構下進行的，螞蟻金服的體量大家可以想象，是以這個探索會帶有一個非常隆重的色彩：對性能/規模/高可用等方面的思考。

今年6月初，在深圳的GIAC大會，我們同僚披露了這個正在開發中的 Service Mesh産品，我們現在暫時命名為 SOFA Mesh。我們目前的産品都在 SOFA品牌下，比如 SOFA RPC，SOFA Boot等。今天我們詳細介紹 SOFA Mesh這個單獨産品，上次大會隻是簡單披露，也就是給大家介紹說我們有這樣一個産品，而我今天的内容是把這個産品詳細展開。

主要是三個内容：一是 SOFA Mesh的技術選型，二是它的架構設計，以及在最後跟大家聊一下，螞蟻金服在 SOFA Mesh上的開源政策。

一、技術選型

先上來一堆要求，剛才我們提到過的，因為是大規模，而螞蟻金服的體量，大家可以想象到的。實際上在性能，穩定性上，我們的衡量标準，我們考慮的基石，都是以螞蟻金服這樣的一個規模來考慮的。

在這樣一個規模下，我們會涉及到一些跟其他公司不太一樣的地方，比如說：我們在性能的考量上會比較重一些。因為如果性能不高的話，可能沒法支撐我們這樣一個規模。在考慮性能的時候，就有另外一層考量：架構和性能之間的這個權衡和取舍是要非常謹慎的。性能要求不太高的情況下，架構可能的選擇，和需要比較高性能的情況下，可能會有完全不一樣的取舍。穩定性就不必說了。

部署方面的要求，首先是我們會用于多種場合：

• 主站是指我們螞蟻金服内部，比如大家用的最多的支付寶。
• 金融雲，可能有一部分和我們有聯系的同學會有所了解，這個是我們推出的針對金融行業的雲。
• 然後還有我們的外部客戶

部署上會要求這三個場合都能使用。

部署環境也會有多種，剛才我們調查到，有部分同學相對比較前沿一些，現在就已經上k8s了。有部分同學還是停留在以前的虛拟機以及實體機這種狀态，也有一部分自己上了容器，還有部分同學可能會使用不同的公有雲和私有雲。這幾種不同的環境，我們都是需要滿足的。

第三點可能要特殊一些，需要滿足各種體系。剛才我們在調查的時候了解到，有部分同學是在做舊有系統改造，那在改造的時候就會遇到一個問題：除了Service Mesh之外，還需要跟原來的體系，比如說 SOFA，或者社群主流架構如Dubbo，Spring Cloud，互相之間打通和過渡。怎麼在技術轉型期間平滑的讓業務做變更，是我們在整個技術選型之前提出的實際要求。整個技術選型是在這樣一個背景下進行的。

我們做技術選型的時候，有兩大方向：

• 一個選擇是在開源産品上做
• 我們先看右邊的路線，起點是找一個開源産品，fork出來，做增強/擴充/定制，和内部內建。因為開源産品還在繼續往前走，是以我們會持續做版本更新，也可以從社群拿到最新版本。相當于是從開源社群做擷取，然後接下來做回報，讓我們的一些産品，我們做的東西回報回去。
• 這條路線比較大的好處是從一開始就可以得到社群的支援，社群往前走的時候也跟着往前走。如果做的比較好，願意讓自己的産品反哺社群，那麼社群也可以從中受益。
• 當然這裡面有一個小問題，就是說可能我們自己這個産品路線和開源産品路線可能會有一些分歧，可能我們領先一步，也可能他們領先一步，或者一個事情可能有兩個做法。這種情況下，如何讓社群的接受我們的改動，會變成這條路線上比較頭疼的一個問題。
• 這是兩條路線上的第一條，選擇以開源産品為起點。

• 另外一種思路全新打造
• 或者，如果手上已經有一套類庫或者架構，可以在這個基礎上做包裝。
• 這條路線有一個好處，可控性比較強。因為整個體系是全新打造或者在原有體系上演進而來的，整套體系基本上都是自己的開發團隊完全可控的。
• 這條路線會遇到一個問題，因為長期上看我們也是希望開源的，而開源就意味着不能将自己内部太多的定制化的東西直接做進去，是以在架構上需要考慮可擴充性，可以定制化。因為開源出去的應該是一個标準産品，這樣的産品才可以得到社群和客戶的認可。客戶希望看到一個幹淨的東西，也需要做擴充，整個體系在設計上會有所不同。

兩條路線的終點，從圖上看，我們有兩個目标：

1. 第一個目标是内部落地
2. 前面提到的，我們需要在螞蟻金服主站這樣的一個巨大規模的場景下落地，這是螞蟻金服自身的需求。
3. 第二個目标是技術輸出
4. 因為螞蟻金服在公司政策上有科技輸出的内容，不僅僅我們自己用，我們還需要給出去。

現在我們來看這個問題：目标在這裡，然後有左右兩條路線，我們該怎麼選擇？在做的技術選型的時候，這是一個非常大的分歧點，到底是從左邊走，還是從右邊走？

在公布結果之前，我們先來看一下有什麼可選方案。

這是開源方案的選擇，第一代的Service Mesh。

左邊的Linkerd，這個基本上，目前看，大家都已經有點嫌棄了。因為它沒有控制平面，用Scala寫的，基于JVM，資源消耗比較大。它的可擴充性比較有限的，相對于Envoy的擴充性。然後它裡面有個dtab，有接觸到的同學就會有認識：dtab的文法，非常的不人性，很難了解，使用不太友善。另外它的功能是遠遠不夠的，對于螞蟻金服來說。另外這個産品本身的發展前景已經很暗淡了，是以這個選項就被淘汰了。

Envoy是非常不錯的，做了一些令我們意外的事情：安心的去做好資料平面，沒有往上面做很多的東西，而是創造性的提出了XDS API。整個設計是非常優秀的，性能和穩定性也表現得非常好，甚至看到業界有一個趨勢，有一部分的公司開始把他們的nginx替換了，不再用nginx了，而是用envoy。也就是說，現在它的穩定性和性能達到和nginx一個級别，nginx大家應該都有聽說過，envoy已經是這樣一個工業成熟度。

我們當時選型時是比較頭疼的，因為它是c++寫的，c++14。和我們技術棧的差異會比較大，因為螞蟻的技術棧是以Java為主，長期的話，我們可能部分轉到Golang上去。在這種情況下，C++的技術棧，會讓我們比較尴尬，也不是說我們找不到會c++的同學，而是說，長期上會和我們的方向不一緻，我們要在Java和Golang的技術棧之外再加一個c++，這就比較難受。

然後我們内部會有大量擴充和定制化的需求。因為我們内部有我們自己的産品，我們自己的需求，我們的通訊方案，我們内部的追蹤，監控，日志方案，是以工作量非常大。

總結說，我們覺得Envoy很好，但是我們不能簡單用。但是它在資料平面上的表現我們是非常認可的，Envoy在這點做得非常好。

開源方案裡面的第二代，istio是我們當時的第一選擇，重點關注對象。Istio現在最大的問題在于它遲遲不能釋出生産可用版本，大家如果對istio有了解的話，會知道istio剛剛釋出了0.8版本，第一個長期支援版本，但是這個版本也不是生産可用。不出意外的話，按照目前的進度，istio應該會在7月份釋出它的1.0版本，但是從我們目前的感受上看，1.0估計可能還是不能工業級的使用。是以需要等，而我們沒法等，但是Istio的理念和方向我們非常認可。大家看一看，我們這個技術選型有多糾結。

右邊的Conduit，現在Conduit的最大限制是它隻支援k8s。而現在螞蟻金服還沒有普及k8s，我們現在還有很多系統是跑在非k8s上的。第二是它的資料平面是Rust編寫的，這個語言更加小衆了，在座的同學有沒有人了解Rust這門語言？或者聽過。（備注：現場大概十幾個人舉手）大概10%左右的同學聽過。好，Rust語言排名大概在50名左右。這個語言本身還是蠻認可的，我還很喜歡這個語言，它的一些特性還是非常有道理，如果掌握好還是可以寫出非常好的産品，但是它的入門台階會比較高一點。這個地方比較讨厭的事情是說，因為這個語言本身比較小衆，是以基本上是沒辦法從社群借力的。這裡可以舉個例子，大家可以看一下Conduit的committer的人數，大概是25個左右，還包括像我這種隻送出了幾行代碼的。Conduit從12月份開源到現在已經有半年時間，半年時間隻有這麼多的committer，其中真正有貢獻大概9到10個人，基本上都是他自己的員工。也就說這個産品基本上沒辦法從社群借力，一個産品，如果大家一起來幫忙，其實很多的細節是可以完善的，但是Conduit就卡在Rust語言上。

然後還是同樣有技術棧的問題，因為這個原因，基本上Conduit我們也沒法用了。

我們再看一下國内的在Service Mesh領域，其他的一些比較前衛的同學，他們的選擇會是什麼？

首先是華為，華為自己做了一套Golang版本，名字叫做Mesher。這是由他們之前的一套類庫演進而來。它走的路線是，先有類庫和架構，然後加proxy，proxy打通了之後再慢慢的開始添加控制平面。這是一條非常非常标準的路線，我這邊給一個詞叫做老成持重，因為這條路是最安全的：每一步都是基于現有的産品，很快就可以到下一個裡程碑，然後每個裡程碑都可以解決一些實際問題，可以直接得到一些紅利，這個方案是比較比較穩妥的。比如說第一步是把proxy做進去，有了這個切入口之後，就在第一時間擷取跨語言的紅利，還有技術棧下沉的好處。然後控制平面的創新，可以在這個基礎上慢慢往前做。

在對接Istio這一條上，現在華為的政策，我們現在從公開途徑了解到的是：部分對接istio，也就是有一部分的API相容Istio。但是細節上還不太清楚，因為它的開源還沒出來，目前得到的消息是，會在7月份開源。

第二個是新浪微網誌的Motan Mesh，他們也是Golang的，但他不太一樣，是全新實作。他們用Go語言重新寫了一把，主要原因是因為它沒有golang類庫，Motan是基于Java的。

剛才看到的這兩個産品，他們的思路大體上是相同的，差異在哪裡？就是啟動的時候是用已有的類庫還是重新寫？這兩個選擇之間最大的麻煩在于程式設計語言，華為原來有go的類庫，是以繼續用golang包裝一下就好了。但是新浪的類庫用的是Java，而sidecar選擇的是go語言，是以隻能重新做了。

我們再看騰訊，最近看到他們有類似的産品出來。我們看看他們的資料：在資料平台上繼續選擇Envoy，因為它比較成熟。騰訊的話大家比較熟悉，尤其是騰訊有非常深厚的c++背景，是以Envoy對他們來說，技術棧是非常OK的。而且之前内部其他領域Envoy也是在用的，是以底層非常自然的選擇了Envoy。然後控制平面上，據傳是"掙紮了一下"。這個詞是我抄過的，"他們掙紮了一下"，最後還是選了Istio。然後自己做定制和擴充，然後注意到他們也解耦了k8s。這也是其中一個關鍵的點：要不要綁定k8s？

這裡還有UCloud的一個很有意思的做法，另辟蹊徑啊。他的方案很有意思，是一個輕量級的實踐：從Istio裡面，将Envoy和Pilot單獨剝離出來。就是說不用Istio整體，把Mixer和Auth的子產品去掉，隻要最重要的Envoy，然後把Pilot剝離出來。然後這個Pilot還是個定制版，把其他的adapter幹掉了。Pilot主要是做服務發現，它底層用ETCD，做了一個ETCD的adapter，把其他的adapter從Pilot中去掉。做完這幾個事情之後，整個體系就可以脫離k8s了，這是一個比較有意思的實踐。

總結：在講我們技術決策過程之前，我們過了一下目前市場上的主要産品，以及一部分實踐者的做法。

我們現在來詳細講一下，SOFA Mesh在技術選型上的考慮。

首先第一個，資料平台上Envoy是最符合我們要求的，Envoy确實好。第二個事情是Envoy提出的XDS API設計是非常令人稱道的，我們現在對這個的評價是非常高的。它實際上是一套通用的API，由于時間的緣故，我今天就不在現場展開API的細節。隻能說XDS API基本上已經成為資料平面和控制平面之間的一個事實标準。

在這種情況下，我們其實是想用Envoy的，但是剛才提到我們有個技術棧選擇的問題：我們不願意将c++納入到我們主流的技術棧。然後我們本身有太多的擴充和定制，逼得我們不得不去改Envoy，我們不能簡單的拿過去用，我們需要做很多擴充的。

另外一個事情是，我們這個proxy不僅僅是用于Mesh，我們有可能把它引入到API Gateway裡頭，以及後面會提到的名為Edge Sidecar的子產品。因為這個原因，是以，怎麼說呢，想用，但是不合适用。

第二就是在Istio上，控制平面這一塊Istio可以說是做的最好的。基本上，到目前為止，在控制平面上，暫時我們還沒有看到做的比Istio更好的産品，或者說思路。目前Istio整個設計理念，包括它的産品方向，也是我們非常認可的。

但是Istio的性能是目前最大的問題，而我們有一個重要的前提：大規模應用。要用在螞蟻金服主站這樣一個場景下，性能和穩定性對我們非常非常的重要。第二個問題是它對非k8s的支援不夠理想，因為我們還涉及到一個k8s沒有完全上線的問題。第三個是和侵入式架構互通的問題，我們内部用的是SOFA，對外推出的時候我們的客戶用的可能是Dubbo或者Spring Cloud，Mesh上去之後，兩個系統現在走不通，這是大問題。

最終我們的政策是這樣的，這是我們 SOFA Mesh的技術選型：左邊是Istio現有的架構，Envoy/Pilot/Mixer/Auth，右邊是我們 SOFA Mesh的架構。

• 最重要的第一點：我們用Golang開發的Sidecar替換Envoy，用Golang重寫整個資料平面。
• 第二點是我們會合并一部分的Mixer内容進到Sidecar，也就是Mixer的一部分功能會直接做進Sidecar。
• 第三點是我們的Pilot和Auth會做擴充和增強。

這是我們整個的技術選型方案，實際上是Istio的一個增強和擴充版本，我們會在整個Istio的大架構下去做這個事情，但是會做一些調整。

二、架構設計

然後我們來詳細介紹一下在這個技術選型上我們怎麼去做實作。

首先是Golang版本的Sidecar，我們會參考Envoy，非常明确的實作XDS API。因為XDS API是目前的事實标準，是以我們選擇遵循，然後我們會讓它相容Istio。

在協定支援上，我們會支援标準的HTTP/1.1和HTTP/2，也就是大家常見的REST和gRPC協定。然後我們會增加一些特殊的協定擴充，包括 SOFA協定，Dubbo協定，HSF協定。我們現在正在做這幾個協定的擴充，然後XDS API我們支援，mixer service我們沒有改動，遵循現有實作。

最大的變化在Mixer，其實剛才的Sidecar雖然是全新編寫，但是說白了是做Envoy的替換，在架構上沒有什麼變化。但是第二步的變化就非常大，我們會合并一部分的Mixer功能。

Mixer的三大功能：

1. check。也叫precondition，前置條件檢查，比如說黑白名單，權限。
2. quota。比如說通路次數之類。
3. report。比如說日志，度量等。

三大功能裡面，注意到，前兩個功能是同步阻塞的，就是一定要檢查通過，或者是說quota驗證OK，才能往下走。如果結果沒回來隻能等，因為這是業務邏輯，必須要等。而Report是可以通過異步和批量的方式來做的。

在這裡，我們現在的決策是：我們會将其中的兩個部分(check和quota)合并進來，原有report部分我們會繼續保留在mixer裡面。

可能大家會問：為什麼我們要選擇用這個方案，而不是遵循Istio的标準做法？我們之前聊到，我們會盡量去和Istio做相容，跟随Istio的設計理念和産品方向，但是我們在它的架構上做了一個重大的調整。為什麼？

最大的問題就是對性能的影響。

給大家解釋一下，看右邊這個圖，Envoy在每次請求進來的時候，要去做兩次調用：

1. 第一次在請求轉發之前要做一次check，這個check裡面包含了quota。Check完成通過，才能把請求轉發過去。
2. 請求轉發完成之後，再調用report，報告一下響應時間，日志，度量等資訊

每次traffic都會有兩次調用：一次check，一次report。而這是遠端調用，因為這兩個子產品是兩個程序，Mixer是單獨部署的。

同步阻塞意味着必須要等，遠端調用意味着有開銷而且有延遲。這個事情是發生在每一次請求裡面，意味着整個的性能一定會受影響。而考慮到我們螞蟻金服這樣一個體量，其實我們是很難承受。是以我們有自己的觀點：我們不是太認可這樣的一個方式，我們的想法是說我們要把它拆分出來想一想：

• 如果是需要請求做同步阻塞的功能，比如說黑白名單的驗證，可能要檢查IP位址，可能檢查quota。這些逼請求一定要做同步阻塞等待結果的功能，就不應該放在Mixer中去完成去遠端調用，而應該在Sidecar中完成。
• 這是我們的觀點，原因就是遠端調用帶來的系統開銷，這個代價實在是太高了！
• 然後其他的功能，比如說可以優化為異步的，或者可以以批量方式來送出的，最典型的就是Report。Report其實是可以異步送出，可以把十個請求打包到一個report同時送出，這些都是OK的。

這是我們的基本想法。

這個問題其實在Istio裡面是給了一個解決方案的。最早的時候，Istio 0.1版本中，一出來就發現這個問題。從去年5月份開始到現在，13個月的時間裡，他隻給了一個解決方案，就是在Mixer上的這個位置加了一個Cache。這個的Cache的想法是：把這些結果緩存在Envoy的記憶體裡面，如果下次的檢查參數是相同的，那我們可以根據這樣一個緩沖的設計，拿到已經緩存的結果，就可以避免遠端調用。這個方式是很理想的，對吧？隻要緩存能夠命中，那就可以避免這一次遠端調用。

然後第二個優化是report，現在的report是通過異步模式完成的，而且是批量。

理論上說，如果這兩個事情做到足夠理想，Mixer應該就不是瓶頸。對吧？

問題在于：這個Cache真的搞得定嗎？

我們給一個簡單的例子，我現在假設Mixer有三個adapter。然後它的輸入值是不同的屬性，屬性是istio的概念，了解為若幹個輸入值。假設，需要三個adapter分别檢查A/B/C。如果這三個屬性A/B/C，他們隻有100個取值範圍，每個都是從0到100，我們假設這種最簡單的場景。

如果這三個adapter分别做緩存的話，需要多少個緩存項？很容易計算吧？100個a，100個b，100個c，非常容易計算，這種情況下，其實就是a+b+c等于300嘛。了解一下：有三個輸入，每個輸入隻有一百個取值範圍，我們要把他們緩存起來。這些緩存大小，就是允許的範圍，然後加起來。隻要有300個key，就都可以緩存起來。

但是，這個方法中，緩存是做在mixer這邊，每個adapter單獨緩存。但是，在Istio中，緩存是做在Envoy這端的，因為做在mixer這端是沒有用的，還是要遠端調用過去。它做緩存的很重要的目标是要在用戶端避免遠端調用。是以，這種情況下，把緩存放到這裡（備注，圖中綠色方塊）。

大家現在想一想，現在這裡隻有一個緩存，隻有一個key/value。現在還有剛才的這個場景，A/B/C各自的取值範圍都是一百。但是現在緩存放在這邊的話，實際上的這個key要考慮三個值了，A/B/C的組合。這種情況下，它的最大緩存個數是多少？

（備注：現場回答，a 乘 b 乘 c）

a * b * c？還能 a + b + c嗎？做不到了，對不對？現在是 a * b * c，從300變成這麼大的數了。為什麼？因為緩存是在這個地方做的，根本沒有辦法像這樣分開做，是以這裡就變成了一個笛卡爾乘積。

這個笛卡爾乘積有一個很大的麻煩，也就是說，如果adapter檢查的某個屬性，它的取值範圍比較大，比如說要檢查用戶端的IP位址？你想想，這個IP位址有多少個取值範圍？數以幾十萬幾百萬計，對吧？這種情況，哪怕在前面再乘以特别小的值，哪怕隻是十，二十，如果是加20根本沒所謂的，加200，加2000都沒所謂的，那乘個200，乘個2000試一下？瞬間就被幹掉。IP位址可能隻是百萬級别，再在前面乘個100，乘個1000，瞬間就瘋掉了。這個key值基本上已經是大到不能接受：要麼就全放記憶體，記憶體爆掉；要不然限制緩存大小，就放1萬個，緩存的命中率會非常低，整個緩存相當于失效了。

這個細節，因為時間原因，不在這裡詳細講了。

這裡講第二點，我們的檢討：隔離怎麼做？

Mixer有一個基本的設計目标，就是希望提供一個統一的抽象（就是這個adapter的概念），用它來隔離基礎設施後端和Istio的其他部分。但是在這個點上我們的反思是：我們認可這樣一個隔離。大家了解基礎設施後端的概念吧？舉個例子，日志處理如prometheus，各種後端監控系統。這些系統和應用之間，我們認為這種情況下的确應該做隔離，沒必要每個應用都去和基礎設施後端産生直接的聯系。這個觀點是我們是贊許的。

但是我們現在的意見是，我們把這條線(備注：連接配接應用和基礎設施後端的标記有紅叉的線)從應用裡面拿下來之後，我們把它下沉。下沉到Sidecar，夠不夠？Istio的做法是，它覺得這個地方應該再往前走一步，到Mixer裡面。由Mixer去完成和基礎設施後端的連接配接，走這根線（備注：圖中連接配接Mixer和基礎設施後端的線）。但是多了這樣一個隔離之後的代價，就是在中間的這根紅線上，會多一次遠端調用。

現在隻有兩個選擇：和基礎設施怎麼連？這條線（備注：最左邊的）大家都認為沒必要，這兩條線（備注：中間和右邊的線）之間選，兩條線的差異，就是要付出一次遠端調用的代價。

繼續檢討：什麼是基礎設施後端？

這裡我們做一個清單，整個Istio現有的adapter，大家可以看到，大概是這些。前面這兩個部分是實作check和quota的adapter，後面這些adapter是實作report功能。

在這裡，我們的檢討是：這些功能，比如說黑白名單，比如說基于記憶體的quota，或者基于外部redis的quota。我們認為這些功能不太應該視為後端基礎設施，因為這些功能更應該是說是體系内置的基本能力，應該直接把它們做成Mesh的内置産品，或者說可以做标準化，然後和外部系統內建。這些我認為應該是Mesh的最基礎的功能，比如說我們 SOFA Mesh可以提供基于Redis的quota方案，直接就把這個功能給出來了。我不認為應該再去跟外界的一個所謂的基礎設施後端發生聯系。

但是下面這些我們是覺得OK的。這些adapter大家有概念吧，prometheus大家應該都接觸過的。剩下的這些在國内可能用的不多，是各種日志和metric相關的功能。把這些視為基礎設施後端，我們是非常了解的。包括我們内部，我們螞蟻也有很多這樣的系統，相信各位自家的監控方案也是不一樣的。

這些視為基礎設施，和系統隔離開，我們認為這是非常有必要，可以了解，可以接受。

這是我們在這一點（備注：何為基礎設施後端）上和istio的差異。

因為時間原因，我們就不再深入去講，這裡我給了一些我部落格上的文章。前段時間，我們在做技術選型，在做前面整個架構設計時，在這一點上有些讨論。以及我們最重要的決策：為什麼要把Mixer合并進去。細節都在這幾篇文章裡面，大家如果有興趣，可以去詳細了解。

備注連結位址（請複制網址到浏覽器打開）：

• Service Mesh架構反思：資料平面和控制平面的界線該如何劃定？

https://skyao.io/post/201804-servicemesh-architecture-introspection/

• Mixer Cache: Istio的阿克琉斯之踵

https://skyao.io/post/201804-istio-achilles-heel/

• Istio Mixer Cache工作原理與源碼分析(1)－基本概念

https://skyao.io/post/201804-istio-mixer-cache-concepts/

• Istio Mixer Cache工作原理與源碼分析(2)－工作原理

https://skyao.io/post/201806-istio-mixer-cache-principle/

• Istio Mixer Cache工作原理與源碼分析(3)－主流程

https://skyao.io/post/201806-istio-mixer-cache-main/

• Istio Mixer Cache工作原理與源碼分析(4)－簽名

https://skyao.io/post/201806-istio-mixer-cache-signature/

我們還有一部分現在沒有合并進來的adapter和mixer，report的這部分。但是這塊不是說完全沒有問題，我們現在有一個擔心，report這塊可能會存在一個叫做網絡集中的問題。比如說，大家會注意到，應用和Sidecar是一對一部署的，有一萬個應用，就有一萬個Sidecar。基礎設施後端也是多機部署的。

而現在的方式，流量會先打到Mixer來，Mixer也是高可用的，也是會部署多台。但是這個數量肯定不是一萬這個級别，跟這個肯定會有很大的差異。這樣流量會先集中，通道會突然間收縮一下。總的流量沒變，但是通道的口徑要小很多。

對網絡吞吐量也會有影響。比如最簡單的，如果應用直連，走交換機直接就過去了。

如果是Sidecar模式，是在這個位置上（備注：應用和sidecar之間的綠色連線）加一個遠端調用，但是應用和Sidecar之間走的是localhost，localhost根本就不走網卡，直接環回位址就走了。對性能不會有什麼影響，對網絡流量的影響就為零了。是以這兩個方案相比，吞吐量不會有變化。

但是，如果在Sidecar和Backend之間再加一個Mixer，這意味着要走兩次網絡，這樣的話會有一個流量翻倍的問題。

是以這個地方可能會帶來一些問題，但暫時我們現在還沒做決策，我們現在還不是很确定這個問題會不會導緻質的影響。是以我們現在暫時還是把它放在這裡，就是說我們後面會做驗證，如果在我們的網絡方案下，這個方式有問題的話，我們可能再合進去。但是如果沒問題的話，我們認為分開之後架構确實會更理想一些，是以我們現在暫時先不合并。

給大家一些參考，目前Conduit最新版本已經把report的功能合并進來，然後check的功能，會在後續的計劃中合并。我們在國内做一些技術交流，華為新浪微網誌他們現在通通都是選擇在Sidecar裡面實作功能，不走mixer。

這是我們稱之為夢幻級别的服務注冊和治理中心，我們對他的要求是比較多的：

• 我們需要他支援跨叢集，比如說我們現在有多個注冊中心，多個注冊中心之間可以互相同步資訊，然後可以做跨注冊中心的調用
• 還有支援異構，注冊中心可能是不一樣的東西。能了解吧，有些是Service Mesh的注冊中心，比如Istio的，有些是Spring Cloud的注冊中心，比如Consul。
• 然後終極形态，我們希望在兩種場景都可以支援。

右邊的這個圖，是我們構想中的比較理想化的注冊中心的架構，我們會有各種adapter實作，會有一個抽象的模型，把他們抽象起來，然後有一些接口。後來，在我們實作的時候發現，Istio的路線跟我們有點像，Istio本身也是做了跨平台的Adapter，也做了一層抽象，然後它也提出了一些API。是以我們最終的決策是：往Pilot靠。

我們以Istio的Pilot子產品為基礎去做擴充和增強：

• 增加 SOFA Registry的Adapter，SOFA Registry是我們内部的服務注冊中心，提供超大規模的服務注冊和服務發現的解決方案。所謂超大規模，大家能了解吧？服務數以萬計。
• 再加一個資料同步的子產品，來實作多個服務注冊中心之間的資料交換。
• 然後第三點就是希望加一個Open Service Registry API，增加服務注冊，因為現在Istio的方案隻有服務發現，它的服務注冊是走k8s的，用的是k8s的自動服務注冊。如果想脫離k8s環境，就要提供服務注冊的方案。在服務發現和服務模型已經标準化的情況下，我們希望服務注冊的API也能标準化。

這裡還有一個比較特殊的産品，因為時間限制，給大家簡單了解一下。

我們計劃的Edge Sidecar這個産品，它是東西向服務間通訊的一個特殊橋梁。所謂東西向，大家能了解吧？東西向指服務間通訊，也就是A服務調用B服務。對應的還有南北向，南北向通常是指從外部網絡進來調用服務，如走API Gateway調用服務。在東西向通訊中，我們有時會需要一個比較特殊的途徑，比如說在這個圖中，我們有兩個叢集，兩個叢集各有各自的服務注冊中心。我們通過增強Pilot的方式打通兩個注冊中心，可以知道對方有什麼服務。

當A服務發出一個請求去調用B服務的時候，由于兩個叢集是隔離的，網絡無法相通，肯定直接調用不到的。這時local sidecar會發現，服務B不在本叢集，而在右邊這個叢集裡，Local Sidecar就會将請求轉發給Edge Sidecar，然後由Edge Sidecar接力完成後續的工作。

這個子產品的功能會比較特殊一點，因為時間限制，在今天的過程當中，Pilot和Edge Sidecar就不再詳細展開。

下個月在北京的meetup上，我們這邊負責這一塊工作的專家，俊雄同學，會給大家詳細展開。

三、開源政策

SOFA Mesh的開源政策，可能會和大家之前接觸到的一些開源産品，有質的差異，非常的不一樣。

備注：這塊就不整理了，直接看圖中文字。

這是整個大的願景。

SOFA Mesh的開源态度，其實我寫左邊這些的時候是有很大壓力的。用官方話語說，不針對任何人和任何項目，我們不影射任何人。

但是，大家如果經常用各種開源産品的話，會發現一些問題。比如說，開源的時機。大家接觸的開源産品，尤其是國内的，不管是多大的公司，通常都是産品完成之後，甚至是使用好多年。好處是相對穩，缺點是什麼？（備注：現場回答，老）對，技術可能已經很老了，十年前的！還有可能是它都已經放棄了，開源出來時自己不再使用。或者說是一個很新的産品，真的很新，他自己不用，說就是做出來給你用的。（備注：現場哄笑）自己不用的産品給你用，你的第一反應是什麼？小白鼠是嗎？你願意做小白鼠嗎？你敢把公司的這個産品放上面嗎？

SOFA Mesh這次比較特殊，非常非常特殊。我們這個産品，會在非常早的時間點上開源給大家。我甚至可以跟大家說，其實在這個點上，我們更重要的是擺明态度：我們要開源，我們要把這個産品開源給大家，甚至早到我們自己都不認為這是一個完整的産品。為什麼？

有幾個事情，這幾點大家認可吧？業界最新的技術，Mesh是最新技術大家都已經達成共識了吧？業界最好的架構，當然這個我們還在努力中，盡量做好。然後我們會給大家一個承諾，大家不用擔心做小白鼠，你能拿到的産品，我們已經趟過一遍了。

開源動機，這個地方我們也不說大話，就是我們希望能吸引整個社群，謀求這樣一個合作，走開源共建的方式。這是為什麼我們會選擇在現在這個時間點上開源出來。

整個産品的維護，什麼樣的産品會讓你有信心，不用擔心中間斷掉？最重要的一點是我們自己在用。想想，如果支付寶在用，你擔心這個項目死掉嗎？對不對？如果這個産品本身是螞蟻金服這樣級别的公司，在它的線上将會使用的産品，而且是同樣一個核心的版本。相信在這種情況下，大家就放心了吧？

SOFA Mesh的合作模式，我稱之為"多層次全方位開放"。

中間這幅圖，最底下的是基礎類庫，實作各種功能。我們希望有這樣一套基礎類庫，類比Netflix的OSS套件。因為Golang的類庫做的不是很好，沒有Java沉澱的那麼好。目标是希望在這個産品做完之後，能給整個社群沉澱出一套Golang的微服務基礎類庫。最重要的一點，是希望最好能大家合力，在這個點上做出一套成熟穩定性能足夠好的産品。這是在類庫層面。

在類庫之上，功能子產品層面，比如說Golang版本的Sidecar，我們希望它能替換Envoy的功能。在原來使用Envoy的情況下可以使用這個Sidecar來替代。展現在什麼層次？就是說，如果想用Envoy，也很喜歡它，但是可能又受限于C++語言棧，更希望是Golang語言棧的時候，可以選擇我們這一套。或者如果我們抱有同樣的想法，比如想把Mixer合進來，可以在Sidecar這個層面上來重用我們的産品，跟我們做合作。或者我們剛才提到的這個産品，增強版本的Pilot，大家有印象吧？我們會實作一個非常強大的，跨各種叢集，各種異構的服務注冊機制。然後是Edge Sidecar，在兩個不同的區域之間，比如兩個不同的機房，IP位址不通的情況下，幫你打通服務間調用。這些功能子產品，會以單獨的産品和項目出現，你可以在某一個産品上跟我們合作。

第三點就是完整的産品，如果你需要一個完整的Service Mesh的産品，把這些所有的功能都包括進來，沒問題，SOFA Mesh可以拿來用。

有些同學可能會需要更完整的解決方案，我們的金融雲會提供 SOFA Mesh的支援，這是我們的目标。你可以将你的系統，架構在金融雲之上。

今天的幾位講師來自不同的公司，我們非常歡迎業界參與。如果大家有意在Service Mesh領域做一些事情，大家可以互相之間做技術的溝通，技術的交流，在社群合作上做一些事情。

有些同學說，我隻是用一下，好像沒法做什麼貢獻。其實，"用"是一個很重要的合作，你能夠用，你就會遇到問題，有你的訴求，遇到什麼樣的bug，有什麼樣需求沒有滿足。這些對我們來說，是非常重要的輸入。在這一點上，歡迎和我們保持合作。

SOFA Mesh的開源宣言，寫的比較狗血。但是在這一點上，我覺得這一次SOFA Mesh在開源上還是做的比較有誠意。

首先我們認可這個大方向，我們看好Service Mesh的前景。展現在什麼上呢？我們現在規劃，未來整個螞蟻金服内部的大部分應用都會逐漸的往Service Mesh上落。這個内部已經達成一緻了，會往這個方向走。

第二是說，"勇敢探索"，"耐心填坑"，有在1.0版本之前用過大型開源産品的同學，對這兩個詞都應該有深刻體驗，對吧？包括前兩年用0.*版本和1.1/1.2版本的k8s的同學。任何一個新的技術，一個大的方案出來，前期的時候，這些事情是一定會遇到的。但是我們覺得還是要去趟這個事情。

我們要繼續推進這樣一個技術進步，包括Service Mesh技術社群的推廣。大家如果有注意的話說，Service Mesh技術社群已經重新啟動了，我們在跟很多的公司，包括甚至我們一些競争對手合作。從技術進步的角度說，我們歡迎大家在一個公平的基礎上做技術交流。

然後我們是願意做分享的，整個産品，我們接下來所有能開源的東西都會開源出來。除了一些内部定制化的東西，内部沒有開源的産品的內建。基本上，你們能看到的東西，也就是我們内部用的東西。

我們尋求和大家的合作，包括剛才講過的各個層面的合作，哪怕是簡單的使用，發現問題給我們送出一些bug，也是非常好的合作契機。

這裡我喊一個口号，這個口号有點大，"集結中國力量，共建開源精品"。這裡面有個詞，比較大一點，我也斟酌了一下，中國這兩個字敢不敢用。最後我覺得還是用吧，至少到目前為止，Service Mesh這個技術領域，在全世界目前都還沒有成熟的場景落地的情況下，我們目前在這方面的探索，已經是走在最前面的了。

在這一點上，我們是希望能聯合國内在這個領域做探索的同學，我們一起來做這個事情。我們開源的一個重要目的，是說不管大家在商業上有什麼樣的競争，至少在技術領域上，包括剛才說的可以在類庫層面，産品層面，或者社群合作方面，開展合作。我們希望能夠盡可能的聯合國内的合作夥伴，包括競争對手一起來營造整個技術氛圍，把整個Service Mesh技術體系的基本水準提升上來。

這一點應該是大家比較關注的，什麼時候開源? 我們隻能告訴大家說，on the way，正在路上。

本來這一頁的寫法應該是貼個位址給大家的，但是因為進度的原因還沒有實作，有可能會在一到兩個星期之後，在7月份的時候開源給大家。

需要澄清的一點，大家的期望值不要太高，因為我們開源出來的第一個版本，主要是釋放姿态，把我們的開源共建的姿态釋放出來。我們的第一個版本，肯定不是一個完善的版本。（備注：現場有同學問，有在用嗎？）内部有用一部分，Sidecar内部已經在用了，但是第二部分的内容，比如說XDS API的內建，我們現在正在做。我們不希望等把産品做完善了，比如說兩年之後非常成熟的情況下再來開源。我們希望盡可能早的開源。

（備注：現場提問，7月份的版本，不一定是生産環境可用？）對，是的。有一部分功能是生産可用的，有一部分功能不是，因為我們是疊代上去的。

四、官方社群網站

這是我們剛剛開通的Service Mesh技術社群的官方網站，歡迎通路。（http://www.servicemesher.com 請将網址複制至浏覽器中打開即可檢視）

五、線下活動

螞蟻金服将在7月6日與ArchSummit深圳合作舉辦雲原生架構探讨晚場技術交流活動，邀請微服務、中間件、應用開發架構、分布式事務解決方案等技術專家，共同讨論雲原生、容器、微服務、海量資料通路等話題，Service Mesh、K8S、海量資料一緻等，六大熱點技術邀你來聊！

報名連結：

https://www.bagevent.com/event/1590965?bag_track=my

六、交流社群

我們也為對 SOFA 中間件感興趣的同學準備了微信的交流群，歡迎感興趣的同學添加加群小助手（微信号：Ant-Techfin01）加入我們 SOFA 交流群讨論和咨詢相關問題哦。

歡迎通路 http://github.com/alipay 了解更多 SOFA 開源資訊，共同打造SOFAStack 。更多最新分布式架構幹貨，請關注公衆号《金融級分布式架構》了解一下~