首屆云原生編程挑戰賽正在報名中，初賽共有三個賽道，題目如下：

賽道一：實現一個分布式統計和過濾的鏈路追蹤
賽道二：實現規模化容器靜態布局和動態遷移
賽道三：服務網格控制面分治體系構建

立即報名（報名時間即日起至06/29）：https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition

本文主要針對賽道三題目做出剖析，幫助選手更高效的解題。

背景知識

“服務網格” 是近年來非常火熱的技術，其全托管的思維非常適合云原生場景。“服務網格” 核心分為控制面與數據面：數據面主要是一個名為 Sidecar 的代理組件，它通過接收控制面發送的路由與控制信息來定向轉發或處理數據。這樣一些坐落在服務網格里的應用就將整個分布式邏輯交給了底層，自己不用關心了。一旦與底層解耦，靈活性大大增加，更符合云原生的標準。

題目解析

本題的核心考查點還是如何讓服務網格的控制面支撐大規模的 Sidecar 實例。為什么會產生這個問題呢？因為在目前服務網格影響最廣的實現 Istio 架構中，控制平面 Pilot 負責整個系統的路由轉譯工作，也就是說所有服務的實例信息都需要通過 Pilot 下發給每一個 Sidecar，當然用戶可以通過 SidecarScope 來設置個別 Sidecar 對于系統服務的可見性，但這只會影響到 Sidecar 接受到的數據而已，Pilot 仍然是全量從注冊中心同步（例如 Consul，K8s 的 CoreDNS 等），如此一來隨著接入應用的增加，Pilot 不能橫向擴容，很快便會成為性能瓶頸（內存不夠用啊）。

題目提出了分治的解法，而選手們的任務就是優化分治邏輯，使整體負載均衡。為了理解題目，我們首先需要弄清楚什么是分治。所謂的分治就是將負載分成一個個獨立的子系統，然后分別處理他們，這樣就將問題化小了，比如我們常見的合并排序，就是分治的典型應用。按題目的解釋，控制面的分治是按應用維度進行劃分的，也就說坐落在服務網格中的應用將被劃分到不同的子系統中。

上圖中，就被劃分成了左右兩個子系統。應用之間存在相互依賴即服務依賴，在本題中一個應用只提供一個服務，因此應用所連接的 Pilot 需要加載的數據就是其依服務。由于分治的存在，每個 Pilot 不需要加載所有的服務了，這樣當更多的應用接入時，我們就可以進行橫向擴容解決容量問題。

上圖中為什么每個分治組加載的數據不是完全隔離的呢？這里的原因是應用的依賴是錯綜復雜的，如果我們把每個應用一個點表示，依賴用一條線表示，那么實際生產中，幾乎是不可能形成孤島的，原因是：每個應用依賴的服務是有重疊的，而且很多。

這樣我們便不能隨意地劃分應用，因為如果我們將依賴相似度很高的應用劃分到不同的 Pilot 上，會導致同樣的依賴在多個 Pilot 上加載，造成內存消耗增加。反過來，如果將所有應用都掛到同一個 Pilot 上，那么加載的內存總量是最少的，不過連接就極度不均勻了。

所以本題要求選手優化分治邏輯，讓分治系統均勻承壓。我們先來看看一評分的公式：

公式也不復雜，分為三個評分項：

Pilot 實際加載內存與理想內存的占比，上文提到，不同應用之間依賴的服務可能會有重疊，因此最理想的狀態就是所有服務依賴在整個 Pilot 系統中只加載一次，簡單來說就是將有相似依賴的應用都劃分到同一個 Pilot 中；

Pilot 的內存標準差，這個就比較直白了，就是讓 Pilot 加載的服務盡量均衡，不要出現一個 Pilot 加載很多數據，另一個空閑的狀態；

Pilot 連接的標準差，這個與上面的類似，就是要求 Pilot 連接的 Sidecar 盡量均衡。

由于實際加載的內存肯定是大于等于理想狀態內存，因此最左邊的分子式始終于大于 1 的，也就是說，這是一個倍率；而標準差是大于等于 0 的，顯然想要兩個標準差同時為 0 不現實。因此選手的任務就是分配應用，讓

每個 Pilot 加載的服務數相近；

每個 Pilot 連接的 Sidecar 相近；

盡量不要重復加載服務。

什么意思呢，既然我們已經知道了分治就是讓應用連接不同的 Pilot ，那么每個應用連接上 Pilot 后便會給其一定的壓力。

?

連接的應用越多，壓力越大，但由于服務存在重疊的現象，因此并不完全是線性關系。例如上圖中另一個應用 E 連 接上來后，如果其依賴的服務是 [服務A，服務B，服務E]，那么 Pilot 加載的服務僅會增長 1。這就很好的節省了內存開銷。

因此，如何分配應用至每個 Pilot 上，使其滿足公式所示條件，就是本題的操作空間與需要解決的問題。

需要特別注意的是，本題評分分為了 兩個階段，一個是靜態的，選手可以一次性拿到一階段所有數據，這樣我們就可以整體分析。二階段數據都是實時分批給的，因此如何讓動態的數據也具備良好的表現亦是解題的一個關鍵點。另外還需要注意的一點，Pilot 加載的數據是只境不減的，因為在實際生產環境中，不可能將一個應用瞬間遷移到另一個 Pilot 上，因此已有的數據需要保留。

解題思路

既然我們知道了得分的要點，那我們就可以圍繞這三個點來優化。以下給大家一些分析，以供解題。當然解法很多，下面只是一個列舉。

僅量不要重復加載服務數據

當然是讓依賴相同的應用出現在同一個 Pilot 上，因此我們可以分析應用依賴的相似度，把相似度高的應用歸組一起分配。因為依賴是一個列表，我們可以將其視為一個基因片段或者字符串中的一個字符，問題便成了如何在海量字符串中找到相似的。

Pilot 連接的 Sidecar 相近

當然是每個 Pilot 都一樣為好，理想狀態是均分。平均說到是簡單，但是我們可不能像切蛋糕那樣做呀。每個應用的實例有大有小，那么這里的問題就化為了有一串物品，N 個包他們的價值為 a1, a2, a3……，我們如何放置才能使每個包里物品的價值接近平均值，雖然我們有兩個要求相近的值（內存與連接），不過如果我們再把物品的重量考慮進來，參數維度就增加了。

第二階段動態部分

由于第二階段的數據是不能一次性得到的，因此如何利用已有的數據便成了關鍵，這里一個方向是類似基于已排序數列進行插入再排序的思想，如何構造這樣的一個狀態便是關鍵。

如何拿好成績

由于得分公式是一個整體，單單提升一個是得不到好成績的，因此要想拿好結果，建模是需要的，這樣我們才能知道哪個才是最大的影響因子，或者甚至能夠消除一個變量，那就更好了。

以上內容來自賽道三的明星導師玄胤。

作者信息：
玄胤，阿里云高級技術專家，8 年專注軟負載領域，從 0 到 1 寫過服務百萬實例的軟負載產品，Nacos 奠基人，《Service Mesh 實戰》作者，Istio 社區成員，3項國家發明專利。

挑戰賽交流群

報名成功后，一定要記得加入咱們的挑戰賽交流群哦~

首屆云原生編程挑戰賽選手交流群（釘釘群）：

?

領取通關秘笈：關注“阿里巴巴中間件”公眾號，回復：2020，獲取大賽玩法解析（包含參賽玩法和奇葩任務的玩法）。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的赛题解析|初赛赛道三：服务网格控制面分治体系构建的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。