PaaS容器集群優(yōu)化之路

1. 性能優(yōu)化面對的挑戰(zhàn)

以下是整個PaaS平臺的架構

其中主要包括這些子系統(tǒng)：

微服務治理框架：為應用提供自動注冊、發(fā)現(xiàn)、治理、隔離、調用分析等一系列分布式/微服務治理能力，屏蔽分布式系統(tǒng)的復雜度。

應用調度與資源管理框架：打通從應用建模、編排部署到資源調度、彈性伸縮、監(jiān)控自愈的生命周期管理自動化。

應用開發(fā)流水線框架：打通從編寫代碼提交到自動編譯打包、持續(xù)集成、自動部署上線的一系列CI/CD全流程自動化。

云中間件服務：應用云化所需的數(shù)據(jù)庫、大數(shù)據(jù)、通信和應用中間件服務；通過服務集成管控可集成傳統(tǒng)非云化的中間件能力。

面對一個如此復雜的系統(tǒng)，性能優(yōu)化工作是一個非常艱巨的挑戰(zhàn)，這里有這么一些痛點：

源代碼及開發(fā)組件多，100+ git repo，整體構建超過1天

運行架構復雜，全套安裝完需要30+VM，200+進程

軟件棧深，網(wǎng)絡平面復雜

集群規(guī)模大，5k — 10k節(jié)點環(huán)境搭建非常困難

系統(tǒng)操作會經(jīng)過分布式的多個組件，無法通過單一組件診斷發(fā)現(xiàn)系統(tǒng)瓶頸

無法追蹤上千個處于不同層次的API的時延和吞吐

大部分開發(fā)人員專注于功能開發(fā)，無法意識到自己的代碼可能造成性能問題

2. 優(yōu)化分析

那么，對于這么一個大的、復雜的系統(tǒng)，從方法論的角度來講，應該怎么去優(yōu)化呢？基本思路就是做拆分，把一個大的問題分解為多個互相不耦合的維度，進行各個擊破。從大的維度來講，一個PaaS容器集群，可以分為3個大的子系統(tǒng)。

控制子系統(tǒng)：控制指令的下發(fā)和運行(k8s)，例如創(chuàng)建pod

業(yè)務流量子系統(tǒng)：容器網(wǎng)絡(flannel)、負載均衡(ELB/kube-proxy)

監(jiān)控子系統(tǒng)：監(jiān)控告警數(shù)據(jù)的采集(kafka, Hadoop)

這個看起來僅僅是一個架構上的劃分，那么如何和具體的業(yè)務場景對應起來呢？我們可以考慮如下一個場景，在PaaS平臺上大批量的部署應用?？纯丛诓渴饝玫倪^程中，會對各個子系統(tǒng)產(chǎn)生什么壓力。

應用軟件包大?。?00M

應用模板大?。?0M

1000個節(jié)點，每個節(jié)點一個POD，一個實例

10種類型的軟件包，依賴長度為3，10GB 網(wǎng)絡

調度及資源管理 3VM

這是一個典型的部署應用的一些規(guī)格，那么對于這樣的一個輸入，我們可以按照架構把壓力分解到每個子系統(tǒng)上，這樣得出的子系統(tǒng)需要支撐的指標是：

控制子系統(tǒng)： kubernetes調度速度 > 50 pods/s，倉庫支持300并發(fā)下載，>40M/s

數(shù)據(jù)子系統(tǒng)：overlay容器網(wǎng)絡TCP收發(fā)性能損耗 <5%

監(jiān)控子系統(tǒng)：在上面這個場景中不涉及，但可以從別的場景大致告警處理能力100條/秒

這里的業(yè)務場景：架構分析：子系統(tǒng)指標，這三者是m:1:n的，也就是說在不同場景下對不同的組件的性能要求不同，最后每個組件需要取自己指標的最大值。

指標決定了后續(xù)怎么進行實驗測試，而測試是要花較大時間成本的，所以在指標的選取上要求少求精，盡量力圖用2-3個指標衡量子系統(tǒng)。

3. 優(yōu)化測試 & 工具

上面講的還是偏紙上的推演和分析，接下來進入實戰(zhàn)階段

對于服務器后端的程序來講，推薦使用Promtheus這個工具來做指標的定義和采集。Promtheus的基本工作原理是：后端程序引入Promtheus的SDK，自定義所有需要的測量的指標，然后開啟一個http的頁面，定期刷新數(shù)據(jù)。Promtheus服務器會定期抓取這個頁面上的數(shù)據(jù)，并存在內部的時間序列數(shù)據(jù)庫內。這種抓而非推的方式減少了對被測試程序的壓力，避免了被測程序要頻繁往外發(fā)送大量數(shù)據(jù)，導致自身性能反而變差而導致測量不準確。Promtheus支持這幾種數(shù)據(jù)類型：

計數(shù)(對應收集器初始化方法NewCounter、NewCounterFunc、NewCounterVec，單一數(shù)值，數(shù)值一直遞增，適合請求數(shù)量統(tǒng)計等)

測量(對應收集器初始化方法NewGauge、NewGaugeFunc、NewGaugeVec，單一數(shù)值，數(shù)值增減變動，適合CPU、Mem等的統(tǒng)計)

直方圖測量(對應收集器初始化方法NewHistogram、NewHistogramVec，比較適合時長等的統(tǒng)計)

概要測量(對應收集器初始化方法NewSummary、NewSummaryVec，比較適合請求時延等的統(tǒng)計)

我們可以看看在kubernetes項目里面是怎么用的：

var ( // TODO(a-robinson): Add unit tests for the handling of these metrics once // the upstream library supports it. requestCounter = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "apiserver_request_count", Help: "Counter of apiserver requests broken out for each verb, API resource, client, and HTTP response contentType and code.", }, []string{"verb", "resource", "client", "contentType", "code"}, ) requestLatencies = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: "apiserver_request_latencies", Help: "Response latency distribution in microseconds for each verb, resource and client.", // Use buckets ranging from 125 ms to 8 seconds. Buckets: prometheus.ExponentialBuckets(125000, 2.0, 7), }, []string{"verb", "resource"}, ) requestLatenciesSummary = prometheus.NewSummaryVec( prometheus.SummaryOpts{ Name: "apiserver_request_latencies_summary", Help: "Response latency summary in microseconds for each verb and resource.",// Make the sliding window of 1h. MaxAge: time.Hour, }, []string{"verb", "resource"}, ) )

在這里，一個http請求被分為verb, resource, client, contentType, code這五個維度，那么后面在PromDash上就能圖形化的畫出這些請求的數(shù)量。 從而分析哪種類型的請求是最多，對系統(tǒng)造成最大壓力的，如圖

除了Promtheus，還可以引入其他的測量手段，對系統(tǒng)進行分析。

在kubernetes調度過程中，各個狀態(tài)Pod的數(shù)量，看哪一步是最卡的

go pprof分析，哪些函數(shù)是最耗CPU的

4. 優(yōu)化開發(fā)

發(fā)現(xiàn)了瓶頸之后，下一步就是解決瓶頸，和具體業(yè)務邏輯有關，本文在這里就不做過多的闡釋。需要對相關代碼非常熟悉，在不改變功能的情況下增強性能，基本思路為并發(fā)/緩存/去除無用步驟等。

5. 優(yōu)化的優(yōu)化

在上面的優(yōu)化過程當中，基本上工程師要做幾百次優(yōu)化的測試和開發(fā)。這里會產(chǎn)生一個循環(huán)：

測試尋找瓶頸點

修改代碼突破這個瓶頸點

重新測試驗證這段代碼是否有效，是否需要改優(yōu)化思路

這就是一個完整的優(yōu)化的迭代過程，在這個過程當中，大部分時間被浪費在構建代碼、搭建環(huán)境、輸出報告上。開發(fā)人員真正思考和寫代碼的時間比較短。為了解決這個問題，就需要做很多自動化的工作。在kubernetes優(yōu)化的過程中，有這么幾項方法可以節(jié)省時間：

5.PNG

kubemark模擬器 ：社區(qū)項目，使用容器模擬虛擬機，在測試中模擬比達到1：20，也就是一臺虛擬機可以模擬20臺虛擬機對apiserver產(chǎn)生的壓力。在測試過程當中，我們使用了500臺虛擬機，模擬了10000節(jié)點的控制面行為。

CI集成：提交PR后自動拉性能優(yōu)化分支并開始快速構建

CD集成：使用I層的快照機制，快速搭建集群并執(zhí)行測試案例輸出測試報告

以上都是在實踐過程中總結的一些點，對于不同的項目工程應該有很多點可以做進一步的優(yōu)化，提升迭代效率。

在搭建完這套系統(tǒng)后，我們發(fā)現(xiàn)這個系統(tǒng)可以從源頭上預防降低系統(tǒng)性能的代碼合入主線。如果一項特性代碼造成了性能下降，在CI的過程當中，功能開發(fā)者就能收到性能報告，這樣開發(fā)者就能自助式的去查找自己代碼的性能問題所在，減少性能工程師的介入。