作者：郭洋
內容簡要：
一、雲原生啟動背景
二、容器化落地
三、比心雲平臺建設
四、研發效能工具建設
五、未來展望
一、雲原生啟動背景
（一）雲原生的理解
雲原生的架構是可彈性、可管理、可觀測、自動化、並且容錯性比較高的一種架構。
業內普遍的一些技術體現，包括容器、微服務、聲明式的API、服務網格、不可變的基礎設施，還有DevOps和12因數，只要應用符合這12因數，那麼它的應用架構就符合雲原生的架構理念。
很多人問Docker或K8s是否算是雲原生技術，我覺得這種理解比較片面，雲原生更多的是一種技術和指導思想，我認為應用天生適合運行在雲上，並且能夠讓應用運行在任意雲上，這種雲包括公有云、私有云和混合雲。
（二）雲原生的價值
接下來我將從以下三個方面談一下我對雲原生價值的理解。
在運維價值方面，首先它屏蔽了底層的基礎設施和底層的異構環境，這一點是比較重要的，因為它讓基礎設施成為了一個比較標準化的環境。其次是管理方便和高效，如果問一個運維，管理2000臺服務器和管理2000個Docker相比哪個相對簡單，相信運維同學給出的答案是管理2000個容器更簡單，這一點我深有體會。目前，整個比心有大概超過5000個容器，對於運維團隊來說，只需要一位運維人員就能夠滿足日常的管理工作。
在業務價值方面，雲原生具備彈性高可用，並且穩定性更高。對於K8s的這個架構來說，K8s天生就具備彈性的能力，它讓我們無需在傳統的ECS去構建這一塊的能力，讓編碼更簡單。其次是高可用，我們使用了K8s之後，我們的橫向擴容能力以及基礎設施的穩定性更高，解決故障更方便。還有就是降本，我認為降本有兩個層面，不僅是基礎資源的降本，還能幫助企業業務功能迭代更快，構建平臺成本更低。比心在這一塊做了很多工作，基礎設施通過資源的壓縮，已經讓CPU使用率大大增加，讓我基礎設施的成本更低。關於業務功能迭代這一塊，尤其是在做CICD這一塊，讓我們的整個流程更簡單，構建速度更快。
在技術價值方面，首先是以K8s為基石帶來的整個生態發展，現在更多的比如Service Mesh技術，邊緣計算等，更多的是基於K8s進行部署。這並不是說它只能在K8s上部署，只是說以K8s的方式部署可以讓我們更簡單方便，它帶來了整個生態的發展。第二點是技術文化氛圍的沉澱，企業更容易吸引優秀的人才，這對於技術人員來說是一件重要的事情。因為很多技術人員更希望待在技術氛圍好，或者是具有前沿技術優勢的企業，比如在面試的時候經常會有面試者詢問，公司是否有在使用容器或者K8s這類技術，因此我覺得有這一塊的技術落地，能夠吸引更多的人才。
（三）微服務帶來的挑戰
微服務帶來的挑戰就是在數字化時代對基礎設施的彈性、時效性提出了更高的要求。
首先是應用方面，第一點就是應用的規模比較大，自從使用了微服務架構之後，我們的應用從原來的幾十個已經發展到如今的六百多個應用，規模翻了好幾十倍。第二點是我們在微服務落地過程中，發現資源使用率比較低。
其次在業務方面，會出現十倍流量洪峰，這對我們的穩定性或者高可用提出了更高的要求，尤其是在直播業務，有時可能因為一個活動就會導致我們的流量成十倍或者二十倍的陡增。
最後是在運維方面，服務器的數量比較多，管理成本比較高。上文提到比心的服務器數量包括容器化數量，已經達到了5000+的規模，運維管理成本較高。
二、容器化落地
（一）集群設計
接下來分享關於比心容器化落地的一些情況。
首先是集群的設計，目前比心集群設計的第一點是採用了多集群高可用部署。當時在選型的時候也是充滿糾結，因為我們測試了很多，包括自建，阿里雲的ACK等，最終在生產上我們選擇了自建K8s加上阿里雲的ACK，採用多集群的部署模式。
第二點是不同業務獨立網關入口，我們每個業務會有獨立的網關，流量打進來後，我們將它進行區分與分離，避免不同業務之間互相影響。
第三個是我們採用了多集群管理控制平臺，比心自研了一個可靠的平臺，這一點在後面會闡述。通過使用這個平臺我們可以對K8s多集群進行管理調度，讓我們不同的應用和任務下發到不同的集群。
其次想談一下集群設計的思想，這邊給團隊提出了一“縱”兩“橫”的思想。一“縱”表示服務器配置可以縱向地擴展，這是基於阿里雲的能力。
目前我們使用的服務器有一些普通ECS和神龍服務器，配置規格普遍在64C 128G或者神農的104C 384G機型。基於阿里雲神龍服務器的縱向擴展能力，如果未來資源不夠了，我們可以把它擴到更高規格，比如300+C 700+G的服務器資源。
兩“橫”的第一橫是我們的K8s Node可以橫向擴容，這 基於K8s本身的橫向擴展能力。目前社區K8s提供的標準大概是能擴容到5000個節點，很多大廠在基於K8s優化的基礎上，已經能夠做到上萬節點。
對於我們來說，保守估計K8s集群擴容到3000個節點是沒有問題的，基於我們現在整個集群的設計，擴容10倍～20倍，在這一個橫向的能力上是沒有問題的。
兩“橫”的第二個橫是K8s集群數量的增加。上文提到比心有一個自研的比心雲平臺，支持K8s的橫向擴展能力是支持。
基於這一“縱”兩“橫”，我們整體K8s的擴容能力可以無限增加，未來能夠支撐10倍、20倍甚至上百倍的業務發展。
（二）容器化的里程碑
下面簡單聊一下比心容器化的里程碑。
目前，自建K8s集群測試環境已經在2019年3月份 100%容器化，UAT環境也在2020年9月份完成了。
生產環境目前採用的是自建和阿里雲的ACK，這一點在2021年3月份已經達到了99%，剩下的1%基本是一些有狀態的應用。容器化整體完成得比較好，已經全面達到99%。
UAT環境和生產環境和測試環境的跨度時間比較長，是因為我們UAT環境和生產環境是一起做的，為了保證環境的一致性，並且我們是一個個團隊去推行的，所以在保障業務穩定性的前提下，整體的容器化的進度還算不錯。
（三）降本
在容器化之後，整個容器化的降本達到了以下效果。
首先是在線業務的資源使用率從5%提升到20%以上，也就是整體的資源使用率之前是很低的狀態，經過容器化之後達到了20%以上。
其次是成本，公有云的成本降低了25%以上，採用的技術手段主要是應用分級加混部，應用分級是對我們的應用做了4層分級，讓不同級別的應用部署在不同服務器裡面。而在混部方面，比如讓第1級的應用和第4級的應用盡量部署在同一臺服務器上。
我們認為應該保證核心應用的穩定性，原生的K8s無法支持，因為原生K8s在調度器這一塊只能夠識別到分配的資源，不能更好地識別到服務器或實際應用的資源使用情況。
舉個例子，它不能夠判斷某一臺ECS實際的CPU使用率是多少，在這一臺ECS上應用的CPU或每一個應用的資源的大概使用情況，根據這些資源的使用情況去做很好的分佈。
我們在全面容器化之後發現整體的ECS使用率不均勻，有些ECS資源使用率比較高，有些ECS資源使用率比較低，所以我們在原生調度器的基礎上做了一些開發和定製，我們更希望它能結合我們內部的一些監控平臺，比如Prometheus或一些其他監控平臺，能拿到這些指標和數據做綜合分析，然後合理做調度。
三、比心雲平臺建設
（一）比心雲平臺
下面主要分析比心雲平臺的建設。
比心雲平臺建設初心主要有兩個點，第一個是讓大家感受不到K8s的複雜，因為一開始我們上K8s的時候，大家的技術棧比較薄弱，對於容器化這一塊，我們的初心是希望不僅讓業務感受不到K8s的複雜，也讓技術、運維團隊感受不到K8s的複雜。
第二個初心是無需業務寫一行dockerfile和yaml文件。這裡比較重要的一點就是能夠讓我們順利推行容器化，儘量不讓業務研發團隊在發版或部署過程中寫dockerfile或yaml文件。可以通過比心的雲平臺，自動生成這些文件，然後自動化進行部署。
比心的雲平臺總共有九大模塊，第一個模塊是容器中心。容器中心的定位主要是管理多個K8s集群，對於K8s所有的Resource進行增刪改查，無需讓運維或業務研發通過yaml文件的方式去操作。
第二個模塊是監控中心，監控中心目前主要是基礎設施層，我們對ECS、容器、Pod或Deployment做資源的監控和告警。
第三個模塊是日誌中心，日誌中心經過了兩個版本的迭代，第一個是ERK平臺，因為我們當時的日誌規模量很大，每天是幾十T的增量。在使用ERK平臺的時候，我們對資源的使用成本比較高。因為我們大家都知道用ES，尤其是日誌量大的時候，而且我們採用了固態硬盤，所以SSD在這一塊成本較高。數據量大的時候，可能偶爾會出現一些因為性能問題導致日誌丟失，基於這個原因，最後我們選型了阿里雲的SRS，它在這一塊的表現不錯。再結合我們自己開發了一些UI的界面，對接到比心雲平臺，讓業務人員或運維團隊能更好地查詢日誌、分析日誌。
第四個模塊是發佈中心，這在下文會詳細介紹，因為它的定位主要是針對整個服務的發版或部署。
第五個模塊是CMDB, 這方面我們給團隊定了一個指標，就是儘量保證數據的準確性和完整性。因為我們一直覺得CMDB是技術配置信息的管理，這方面的數據準確性比較重要。我們以前CMDB在使用過一段時間之後，發現CMDB的一些信息和數據的準確度不是那麼高，會影響上層應用或上層業務的使用。這一點我們是基於應用出發，儘量讓每個應用都能自己管理資源。第二點是結合自動化，然後可以自動化地通過監控平臺或一些其他的運維平臺，收集到以應用為維度的一些關聯關係或配置信息，然後去做實時同步。
第六個模塊是應用管理，通過應用管理，我們能夠讓業務或每個團隊的負責人做管理的應用，比如通過應用管理配置應用的成員、權限或一些發版的策略，甚至能夠看到應用容器Pod狀態。
第七個模塊是消息中心，我們提供了統一化的消息接口，能夠對業務提供比如發送釘釘、打電話或發短信。
第八個模塊是雲商管理，因為比心使用多個公有云的資源，比如阿里雲、騰訊雲等，針對這些雲，我們做了一些資源管理以及賬單分析。
第九個模塊是權限中心，權限中心也是我們對業務提供的中心化權限管控，對接各個業務的後臺管理系統，能夠方便地為業務團隊提供權限管控能力。
（二）監控中心
下面聊一下我們監控中心的架構。
上文提到監控中心主要是針對基礎設施，所以一開始選型就用了Prometheus。大家都知道在業內裡面Prometheus既有它的優勢，也有一些不足之處，比如Prometheus天生就不具備橫向擴展能力，對於存儲也沒有很好的解決方案。
其次，我們針對一些數據做了整合，然後進行統一顯示。我們的方案是採用一些開源的方案。比如說我們用Thanos進行日誌數據的收集和處理，比如一天以內的數據保留在本地磁盤，讓它有更好的性能查詢。對於一天以上的數據，我們保存在阿里雲的OSS裡，可以讓成本更低。並且採用Thanos的Query功能，還可以做統一化的查詢，也就是說我們不需要關心指標在哪一套Prometheus集群裡面，通過統一化的數據整合，能夠做快速查詢。
在配置層，我們開發了一個叫rule-engine的組件，能夠通過API的形式很好地配置如告警規則，達到一個什麼樣的閾值然後告警，或是把這些告警分發給誰。傳統Prometheus用的方法是讓大家寫大量的yaml文件，我們這裡相當於屏蔽了這一塊，然後以API的形式去提供這方面的能力，並且通過上層的UI，讓運維團隊通過可視化的一個界面，更好地配置這些。
告警層我們自己開發了一個叫cloud-monitor的告警組件，因為我們已經捨棄了Prometheus的Alertmanager，因為我們覺得它無法滿足多元化的需求，所以我們自研了組件cloud-monitor，通過這個組件進行告警，不僅可以通過釘釘、短信或電話的方式告警，還能做一些分級，發送到不同的業務人員或不同團隊。
（三）HPA開發
關於HPA的開發，我們的初衷是由於原生HPA支持的指標比較單一，不能很好地適配各種業務場景，比如它原生指標可能只支持CPU和內存，其他指標比如一些業務形態指標，它無法很好支持。因此，我們在開源的基礎上去適配對接了一些業務平臺，比如現在已經能夠做到定時擴縮容，還能夠根據QPS、熔斷、限流指標做一些擴縮容。
我們採用的開源工具主要是KEDA,然後基於開源工具的基礎上，我們做了大量的二開，並且做了一個可視化的UI界面，對接到我們的的雲平臺上，讓運維團隊或業務團隊能夠更好地做一些配置或管理工作。並且我們還支持批量配置，比如我們能夠很好地配置在某一個NameSpace下所有Deployment指標。
（四）Warm Up
Warm Up是為了解決我們業務上的痛點，因為我們基本上使用的都是Dubbo服務, Dubbo的服務本身天然具備 Warm Up的功能。
當然,我們也有一些外部服務，比如這些外部服務在流量湧入的情況下，尤其是在服務發版或服務重啟時，請求大量湧入，可能會造成服務GC，導致出現超時。基於這個痛點，我們雲原生平臺團隊開發了Warm Up的這樣一個Controller，可以根據Pod的狀態控制SLB流量的進入，尤其是在發版的時候，我們通過Pod狀態信息，慢慢調整SLB流量比例，比如可以按時間維度，這些配置都可以通過yaml文件進行，比如每15秒進入5%的流量，從而解決流量大量湧入，可能會造成服務GC的情況。
目前這個已經在平臺通過測試，我們也在慢慢上手使用它。
（五）GPU服務器容器化、平臺化
下面跟大家聊一下我們關於GPU服務器的容器化、平臺化。
我們是從2021年年初開始去做這個事情，從2020年開始我們所有的業務容器化已經做得差不多了，所以就開始探索GPU這個方面。
我們沒有做這一塊之前，整體使用GPU的服務器資源是共用的，並且隔離性比較差，基本上都是手動部署，沒有使用一些自動化的工具，並且沒有標準，技術棧比較多樣性，比如可能一些算法的框架用了比較多，生產基本上是單節點沒有高可用。大家都知道像GPU這種服務器本身成本比較高，所以我們在以前的ECS上沒有去做一些高可用的部署。
基於以上痛點，我們做了一些 GPU容器化的探索，主要使用了阿里CGPU的一些技術,解決搶佔GPU資源，提升了資源使用率。
我們將一張卡，比如利用阿里雲的CGPU技術可以分成多份，並且使用容器化技術做到很好的資源隔離和限制。第二個就是把它通過我們的雲平臺做到了自動化和平臺化，讓任務訓練或部署通過雲平臺可以自動化迭代，大幅提高開發人員的效率。
第三個是支持了分佈式任務的部署和調度。
最後一個是整個技術棧可以做到標準化、統一化，讓業務人員可以更方便省心地使用底層的基礎設施資源。
（六）Flink容器化的演進
下面分享關於Flink容器化的演進。
一開始比心整個大數據平臺的技術棧比較多樣化，我們有自建的Hadoop集群，也有阿里的一些OTPs之類的，我們從2019年開始慢慢探索Flink的使用。
當時，我們使用的Flink有一個阿里雲半托管的，還有一個自建的，主要是用了篩選模式。這個模式的缺點主要是資源使用率不高，因為我們當時基本上是先準備好資源。
舉個例子，我們一開始使用的是100C 400G的資源，在使用過程中，我們看到整體的資源使用率比較低，因為無論使用不使用，它已經申請在那裡因此從2020年開始，我們開始使用Native/Session的這種Flink模式，希望能夠結合阿里雲ECI彈性資源，提升資源使用率。
比如在計算的過程中，在某個時間段我們不需要這麼多資源，就可以把這些資源釋放，也就是做到按量使用按需付費，這是我們整體Flink平臺的演進。
四、研發效能工具建設
（一）研發效能
下面介紹比心研發效能工具的建設。
面向雲原生的開發運維協同方式
這裡主要是面向雲原生的開發運維協同方式。比心在這方面經歷了好幾次的迭代，從最開始使用GitLab CI/CD，後面我們使用Jenkins，再到現在自研了一個比心的研發效能平臺，也就是上文提到的比心雲平臺裡發佈任務模塊，我們從需求出發，打通了整個需求的管理系統，並且能夠自動更新需求信息。
在開發階段，我們可以做到自動代碼檢測，讓業務人員直接做一些Code Review功能，還能做自動合併分支，並且支持多種語言。比如，內部有Python、Java等。
在測試階段，自動化對接了接口測試的平臺，還有一些單元測試平臺，當然這些平臺可能由其他團隊提供。
在發佈階段，可以做到發佈流程審批，並且能夠自動發佈網關。由於我們自研了一套網關係統，因此可以在發版過程中自動做網關部署。
我們的研發效能主要幾個階段，第一個是需求，第二個是測試，第三個是UAT第四個是生產，第五個是驗證，最後一個是完成。我們每個環境的流水線，主要有幾個階段，第一個是拉取基礎信息，比如把代碼拉下來，然後會做發佈檢測，這個檢測主要包括是否需要發佈網關，是否符合發佈規則，如果開啟了自動合併功能，我們會把代碼做自動合併，如果沒有，會跳到下一步代碼檢測。
在代碼檢測會做一些比如說靜態代碼掃描，然後或者是做一些SQL的審核。下一個階段是編譯，編譯之後會判斷是否需要編譯網關，如果不需要就直接進入打包鏡像。我們會把打包好的鏡像直接發到鏡像倉庫裡，最後通過平臺自動化拉取部署，這就是整個流水線的完整階段。
通過發佈中心，大幅提升了整個研發的迭代效率。
五、未來展望
最後一個就是說做一個對技術做一個未來的展望。
首先是K8s，我們希望能夠做到多集群調度，屏蔽底層的K8s時，雖然目前比心的雲平臺能夠管理多個K8s集群，但是這遠遠不夠，目前僅僅是做到了讓業務感知不到底層有多少K8s集群，以及每個應用部署在哪套K8s集群上，但運維團隊或雲原生平臺其實還是能夠感知到。
並且，我們希望整個K8s集群能夠無限橫向擴展，比如我們現在用二套或者三套，希望未來可能有五套或者十套，並且隨著K8s集群的增加，能夠讓所有的人員感覺不到應用部署在哪套K8s上，並且當應用出現問題的時候，能夠自動做切換做調度，這也是我們對於未來平臺建設的一個訴求。
第二個是中間件容器化，因為目前我們業務的容器化基本完成，對於中間件的容器化，這是我們對於未來的一個展望。因為對於中間件管理,大家都知道做有狀態的服務，它對於底層存儲的性能要求比較高，目前業內沒有一個很好的解決方案。其次是我們有沒有達到這個階段，比如Kafka集群有沒有上到一定的規模，在集群規模比較小的情況下，其實還是沒有必要做的。因為隨著中間件資源規模的增加,我們希望未來能夠在這方面更好的賦能業務，比如做到中間件資源彈性，讓運維部署這些中間件集群時能夠更加方便。
第二個方面是大數據，我們一直以來都想做一個一站式的大數據容器平臺，因為我們現在大數據的技術棧還是挺多，上文提到我們可能有Flink、Spark、Hadoop等資源。我們希望通過一個平臺能夠把這些資源做整合，做自動化的處理，更好地提供給業務團隊使用，包括未來大數據平臺或底層基礎設施，我們希望儘量能夠做到統一化和標準化。
下面一個就是離線和在線的一個混部，因為我們現在對於資源使用率，我們現在剛才也說了，我們現在做到了20%以上，希望我們希望未來能夠去做到30%或者40%。
其次是離/在線混部，這個技術對於我們來說也是未來的一個大方向，我們希望通過這些能夠讓使用技術資源的成本更低，比如把一些大數據離線任務能夠和在線業務部署在一起，或採用晚高峰分離，從而達到降本的效果。
第三點是關於存算分離，最近業內比較火的一個詞叫數據庫，包括很多一線的大廠其實都在做這個事情，我們這邊也在探索。我們希望通過數據庫這個理念或者架構，可以將數據做到統一化，因為我們目前的數據是分散的，並且對於整個數據的存儲，隨著規模增加，成本越來越高。我們希望通過數據庫做到我們底層資源，比如使用OSS這種更低廉的存儲工具，更好地支撐我們的業務，讓我們的計算資源能夠無限橫向擴展。
最後想跟大家聊一下Mesh化，我個人從2018年初就開始關注這一塊的技術。當時技術還不是很成熟，我們公司採用的是Spring Cloud的架構，對於傳統的比如Spring Cloud也好，Dubbo也好，這種代碼的耦合性比較重，而Service Mesh可以更好做到從業務代碼和非功能需求代碼的剝離，然後讓整個業務、應用迭代更快更清亮。
Service Mesh在服務治理方面已經做了很多工作，比如服務發現、服務配置、熔斷、限流，還支持AB測試，灰度等功能。我們希望能夠使用Service Mesh，把基礎設施做厚中間件做薄，讓業務更好地迭代，讓業務不需要關心這些，比如中間件這一層的一個架構，在發版的時候讓業務無感知。
