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

時間 2019-12-06

原文原文鏈接

小螞蟻說：nginx

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

講師PPT下載地址：git

https://github.com/servicemes...github

視頻直播回放：golang

http://www.itdks.com/eventlis...redis

螞蟻金服Service Mesh 佈道師敖小劍編程

前言

今天給你們帶來的內容叫作Service Mesh探索之路，可是在前面加了一個定語：大規模微服務架構下。之因此加上這個詞，是由於咱們這個體系是在螞蟻金服這樣一個大的架構下進行的，螞蟻金服的體量你們能夠想象，因此這個探索會帶有一個很是隆重的色彩：對性能/規模/高可用等方面的思考。後端

今年6月初，在深圳的GIAC大會，咱們同事披露了這個正在開發中的 Service Mesh產品，咱們如今暫時命名爲 SOFA Mesh。咱們目前的產品都在 SOFA品牌下，好比 SOFA RPC，SOFA Boot等。今天咱們詳細介紹 SOFA Mesh這個單獨產品，上次大會只是簡單披露，也就是給你們介紹說咱們有這樣一個產品，而我今天的內容是把這個產品詳細展開。瀏覽器

主要是三個內容：一是 SOFA Mesh的技術選型，二是它的架構設計，以及在最後跟你們聊一下，螞蟻金服在 SOFA Mesh上的開源策略。緩存

1、技術選型

先上來一堆要求，剛纔咱們提到過的，由於是大規模，而螞蟻金服的體量，你們能夠想象到的。實際上在性能，穩定性上，咱們的衡量標準，咱們考慮的基石，都是以螞蟻金服這樣的一個規模來考慮的。

在這樣一個規模下，咱們會涉及到一些跟其餘公司不太同樣的地方，好比說：咱們在性能的考量上會比較重一些。由於若是性能不高的話，可能無法支撐咱們這樣一個規模。在考慮性能的時候，就有另一層考量：架構和性能之間的這個權衡和取捨是要很是謹慎的。性能要求不過高的狀況下，架構可能的選擇，和須要比較高性能的狀況下，可能會有徹底不同的取捨。穩定性就沒必要說了。

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

主站是指咱們螞蟻金服內部，好比你們用的最多的支付寶。

金融雲，可能有一部分和咱們有聯繫的同窗會有所瞭解，這個是咱們推出的針對金融行業的雲。

而後還有咱們的外部客戶

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

部署環境也會有多種，剛纔咱們調查到，有部分同窗相對比較前沿一些，如今就已經上k8s了。有部分同窗仍是停留在之前的虛擬機以及物理機這種狀態，也有一部分本身上了容器，還有部分同窗可能會使用不一樣的公有云和私有云。這幾種不一樣的環境，咱們都是須要知足的。

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

咱們作技術選型的時候，有兩大方向：

一個選擇是在開源產品上作

咱們先看右邊的路線，起點是找一個開源產品，fork出來，作加強/擴展/定製，和內部集成。由於開源產品還在繼續往前走，因此咱們會持續作版本更新，也能夠從社區拿到最新版本。至關因而從開源社區作獲取，而後接下來作反饋，讓咱們的一些產品，咱們作的東西反饋回去。

這條路線比較大的好處是從一開始就能夠獲得社區的支持，社區往前走的時候也跟着往前走。若是作的比較好，願意讓本身的產品反哺社區，那麼社區也能夠從中受益。

固然這裏面有一個小問題，就是說可能咱們本身這個產品路線和開源產品路線可能會有一些分歧，可能咱們領先一步，也可能他們領先一步，或者一個事情可能有兩個作法。這種狀況下，如何讓社區的接受咱們的改動，會變成這條路線上比較頭疼的一個問題。

這是兩條路線上的第一條，選擇以開源產品爲起點。

另一種思路全新打造

或者，若是手上已經有一套類庫或者框架，能夠在這個基礎上作包裝。

這條路線有一個好處，可控性比較強。由於整個體系是全新打造或者在原有體系上演進而來的，整套體系基本上都是本身的開發團隊徹底可控的。

這條路線會遇到一個問題，由於長期上看咱們也是但願開源的，而開源就意味着不能將本身內部太多的定製化的東西直接作進去，因此在架構上須要考慮可擴展性，能夠定製化。由於開源出去的應該是一個標準產品，這樣的產品才能夠獲得社區和客戶的承認。客戶但願看到一個乾淨的東西，也須要作擴展，整個體系在設計上會有所不一樣。

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

第一個目標是內部落地

前面提到的，咱們須要在螞蟻金服主站這樣的一個巨大規模的場景下落地，這是螞蟻金服自身的需求。

第二個目標是技術輸出

由於螞蟻金服在公司策略上有科技輸出的內容，不只僅咱們本身用，咱們還須要給出去。

如今咱們來看這個問題：目標在這裏，而後有左右兩條路線，咱們該怎麼選擇？在作的技術選型的時候，這是一個很是大的分歧點，究竟是從左邊走，仍是從右邊走？

在公佈結果以前，咱們先來看一下有什麼可選方案。

這是開源方案的選擇，第一代的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的大框架下去作這個事情，可是會作一些調整。

2、架構設計

而後咱們來詳細介紹一下在這個技術選型上咱們怎麼去作實現。

首先是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的三大功能：

一、check。也叫precondition，前置條件檢查，好比說黑白名單，權限。

二、quota。好比說訪問次數之類。

三、report。好比說日誌，度量等。

三大功能裏面，注意到，前兩個功能是同步阻塞的，就是必定要檢查經過，或者是說quota驗證OK，才能往下走。若是結果沒回來只能等，由於這是業務邏輯，必需要等。而Report是能夠經過異步和批量的方式來作的。

在這裏，咱們如今的決策是：咱們會將其中的兩個部分(check和quota)合併進來，原有report部分咱們會繼續保留在mixer裏面。

可能你們會問：爲何咱們要選擇用這個方案，而不是遵循Istio的標準作法？咱們以前聊到，咱們會盡可能去和Istio作兼容，跟隨Istio的設計理念和產品方向，可是咱們在它的架構上作了一個重大的調整。爲何？

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

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

第一次在請求轉發以前要作一次check，這個check裏面包含了quota。Check完成經過，才能把請求轉發過去。
請求轉發完成以後，再調用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-...

Mixer Cache: Istio的阿克琉斯之踵
https://skyao.io/post/201804-...

Istio Mixer Cache工做原理與源碼分析(1)－基本概念
https://skyao.io/post/201804-...

Istio Mixer Cache工做原理與源碼分析(2)－工做原理
https://skyao.io/post/201806-...

Istio Mixer Cache工做原理與源碼分析(3)－主流程
https://skyao.io/post/201806-...

Istio Mixer Cache工做原理與源碼分析(4)－簽名
https://skyao.io/post/201806-...

咱們還有一部分如今沒有合併進來的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上，咱們這邊負責這一塊工做的專家，俊雄同窗，會給你們詳細展開。

3、開源策略

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月份的版本，不必定是生產環境可用？）對，是的。有一部分功能是生產可用的，有一部分功能不是，由於咱們是迭代上去的。