Hello,各位CubeCon的聽眾,大家好,歡迎各位來收聽我的訊息,今天我要跟大家分享的議題是EdgeMesh,ServiceMesh在邊緣計算場景下的擴展與延伸,我們都知道服務網格大了非常豐富的流量治理能力,比如負載均衡、服務發現、容斷與限流、分布式調用鏈、恢循發布等等。這些特性在我們的系統中都發揮了非常關鍵的作用,然後我們要研究的就是如何將ServiceMesh的能力延伸到邊緣計算的場景,但是今天我要講的那種可能跟ServiceMesh本身並不那麼相關,可能更多的是一個網絡的一些研究。為什麼呢?因為在階段的EdgeMesh它可能要去更多的處理邊緣的網絡問題,所以這個階段EdgeMesh它可能更像是一個Network的一個Mesh,而非是一個ServiceMesh,ok,先做一個簡單的自我介紹。我叫王潔章,然後是來自華為的一名工程師,同時也是CubaEdge項目的Member,然後也是CubaEdge,此項目EdgeMesh的猛燈。我自己也是一位邊緣生技術,邊緣計算技術的一個愛好者。我今天主要分為四個部分來講解我的內容,首先第一個就是邊緣計算場景下面一些網絡挑戰。為什麼網絡問題要單獨領出來講,因為在邊緣計算場景下,它的網絡可能並不像雲數據中心那樣子,它可能會有一些自己的特點或問題,所以必須要先把它講清楚,才能做進一步的一些研究實踐。第二部分就是對EdgeMesh本身的一些架構核心能力進行一個概述。第三部分就是EdgeMesh的一個性能測試,因為EdgeMesh它算是一個數據命的一個組件,所以它負責了很大部分的一些流量的轉方和代理,所以性能必須跟大家描述清楚。最後一部分就是關於EdgeMesh的一個後續的一個roadmap。在講邊緣網絡之前,先了解一下雲上的或者說雲雲生的一個容器網絡吧。在Docker出現之後,Docker也有自己的四種容器網絡模型,比如host的模式,container模式,nam模式以及bridge模式。但是呢,這個時候的Docker它無法去解決容器之間的跨機通信的問題。但是隨著Docker的發展,它也對這些問題去做了一些解決吧。然後它提出了一個CNM,container network module,這麼一個容器網絡模型,然後呢,也是將LipNetwork,然後作為CNM的一個標準實驗之一,貢獻給社區。第二階段就是隨著Cubanitis的出現,然後Cubanitis主推了一個CNi的這麼一個容器網絡接口,然後去做這個容器網絡的一個打通。Cubanitis它本身可能並不去並不負責網絡相關的東西,而是所有能夠接受CNi的這些網絡插電,去負責完成這麼一個網絡的一個打通的問題。它可能就是所有進出炮的一個流量,然後進入到這個容器網絡,然後通過Overlay的方式或Underlay,然後將一個流量送達到最短的一個炮的裡面,然後這個時候它每個炮的都會擁有集群唯一一個IP地址。CNi的一些比較有名的一些項目吧,然後比如說Flanol、Alico、Slim都是比較優秀的一些CNi插件,三階段就是隨著服務網格的發展,它跟CNi進行的配合,然後進入了一個第三代的一個容器網絡模式,就是這些CNi這些服務網格的插件,它都會在每個炮的其中的時候往炮的去注入一個set card的一個待遇,然後來提供一個四成或七成的一個流量智力的功能,然後一些關於服務網格的明星項目,比如Esteal、Binker D、Console都是大家所熟知的。接下來講一下Cubanitis的一個服務發現,Cubanitis的服務發現其實是跟容器網絡是互相依賴的。首先用戶都會去通過Ployment,然後來創建一組運動的後端實力對它進行管理,但是其實炮的生命週期是非常短暫的,可能會隨著炮的一些更新升級,或者它的遷移等等,它的炮的IP都會發生變化,然後我們把這個稱之為炮的IP的漂移,然後為了解決這個問題,上游社區就是Cubanitis社區提出了service的概念,然後每個service都會去對應到一組後端的應用實力上,然後通過提供一個很令不變的class IP,然後來解決炮的IP的問題,然後同時也提供了Cuproxy組件,然後來基於控制面提供的一些信息去維護class IP到後端炮的IP的轉換規則,然後當一個client需要去訪問這個服務的時候,它一般來說就只需要去訪問這個不變的class IP就可以,然後這個流量會經過本機的一個網絡站,然後最後被替換成真實的股等一個後端的炮的IP,然後再通過冷氣網絡,然後請求發送過去。雲上的或者說數據中心的一個網絡,其實是比較好理解的,但是呢在邊緣場景下,它可能就會遇到問題,然後我們先把角度放大一點,我們先看一下邊緣場景中,它都有哪些關鍵的一些挑戰,比如邊緣計算的話,它細分的領域會比較多,互相弱性比較差,然後邊緣的通信網絡指向比較低,血比較高,而且邊緣節點經常位於一些私有網絡裡面,雲上跟邊緣的應用,它比較難實現一個雙向的通信,而且還有很重要一點就是,邊緣的資源一般來說是有限的,所以我們要去思考如何去授生我們的一些組件,然後讓它比較更好的去運行在邊緣節點上,第四個就是在邊緣節點離線的時候,我們也需要業務用的自製能力,以及本地的故障恢復能力,第五點就是邊緣節點它是高度分散,它是非常離散的,如何去高效果管理,向低運員成本,也是非常關鍵的一點,最後就是邊緣節點的量是非常多,它一般都是一些易購的,然後如果對這些易購資源進行一個標準的話,管理和另外的配置,也是我們關注的一點,但其實這些關鍵挑戰都由名人生邊緣超過邊緣階段平台QBH都已經對這些問題做了一個非常好的實現,然後也解決了基本上所有的這些問題,但是除了剛剛說的那些邊緣階段存在上光線問題以外,它其實還有一些其他的問題,我這裡舉個簡單的例子,比如說我們在邊緣有一個視頻流的應用,然後它要去跟雲上的一個邊緣應用進行一個交互,首先它就是因為你上跟邊緣它的網絡,它是沒辦法直接互相連通的,就是說它QBH沒辦法從邊緣去對雲上這個訪問,但是其實你給雲上的那些邊緣應用去配置一個公網IP,其實也是可以解決這個問題,但是這就會引入另外一個問題,就是你如果雲上的每一個應用都去配置這麼一個公網IP,那麼其實你的IP是無法收斂的,這是第一個問題,第二個問題就是,假如你雲上這個應用想要去訪問邊緣這個應用呢,其實它做不到,因為我們的邊緣上的應用一般都處於一些絲網裡面,它一般不會有一個公網IP,所以這就無法做到雙向通信,所以這就是一個第一個問題,邊緣的網絡是割裂的,微服之間它是無法跨自往之間通信,第二個問題其實是由第一個問題引入來,因為我們沒辦法做到微服之間無法直接通信,所以說我們就無法去訪問到對方,那麼其實邊緣測,相當於就是邊緣測是缺少一個無發現的能力,第三個問題的話就是之前也講過,就是邊緣的網絡,它可能左邊這個節點處於一個局域網內,右邊這兩個節點它又處於局域網內,它們兩個不同的局域網,它們的網絡的互通,或者這些節點它本身又處於多重的NAT後面,它們的網絡tube節落是非常複雜的,所以邊緣環境下的一個主網配置管理是非常複雜的,如果我們要去讓工程師主動地去管理這些事情,其實對於它們來說是很酷的,於是EdgeMesh就出現了,就專門為了去解決這些問題,然後講一下邊緣計算平台QBH,QBH想必大家也都對它有一定的了解,QBH它是一個QBANANIS在邊緣場景下的一個延伸,它記憶QBANANIS,它的目標是將QBANANIS對容器編排的這種能力給它延伸到邊緣上,QBH它主要是分為兩個組件,圓上的一個claw code,然後一個邊緣稍微通道,邊緣節點上的一個Edge code,然後同時還有一個device模塊用於去管理海量的邊緣設備,關於QBH的架構我們就不想去展開,然後網上也是有比較多的資料,大家如果感興趣的話可以去查看一下,然後我們主要是看一下EdgeMeshQBH的架構中鎖住了位置,最底下是一條EdgeMesh它打通了所有之間砲的之間的一個通信,網絡通信,你無論這個砲的是處於同一個主機或者不同的主機,或者說這些砲的,處於不同主機的不同的那個語網內,其實EdgeMesh都可以讓他們,讓所有砲的之間可以進行通信,但是其實這個地方應該還有一條數的EdgeMesh,什麼意思呢?就是EdgeMesh它還能完成雲上應用跟邊緣,或者說雲上砲的跟邊緣砲的一個通信,這也主要是簡單的描述一下EdgeMesh的設定原則,或者說EdgeMesh的一個核心思想,我先輕量一下,因為我們都知道邊緣它其實是資源是非常有限的,所以我們要去做一個比較輕量的,輕的一個待遇組件,而且我只需要用這個組件就可以完成,像扣電S、扣Proxy、CMI插電等這些雲上組件合力,然後提供的一個能力,由我這個邊緣側的組件就可以完成。第二個比較重要的就是一個雲原聲的體驗,就是你雲上或者說你cubinatis,你是如何使用service的,就如何創建service,然後怎麼去用。其實對於EdgeMesh來說,它也是一樣,你只需要去創建一個service,然後你去訪問它的class IP,或者說你去直接訪問它的域名,它就可以進行一個服務件的互通。第三點是最重要的,也是目前EdgeMesh來說一個最關鍵的能力,就是一個跨自往通信。它屏蔽了一個複雜的邊緣網絡情況,然後提供了融洩之間跨自往的邊道雲、雲道邊或者跨自往的邊跟邊之間的一個通信。第四點就是一個高可抗性。EdgeMesh它通過了打動能力來建立一個點對的人職聯,它的流量轉發效率是極高的。而且在不支持打動的情況下,我們也可以通過蹤跡的方式來流量,然後來保障屋之間的一個動態通信。最後一個就是EdgeMesh,它本身是一個分層的一個架構模式,它採用分層的大碼結構,然後各個模塊能夠於原生的組件,比如Cooproxy、Cni做一個集成,而且也支持它的動態關閉。那麼什麼是EdgeMesh呢?就是目前這個階段的定義是,首先EdgeMesh它是Cube Edge一部,然後作為Cube Edge集群的一個數據鏈的部件,然後為應用程序提供了簡單的合作發現與流量代理的功能,而屏蔽的邊緣層就像砸了網絡結構。它有什麼優勢呢?首先EdgeMesh它主要滿足了邊緣場景上的一些新需求,比如說資源有限啊,邊緣網絡的不穩定性啊,然後它的邊緣的網絡結構砸啊等等,然後實現了高可靠極致的輕量化。那麼什麼是高可用呢?首先EdgeMesh它是利用了P2P的一個打動技術,然後我們來打動了邊緣之間的網絡,然後在跨局網通信的時候呢,當打動成功的時候呢,EdgeMesh是什麼?我後面會做一個詳細的介紹。EdgeMesh這邊它會建立一個直列的通道,如果打動不成功的話,就會通過Server,Server後面的軌跡,Server做一個徵信的一個轉發。可靠性的,首先原數據,比如Service啊,Andpoint啊,Port啊,這些KBS一些原數據,它都是通過QB edge的邊緣通道,做一個可靠性下滑。第二點就是EdgeMesh內部,它實現了一個輕量級的DNS服務器,你所有的譽明型球,它都可以在那個節點內屁緩,它的譽明型球,不需要在道路上去進行一個處理。輕量化,就是每個節點我只需要部署一個agent,然後我可以大了去,節省一個邊緣的資源。大量什麼樣的用戶價值呢?首先目前來說,這關鍵的一點就是,使用戶的集群上的應用具備了跨越不同局域往邊到邊,邊到雲,雲到邊的這麼一個,應用的跨自往互防的一個能力。然後第二個,就是相對於你,要在邊緣去部署,Troxy去部署,CNN插件去部署,NodeLogDNS這一套組件來說呢,用戶只需要在節點,部署一個集群量的一個agent,就可以完成目標,也就是實現了一個O1的部署。右邊這個表呢,是EdgeMash目前實現了一些主要的關鍵的功能,無法下流氧的一些治理,附在均衡,邊緣往關,然後跨出網通信,其實我們後面要做一個CNN的支持,簡單講一下EdgeMash的一個架構吧。剛剛說到的agent和server,就是EdgeMash agent,它是有別於setcar,它是一個節點級的一個代理,每個節點尤其僅會,尤其僅有一個EdgeMash agent,然後它也細分一些模塊,比如說proxy模塊,proxy模塊有點像coopproxy,然後它主要是負責內核的一些IP title,規則的一個page,然後去將一些應用的請求,直接到EdgeMash頂層內,去進行一個流量的一些處理和轉發。DS模塊就是EdgeMash內置的一個DS解析器,然後它負責將節點內的域名,進行一個解析,然後再返回,和class的IP給應用。DS這個模塊就是用於做流量轉發,然後Ctrl模塊用於獲取一些數據,然後Turn on agent,其實就是剛剛說到,用一個打動技術,然後來連接所有的一些,給它的一些Agent,EdgeMash server,它的功能比較簡單,但是也很非常的重要,它首先,它與每個EdgeMash agent可以先進入一個元階,然後去協助兩個Agent之間,去進行一個打動,然後在打動失敗的情況下,以後為EdgeMash agent,提供一個終極的能力,這裡再講一下EdgeMash的工作原力。先Ctrl模塊去通過EdgeCore,提供了一個ListWatch能力,來監聽一個原數據的變化,並去配置主機上的HappyTip規則,然後當一個應用去發起一個譽明請求的時候,EdgeMash agent裡面的DS模塊,會負責解析,返回一個Class IP,或者說你應用可以直接通過Class IP,然後來對對端的服務進行訪問,然後所有流量被EdgeMash agent攔截之後,進到EdgeMash agent的內部,再由EdgeMash agent的Turner模塊去進行一個轉發。這個時候,在先前他可能EdgeMash agent跟對端的EdgeMash agent可能已經建立了一個直連,那麼如果建立起直連,那麼這個流量就會直接去發送到對端的一個Agent,由對端的Agent發送到對應的應用的後端實力上。但是在打動失敗的情況下,他就會EdgeMash agent他就會先把流量轉到搜額上,讓搜額做一個中轉站,然後再把流量打到對端的一個Agent上。可能就會有些同學就會問,那什麼時候成功,什麼時候打動會失敗,或者打動成功和打動失敗,又有多大差異?那為了回答這個問題,我們就必須對NAT穿透,進行打動這個技術,有一定的瞭解。但是限於篇幅和時長,我沒辦法做過多的介紹,改信訊的同學呢,可以去上網搜索相關資料,然後我自己就直接去給出一個結論吧。首先,NAT的穿透能力,它是跟NAT人力型是搶相關的。NAT主要分為兩大類型,一種是追行,一種是對稱型,然後追行又分為完全限制追行,跟端筒限制追行。從上到下,就是從完全追行,一直到對稱型追行,穿透性是最適量的,安全性是上升的。然後呢,當有一端是對稱型的時候,當另外一端是對稱型,或者是這種關口限制追行,那麼它的打動是一定會失敗,其一個所有情況,打動是一定會成功的。這是關於一個打動成功率的一個點亮的描述。那麼可能大家就會問,那如果我打動成功,跟打動失敗,打動成功的情況下,我又會提供帶來多少的一個轉發效的一個提升。為了回答這些問題,就是我們去做了一些實驗,然後分成兩個實驗,第一個實驗就是一個鍵鏈的耗時,鍵鏈耗時就是一個A鍵的A,或者說P和A,跟另外一個對等點P和B,直接盡力連接的這麼一個市場。然後呢,這個實驗也是先設置了兩個基準組,lockerhost跟局往內。lockerhost的意思就是,我的agent A、agent B都在同一個機上,然後局往內的意思就是,我agent A在一個機器,agent B在另外一個機器,但是呢,他們這兩個機器都在同一個局往內,然後剩下四組就是一些對比組,首先第一個對比就是,跨局往有一個雙線的追行,它使用一個中期的模式。就剛才也說過,兩個都是對稱型,或者一個對稱型,一個是完全線的追行,它才會是中期,但是這也為什麼是中期呢?因為EdgeMesh它支持,你去設置它強制的使用中期模式,對,所以這也是一個比較關鍵的對比組,然後剩下的兩個就是齒聯了,因為它不是那一個雙對稱型,或者說一對稱型,因為完全線的追行,所以它這兩個,中間這兩個一定是一個職聯,然後最後一個呢,就是剛才也說過,如果是雙對稱型,那麼它打動一定是失敗的,所以這也是一個中期模式。然後我們可以看到時間經過,就是會比較,可能會比較那個,比較差也就是在雙對稱型的情況下,它打動它時常是那個,花掉將近30秒,然後還有一點值得我們注意的是,就是它在職聯模式上反而會比中期模式,它的建立它可能會往更長的一些時間,它主要的原因就是,因為它在打動的時候,兩個EdgeMesh之間,它要去交換一個網絡的信息,所以說它會以中期的方式,來消耗更多的時長。那可能這個時候就會有些同學就會問,那在中期的情況下,它居然要花30多秒去建立,那如果我要發一個,比如說我要發一個1KB的一個消息,結果你建立的時間就花了30秒,我發著1KB的消息,可能就只要幾毫秒,那這個可能就不合理,對吧,就有點糊塗,但是其實不是這樣的,因為什麼呢,因為EdgeMeshAgent建立,它只在Agent加入這個集群的時候發生,比如說你左邊的Agent在剛加入這個集群的時候,它會,它才會,主動的跟其他的Agent之間,去建立一個連接,也就是當Agent在加入這個集群後,它會立馬的去跟EdgeMeshAgent建立一個連接,它建立的時間段,它是發生在這個時候的,這個時候可能你的業務,它還沒異形下來,所以說它不會帶來影響,所以呢,這個耗時其實我們是可以,可以不用太擔心,然後呢,還有一個問題就是,所有的Agent,因為在加入集群後,都會跟其他的所有的Agent,去建立一個連接,所以最後呢,就會形成一種這種FullMesh的一個網格,這也是就EdgeMesh的一個名稱的由來,就是它所有Agent在形成以後,都會構成這麼一個FullMesh,然後但是呢,這個時候又有同學可能會有意外,就是,比如說你節點規模很大,那麼我每個節點上的一個,一個鏈接的量就很大,那會不會帶來非常高的一個資源佔用,也就是經過我們的實驗號其實並不會的,舉個例子,比如說這個時候我們集群有1000個節點,那每個節點上都會有199條鏈,但是呢,可能實際上使用的時候呢,你只會使用其中一部分,剩餘的大部分可能你都是沒用上的,然後這些空閒的鏈接,它只能極少的一個系統資源,就是說不用去擔心它一個資源消耗,第二個實驗其實就是關於一個,談述的實驗,就是為了回答,直連模式像跟中際模式像,這兩種,不是的,它的一個數據傳輸的一個效率,有一個發育性,這邊也是直接給出一個結論,這邊測量的結果,可能會有一些測量物差,但是其實在大量的測量情況下,它其實總體的趨勢就是,我下面描述了這麼回事,然後也是擷取了一段記錄值,然後我們可以直接看一下,在直連的情況下,它其實它的效率來說,要比中際模式,它是要提高大概占中際模式傳輸效率的,只有大概15%到20%多吧,所以說,P2P直連的方式,它的數據傳輸的效率是非常高的,第三個部分,就是關於EdgeMesh的一個性能測試,因為EdgeMesh它本身是一個數字面的組件,所以說,它的一個性能是一個非常重要的,也只有把這一部分性能交代清楚了,用戶可能去放心地去使用EdgeMesh,首先第一個性能測試是資源的一個消耗測試,一般資源,大多數都是測量一個內存的消耗,這個CPU的消耗,然後從這個表面我們也可以看出,在等數量等測試應用規模的情況下,單個數據面的EdgeMeshAgent的內存消耗,大約是East to Proxy的,然後CPU消耗是East to Proxy的,大概10左右,然後控制面組件EdgeMeshStorework的內存消耗,大約是East to D的4.5%,然後CPU消耗大約是East to D的0.15%,可能有些同學就會覺得這邊的數據有點誇張,但其實是有一點就是當EdgeMeshAgent在打動情,所有的EdgeMesh都在打動成功的情況下,所有EdgeMesh都通過直連進行一個數據轉發,那麼這個時候其實EdgeMeshStorework,它本身是不用去做一個中繼的工作,那麼相當於它就是一個空檢的狀態,所以這個時候,資源消耗佔用是非常低的,這也是為什麼我們會測出一個比較好的一個結果,第三個非常重要的一個點就是EdgeMesh,本身它是一個節點模式的代理,它不像East to D那樣,它是一個setter的一個代理模式,所以這個時候,它的內存內,或者說一個資源的消耗,它應該是一個節點上,一個應用的配數,比如說我一個節點上有100個應用,那麼East to proxy的一個內存消耗,這個時候它的內存代用可能就是,以記憶度,然而EdgeMeshAgent是每個節點就有一個,這種節點器的代理,所以對於EdgeMeshAgent來說,它的內存可能並不會增加多少,是一個比較關鍵的,最後一個性能測試也是,這種流量轉發,對流量轉發組件來說,非常重要的測試就是,端道端應用的端道端實驗的測試,然後我們是在一個相同環境下,去進行一個測試,其實關於EdgeMesh的一個性能測試,我們是做了非常多的工作,但是限於一個PBT的一個篇幅吧,我們不能都放上來,所以這裡就放上了一些比較關鍵性的結論,首先在我們分成了四個,四個那個吞吐量一個測試指標,分別是二十一百五百兩千五APS,APS就是Request Per Second,每秒的一個請求數,在吞吐量比較低的情況下,比如二十APS,一百APS的時候,EdgeMesh有一個轉發性能測試,由於Esteve,他們轉發的速率大概提高了有十倍左右,而且我們可以看到,從這兩個圖中,我們可以看到其實藍色的EdgeMesh,它跟紅色這個Bialmental這個基準組的意思就是,不網格它直接走了,就是里程的一個容器網絡,或者是那種Overlay,Underlay這種網絡,我們可以看到其實EdgeMesh的一個端道端實驗跟這個基準組的測試結果,基本上是持平了,或者相同的越高,意思就是說EdgeMesh並不會引入不多的一個性能的一個損耗,然而Esteve的話,在零點九九P的時候,就會去一個平穩,然後大概達到一個兩百三十多,兩百二十多的一個好秒的一個延遲,但是EdgeMesh其實也,目前來說EdgeMesh也並沒有那麼完美的,就是在比較高壓或高吞吐量的情況下,EdgeMesh的一個端道端實驗,它會達到,比如這個500ps,它會達到一個七百,然後在那個兩千五的時候,它會達到一個七百多,三千一秒,然而Esteve的話,在這種情況下,它的表現是比較好,在五百多的時候,Esteve也是能保持到兩百多,兩百五左右,然後在兩千五的時候,它是三百五左右,總起來來說還是保持在五百多下,所以這個結論就是,當警求量和吞吐壓力比較高的時候,EdgeMesh的一個端道端實驗波動,是比較明顯的,側面也反映說了,在高壓下EdgeMesh可能有些不穩定性,但是有問題不要緊,我們目前也是在左手去優化EdgeMesh在高壓情況上的一個穩定性,然後目標是給大家帶來,無論在什麼樣的壓力情況下,都能又快速的,肯定的去轉防和代理一些應用的流量,然後這些實驗我全部都是把測試框架開源到了我自己的個人倉庫下面,大家如果感興趣的話也可以去看一下,然後這個測試框架的目標就是讓任何一個人都可以實現,重新實現我的這些性能測試結果,不可能你測出來的具體素質,可能會跟我有些些偏差,但是總體趨勢,肯定也是相差無解的。OK,最後來說一下EdgeMesh的一個roadman,我們在今年6月份,是EdgeMesh從Qbadge的項目中結尾出來,然後做一個鼓勵子項目進行開源,然後在今年9月份的話,實現了一個階段,EdgeMesh最重要的一個功能,就是一個微幅的框架往邊緣,邊緣和邊緣的一個通信,然後預計在今年的年底,然後去實現一個EdgeMesh的一個operator自動換運為,然後在明年Q1的時候去實現一個EdgeMesh接龍CMI,這個地方的表述不太對,因為EdgeMesh它現在已經可以去接龍CMI常見,來,等等,我們都已經測試過了,其實這個地方的意思就是去支持一些CMI,讓EdgeMesh能夠做到在炮的內部,直接通過炮改IP去碰通另外一個最短的一個炮改IP,我們要在明年Q1要做的一個事情,然後明年Q2呢,我們是希望去做一個服務智力能力的一個功夫,然後最終達到能夠對接標準的Esteal去進行一個服務智力的一個控制,也只有做完這一步,才能EdgeMesh,才能稱之為ServiceMesh在邊緣計算場面下的一個聖和Quest,然後明年Q3的話,是打算去做一個EdgeMesh的一個浪跡群的服務通信,其實目前來說,有很多CMI其實也已經做了,或者說ServiceMesh工具,項目都已經做了這件事情,比如那個Celium,它其實已經支持有跨級群多的通信,Esteal它本身也支持跨級群的一個通信,跨級群服務通信其實還是有蠻多的一個使用場景的,所以我們是打算在明年的一個Q3去支持一個跨級群的服務通信,最後就打播小廣告吧,首先就是倉庫的話,都放在QBedge這個主項目不管,然後這是我們一個頻道,有什麼問題可以直接在上面跟我們交流,然後下面這兩個二維碼,大家如果感興趣也可以掃描它,然後可以第一個公送號,大家可以去接收一些QBedge的一些動態,還有一些推文等等,然後第二個二維碼的話,你是掃描它,然後這個小助手會把你拉到一個QBedge的群裡面,有些問題我們也可以直接在群裡面進行交流。最後普通一句就是QBedge的話,其實不是不各都希望有更多的音樂聲、邊緣介紹按後者,加入到其中,然後一起去探索邊緣介紹的方向。OK,謝謝大家。我今天的演講到此為止。謝謝。