賽題解析|初賽賽道三：服務網格控制面分治體系構建

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

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

當即報名（報名時間即日起至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 上，那麼加載的內存總量是最少的，不過鏈接就極度不均勻了。

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

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

1. Pilot 實際加載內存與理想內存的佔比，上文提到，不一樣應用之間依賴的服務可能會有重疊，所以最理想的狀態就是全部服務依賴在整個 Pilot 系統中只加載一次，簡單來講就是將有類似依賴的應用都劃分到同一個 Pilot 中；
2. Pilot 的內存標準差，這個就比較直白了，就是讓 Pilot 加載的服務儘可能均衡，不要出現一個 Pilot 加載不少數據，另外一個空閒的狀態；
3. Pilot 鏈接的標準差，這個與上面的相似，就是要求 Pilot 鏈接的 Sidecar 儘可能均衡。

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

1. 每一個 Pilot 加載的服務數相近；
2. 每一個 Pilot 鏈接的 Sidecar 相近；
3. 儘可能不要重複加載服務。

什麼意思呢，既然咱們已經知道了分治就是讓應用鏈接不一樣的 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，獲取大賽玩法解析（包含參賽玩法和奇葩任務的玩法）。