宜信公司從2018年初開始建設容器雲，至今，容器雲的常用基本功能已經趨於完善，主要包括服務管理、應用商店、Nginx配置、存儲管理、CI/CD、權限管理等，支持100+業務線、3500+的容器運行。伴隨公司去VMware以及DevOps、微服務不斷推進的背景，後續還會有更多的業務遷移到容器雲上，容器雲在宜信發揮着越來越重要的作用。本次分享主要介紹宜信容器雲平臺的背景、主要功能、落地實踐及未來規劃。
一、宜信容器雲平臺背景
宜信容器雲平臺的建設背景主要包括：
- 提高資源利用率。容器雲建設之前，每臺物理機上平均運行的虛擬機大概是20個，使用了容器雲之後，每臺物理機上平均運行的容器數達到50個；之前的CPU利用率大概在10%左右，遷移到容器雲後，CPU利用率提高到20%以上，整個資源利用率得到了極大的提升。
- 提升服務可靠性。傳統的虛擬機運維方式下，當機器宕機或系統故障時，需要運維手動重啓虛擬機和服務，整個過程最快需要幾十分鐘到幾個小時才能解決；使用容器雲後，通過健康檢查的方式，一旦發現有問題就自動重啓恢復服務，可以達到分鐘級甚至秒級的恢復。
- 節約成本。通過容器雲提高了資源利用率，同時也節約了成本。公司每年會採購一些商業化軟件，如虛擬化軟件、商業存儲等，費用動輒千萬。我們基於開源技術自研一套容器解決方案，每年爲公司節省上千萬的軟件採購和維保費用。
- 彈性伸縮。我們公司每年都會組織財富峯會，在這裏有一個很經典的場景：秒殺，秒殺場景需要很快擴展業務的計算能力。爲了快速應對互聯網突發流量，如上述的財富峯會、APP線上活動，我們爲服務設置了自動伸縮的策略：當CPU利用率達到60%的時候，自動做容器擴容，應對突發的業務流量，提高響應速度；活動過後，自動回收資源，提高資源的利用率。
- DevOps整合。DevOps和敏捷開發的理論已經提出很多年了，爲什麼DevOps一直沒有得到很好的推進和實踐呢？因爲缺乏一種工具把Dev和Ops聯繫起來，而容器的誕生很好地解決了這個問題。開發人員在開發完代碼並完成測試以後，可以拿着測試的產物直接到生產環境部署上線，而部署的問題可以直接反饋給開發，形成閉環。也就是說，通過容器的方式，可以實現一次構建多次運行。由此可見，通過容器的方式實現DevOps是最佳的方案，企業亟需一套成熟的平臺幫助開發和運維人員保持各個環境的一致性和快速發佈、快速回滾。
在上述背景下，我們結合宜信的業務場景開發建設宜信容器雲平臺。
二、宜信容器雲平臺主要功能
宜信容器雲平臺經過一年多時間的建設和開發，基本的常用功能已經具備。如圖所示。
上圖左側是宜信容器雲平臺的主要功能，包括：服務管理、CI/CD、代理出口、配置管理、文件存儲、告警策略、鏡像管理、用戶管理、權限管理、系統管理等。
右側是一個服務管理的界面，從中可以看到服務列表、服務名稱、服務狀態及當前服務數量，還有當前鏡像版本及更新時間。
2.1 宜信容器雲平臺架構
上圖所示爲整個容器雲平臺的架構圖，在各種開源組件（包括Harbor鏡像倉庫、Kubernetes容器管理、Prometheus 監控、Jenkins構建、Nginx流量轉發和Docker容器虛擬化等）的基礎之上，我們自研開發了5個核心模塊。
- Cluster-mgr，負責多個Kubernetes集羣之間的管理和調度，在一個Kubernetes集羣出現問題後，將該集羣的容器遷移到其他可用的Kubernetes集羣，並且負責資源的計量。
- Ipaas，負責對接各種資源，如調用Kubernetes API創建容器、對接Ceph創建存儲、對接Harbor獲取鏡像等。前端頁面通過Ipaas獲取容器相關的新聞數據、監控指標等。
- Codeflow，負責代碼構建。通過對接Jenkins實現代碼編譯、打包鏡像以及服務的滾動升級等工作。
- Nginx-mgr，一個對接多個Nginx集羣的管理系統，負責將用戶在頁面配置的規則轉成Nginx配置，並下發到對應的Nginx集羣。
- Dophinsync，和公司CMDB系統打通，從CMDB系統同步公司所有項目和服務的相關數據和信息。
最上面是對用戶提供的web-portal頁面，一個用戶自助的終端。
本次分享的標題是《宜信容器雲的A點與B點》，之所以稱爲A點和B點，這與我們的公司文化有關，我們以“A點”代指現在已經做到的事情，以“B點”代指未來或者下個階段要做的事情。
目前整個宜信容器雲平臺已經完成了大部分主要功能點的開發，這部分已經實現的功能即爲“A點”，包括服務管理、應用商店、域名管理、CI/CD、鏡像管理、文件存儲、監控告警、定時任務、配置管理等。後續還有部分功能需要添加和完善，即爲“B點”，主要包括：對象存儲、大數據容器雲、全面日誌收集、自定義指標伸縮、智能調度和混部、多集羣管理、安全隔離、站點監控等，
2.2 宜信容器雲功能模塊
上圖爲宜信容器雲平臺的整體功能圖，其中藍色代表已經完成的功能、黃色代表需要優化和改善的功能。
整個系統從資源管理的角度來看：
- 底層是硬件層面的計算、存儲、網絡；
- 其上是資源管理層，負責容器、存儲、域名、鏡像、集羣管理；
- 往上是中間件層，包括Kafka、MySQL等中間件服務；
- 再往上是應用層，提供給用戶使用的終端；
- 兩側分別是CI/CD的構建流程和安全認證相關的功能組件。
下面將通過頁面截圖的方式，詳細介紹容器雲的主要功能點。
2.2.1 主要功能點——服務管理
上圖是服務管理頁面的截圖，逐一介紹各個功能。
- 容器列表。上側的菜單是服務管理的列表，進入到某一個服務管理，就可以對服務進行具體操作，包括基本配置、升級、擴縮容、域名管理、同步生產環境等。
- 歷史容器。 服務升級或故障遷移之後，容器的名稱、IP地址等會發生變化，歷史容器的功能是記錄一個服務下面容器的變化情況，方便我們追蹤容器的變化，追溯性能監控數據，進行故障定位。
- 日誌下載。可以通過頁面方式直接下載用戶日誌數據。終端信息與前面的日誌輸出是有區別的。前面的日誌下載是應用把日誌保存到容器裏的某一個指定路徑下；終端信息是容器標準輸出的日誌，Event信息裏主要記錄容器的狀態信息，比如什麼時候拉取鏡像、什麼時候啓動服務等。Webshell主要提供容器登錄，可以像SSH一樣通過頁面的方式登錄到終端。
- 非root登錄。爲了保持容器生產環境的安全，我們以非root的方式登錄容器控制檯，避免誤刪數據。
- Debug容器實現，通過啓動一個工具容器，掛載到業務容器裏，共享網絡、進程等數據。傳統的方式希望容器鏡像儘可能小、安裝的軟件儘可能少，這樣啓動更快、安全性更高，但由於容器本身只安裝了程序必要的依賴，導致排查文件困難。爲了解決這個問題，我們基於開源技術開發了debug容器功能：debug容器掛載到業務容器中，共享業務容器的網絡內存和主機相關的各種信息，這樣一來，就相當於在業務容器中執行了debug命令，既方便運維和業務人員排查故障，保障了容器的快速安全，又爲業務提供了一種更好的debug方式。安裝的客戶端如Reids客戶端、MySQL客戶端、Tcpdump等。
- 容器性能監控，包括CPU、內存、網絡IO、磁盤IO等監控指標。
- 審計，用戶所有操作命令都會通過審計工具進行審覈。
- 摘除實例，主要是針對一些異常容器的故障定位，將流量從負載均衡上摘除。
- 銷燬功能，當容器需要重建時會用到銷燬功能。
除了上文介紹的一排容器按鈕以外，還有一些針對服務的相關操作，比如服務的基本配置：環境變量、域名解析、健康檢查，服務的升級，替換鏡像、擴縮容等操作。
2.2.2 主要功能點——應用商店
很多業務場景有這樣的需求：希望可以在測試環境裏實現一鍵啓動中間件服務，如MySQL、Zookerper 、Redis、Kafka等，不需要手動去配置kafka等集羣。因此我們提供了中間件容器化的解決方案，將一些常用的中間件導入容器中，後端通過Kubernetes維護這些中間件的狀態，這樣用戶就可以一鍵創建中間件服務。
但由於這些中間件服務本身相對來說比較複雜，所以目前我們的應用商店功能主要是爲大家提供測試環境，等這部分功能成熟之後，會把應用商店這些常用的中間件拓展到生產環境上，到時候就可以在生產環境使用容器化的中間件服務了。
2.2.3 主要功能點——CI/CD
CI/CD是代碼構建流，我們內部稱爲codeflow。其實代碼構建流程非常簡單，一句話概括起來，就是：拉取倉庫源代碼，通過用戶指定的編譯腳本構建出執行程序，將執行程序放到用戶指定部署路徑，並通過啓動命令啓動這個服務。系統會爲每個codeflow生成對應的Dockerfile用於構建鏡像，用戶不需要具備Docker使用經驗。
上面的流程是代碼編譯，下面是通過系統預先生成的Dockerfile，幫用戶打包成Docker Image，這就是從代碼拉取、代碼編譯、打包到Docker Image並推送到鏡像倉庫的整個流程。
用戶完成配置並點擊提交代碼後，就可以通過手動或Webhook的方式觸發整個構建流程。也就是說只要用戶一提交代碼，就會觸發整個構建流程，編譯源代碼、打包Docker鏡像、推送鏡像倉庫並觸發滾動升級，用戶可以在分鐘級別看到效果。 在這裏我們還做了一些小的功能：
- 非root構建。我們的後端其實是在一個Jenkins集羣下構建的，這樣就存在一個問題：如果用戶在編輯腳本的時候，不小心寫錯代碼就可能會將整個主機上的東西都刪除，非常不安全。爲了解決這個問題，我們在整個構建過程中採用非root構建的方式，避免某個用戶因編譯腳本執行某些特權操作而影響系統安全。
- 自定義Dockerfile。支持某些用戶使用自己的Dockerfile構建鏡像，用戶通過上傳Dockerfile的方式，覆蓋系統生成的Dockerfile。
- 預處理腳本，主要針對Python類的鏡像構建，Python類的鏡像構建本身不需要編譯源代碼，但運行環境需要依賴很多第三方的包和庫，如果將這些依賴包都安裝到基礎鏡像，不僅會導致基礎鏡像過大，而且後期維護也很麻煩。爲了支持Python軟件容器化的運行，我們提供了預處理腳本，即在業務鏡像之前先執行預處理腳本，幫用戶安裝好所需要的依賴包，然後再把用戶的代碼拷貝過來，基於預處理腳本之後的鏡像去生成業務鏡像，下次構建的時候，只要預處理腳本不變，就可以直接構建業務鏡像了。
- Webhook觸發和Gitlab集成，通過Gitlab的Webhook，當用戶在提交代碼或者merge pr的時候便可以觸發codeflow，執行自動上線流程。
2.2.4 主要功能點——文件存儲
容器通常需要業務進行無狀態的改造，所謂“無狀態”是需要把一些狀態數據放在外部的中間件或存儲裏。
我們提供了兩種存儲方式：NFS和Cephfs文件存儲。用戶在頁面選擇存儲的容量，然後點擊創建，就可以直接創建一個Cephfs文件存儲，並且可以在服務管理頁面指定將這一存儲掛載到容器的某一個路徑下，當容器重啓或者遷移後，文件存儲會保持之前的目錄掛載，從而保障數據不丟失。
2.2.5 主要功能點——Nginx配置
公司有大概100多個Nginx集羣，之前這些Nginx集羣都是通過運維人員手動方式變更配置和維護，配置文件格式不統一，且容易配置錯誤，問題和故障定位都很困難。爲此我們在容器雲集成了Nginx配置管理，通過模板的方式生產Nginx配置。Nginx配置的功能比較多，包括健康檢查規則、灰度發佈策略等相關配置。
上圖是一個系統管理員可以看到的頁面，其中部分項目開放給業務用戶，允許用戶自己定義部分Nginx配置，如upstream列表，從而將公司域名配置模板化。
除此之外，我們還做了配置文件的多版本對比，Nginx的每次配置都會生成一個對應的版本號，這樣就可以看到在什麼時間Nginx被誰修改了哪些內容等，如果發現Nginx配置修改有問題，可以點擊回滾到Nginx的歷史版本。
泛域名解析，主要適用於測試環境。之前每一個測試服務都需要聯繫運維人員單獨申請一個域名，爲了節省用戶申請域名的時間，我們爲每個服務創建一個域名，系統通過泛域名解析的方式，將這些域名都指定到特定的Nginx集羣。
Nginx後端可以包含容器也可以包含虛擬機，這是在業務遷移過程中非常常見的，因爲很多業務遷移到容器都並非一蹴而就，而是先將部分流量切換到容器內運行。
2.2.6 主要功能點——配置文件管理
現在的架構提倡代碼和配置分離，即在測試環境和生產環境使用相同的代碼，不同的配置文件。爲了能夠動態變更配置文件，我們通過Kubernetes的Configmap實現了配置文件管理的功能：將配置文件掛載到容器內，用戶可以在頁面上傳或者編輯配置文件，保存後，系統將配置文件更新到容器內。
就是說當用戶在頁面上傳或編譯某個配置文件以後，平臺會自動把配置文件刷新到容器裏，容器就可以使用最新的配置文件了。爲了避免用戶誤刪配置文件，當系統發現配置文件被使用則不允許刪除。
2.2.7 主要功能點——告警管理
告警管理功能基於Prometheus實現。平臺會把所有的監控數據，包括容器相關的（CPU、內存、網絡IO等）、Nginx相關的、各個組件狀態相關的數據，都錄入到Prometheus裏，用戶可以基於這些指標設置監控閾值，如果達到監控閾值，則向運維人員或業務人員發送告警。
值得一提的是，我們提供了一種特殊的告警：單個容器性能指標。按常理，每個容器監控指標應該是類似的，沒有必要針對單個容器設置告警，但在實際生產環境中，我們遇到過多次由於某個特定請求觸發的bug導致CPU飆升的場景，所以開發了針對單個容器的性能告警。
三、容器容器雲平臺落地實踐
前面介紹了系統的一些常用功能，接下來介紹宜信容器雲平臺落地過程中的實踐。
3.1 實踐——自定義日誌採集
容器的使用方式建議用戶將日誌輸出到控制檯，但傳統應用的日誌都是分級別存儲，如Debug日誌、Info日誌、Error日誌等，業務需要採集容器內部指定目錄的日誌，怎麼實現呢？
我們通過二次開發Kubelet，在容器啓動前判斷是否有“KUBERNETES_FILELOGS”這個環境變量，如果存在，則將“KUBERNETES_FILELOGS”指定的容器目錄掛載到宿主的“/logs/容器名稱”這個目錄下面，配合公司自研的日誌採集插件Watchdog便可以將宿主機上這個目錄下的文件統一收集。
3.2 實踐——TCP代理出口
在實際過程中我們經常遇到網絡對外提供服務的場景，系統中除了Nginx提供的 HTTP反向代理以外，還有一些需要通過TCP的方式對外提供的服務，我們通過系統中指定的兩臺機器安裝Keepalive和配置虛IP的方式，對外暴露TCP服務。
3.3 實踐——自動擴容
自動擴容，主要是針對業務指標的一些突發流量可以做業務的自動伸縮。其原理非常簡單：因爲我們所有的性能指標都是通過Prometheus統一採集，而Cluster-mgr負責多集羣管理，它會定時（默認30s）去Prometheus獲取容器的各種性能指標，通過上圖的公式計算出每個服務的最佳副本個數。公式很簡單：就是每個容器的性能指標求和，除以用戶定義目標指標值，所得結果即爲最佳副本數。然後Cluster-mgr會調用Ipaas操作多個集羣擴容和縮容副本數。
舉個例子，現在有一組容器，我希望它的CPU利用率是50%，但當前4個副本，每個副本都達到80%，求和爲320，320除以50，最大副本數爲6，得到結果後就可以自動擴容容器的副本了。
3.4 實踐——多集羣管理
傳統模式下，單個Kubernetes集羣是很難保證服務的狀態的，單個集羣部署在單個機房，如果機房出現問題，就會導致服務不可用。因此爲了保障服務的高可用，我們開發了多集羣管理模式。
多集羣管理模式的原理很簡單：在多個機房分別部署一套Kubernetes集羣，並在服務創建時，把應用部署到多個Kubernetes集羣中，對外還是提供統一的負載均衡器，負載均衡器會把流量分發到多個Kubernetes集羣裏去。避免因爲一個集羣或者機房故障，而影響服務的可用性。
如果要創建Kubernetes相關或Deployment相關的信息，系統會根據兩個集羣的資源用量去分配Deployment副本數；而如果要創建PV、PVC以及Configmap等信息，則會默認在多個集羣同時創建。
集羣控制器的功能是負責檢測Kubernetes集羣的健康狀態，如果不健康則發出告警，通知運維人員切換集羣，可以將一個集羣的服務遷移到另一個集羣。兩個集羣之外通過Nginx切換多集羣的流量，保障服務的高可用。
這裏有3點需要注意：
- 存儲遷移。底層提供了多機房共享的分佈式存儲，可以隨着容器的遷移而遷移。
- 網絡互通。網絡是通過Flannel + 共享etcd的方案，實現跨機房容器互通及業務之間的相互調用。
- 鏡像倉庫間的數據同步。爲了實現兩個鏡像倉庫之間鏡像的快速拉取，我們在兩個機房內都部署了一個鏡像倉庫，這兩個鏡像倉庫之間的數據是互相同步的，這樣就不用跨機房拉取鏡像了。
3.5 實踐——如何縮短構建時間
如何加速整個CI/CD構建的流程？這裏總結了四點：
- 代碼pull替換clone。在構建代碼的過程中，用pull替換clone的方式。用clone的方式拉取源代碼非常耗時，特別是有些源代碼倉庫很大，拉取代碼要耗費十幾秒的時間；而用pull的方式，如果發現代碼有更新，只需要拉取更新的部分就可以了，不需要重新clone整個源代碼倉庫，從而提高了代碼拉取的速度。
- 本地（私有）倉庫、mvn包本地緩存。我們搭建了很多本地（私有）倉庫，包括Java、Python的倉庫，不需要再去公網拉取依賴包，這樣不僅更安全，而且速度更快。
- 預處理腳本。只在第一次構建時觸發，之後便可以基於預處理腳本構建的鏡像自動構建。
- SSD加持。通過SSD硬件的加持，也提高了整個代碼構建的速度。
3.6 實踐——什麼樣的程序適合容器
什麼樣的程序適合運行在容器裏？
- 無操作系統依賴。目前主流容器方案都是基於Linux內核的cgroup和namespace相關技術實現的，這就意味着容器只能在Linux系統運行，如果是Windows或者C#之類的程序是無法運行到容器裏面的。
- 無固定IP依賴。這個其實不算硬性要求，雖然容器本身是可以實現固定IP地址的，但固定的IP地址會爲Deployment的自動伸縮以及集羣遷移帶來很多麻煩。
- 無本地數據依賴。容器的重新發布是通過拉取新的鏡像啓動新的容器進程的方式，這就希望用戶不要將數據保存到容器的本地，而是應該藉助外部的中間件或者分佈式存儲保存這些數據。
3.7 避坑指南
在實踐過程中會遇到很多問題，本節將列舉一些已經踩過的坑，逐一與大家分享我們的避坑經驗。
3.7.1 爲啥我的服務沒有起來？
這種情況可能是因爲服務被放在了後臺啓動，容器的方式和之前虛擬機的方式有很大區別，不能把容器服務放在後臺啓動，容器啓動的進程的PID是1，這個程序進程是容器裏唯一的啓動進程，如果程序退出了容器就結束了，這就意味着程序不能退出。如果把程序放到後臺啓動，就會出現進程起來了但容器服務沒有起來的情況。
3.7.2 爲啥服務啓動/訪問變慢？
之前使用虛擬機的時候，由於配置比較高（4核8G），很多業務人員沒有關心過這個問題。使用容器之後，平臺默認會選中1核1G的配置，運行速度相對較慢，這就導致了業務在訪問業務的時候會覺得服務啓動和訪問變慢。
3.7.3 爲啥服務會異常重啓？
這和配置的健康檢查策略有關，如果某應用的配置健康檢查策略不通過的話，Kubernetes的Liveness探針將會重啓該應用；如果業務是健康的，但提供的健康檢查接口有問題或不存在，也會重啓這個容器，所以業務要特別注意這個問題。
3.7.4 本地編譯可以，爲啥服務器上代碼編譯失敗？
這個問題非常常見，大多是由於編譯環境和服務器環境的不一致導致的。很多業務在本地編譯的時候，本地有一些開發工具的加持，有一些工作開發工具幫助完成了，而服務器上沒有這些工具，因此會出現這個問題。
3.7.5 爲啥我的歷史日誌找不到了？
這個問題和容器使用相關，容器裏默認會爲用戶保存最近兩天的日誌，主機上有一個清理的功能，日誌超過兩天就會被清理掉。那這些超過兩天的日誌去哪裏查看呢？我們公司有一個統一的日誌採集插件Watchdog，負責採集存儲歷史日誌，可以在日誌檢索系統中檢索到這些歷史日誌。
3.7.6 爲啥IP地址會變化？
每次容器重啓，其IP地址都會發生變化，希望業務人員的代碼不要依賴這些IP地址去配置服務調用。
3.7.7 爲啥流量會打到異常容器？
容器已經異常了，爲什麼還有流量過來？這個問題具體表現爲兩種情況：業務沒起來，流量過來了；業務已經死了，流量還過來。這種兩種情況都是不正常的。
- 第一種情況會導致訪問報錯，這種場景一般是通過配合健康檢查策略完成的，它會檢查容器服務到底起沒起來，如果檢查OK就會把新的流量打過來，這樣就解決了新容器啓動流量的異常。
- 第二種情況是和容器的優雅關閉相結合的，容器如果沒有匹配優雅關閉，會導致K8s先去關閉容器，此時容器還沒有從K8s的Service中摘除，所以還會有流量過去。解決這個問題需要容器裏面應用能夠支持優雅關閉，發送優雅關閉時，容器開始自己回收，在優雅關閉時間後強制回收容器。
3.7.8 爲啥沒法登錄容器？
很多時候這些容器還沒有起來，此時當然就無法登陸。
3.7.9 Nginx後端應該配置幾個？OOM？Cache？
這幾個問題也經常遇到。在業務使用過程中會配置CPU、內存相關的東西，如果沒有合理配置，就會導致容器的OOM。我們新版的容器鏡像都是自適應、自動調整JVM參數，不需要業務人員去調整配置，
3.8 faketime
容器不是虛擬機，所以有些容器的使用方式並不能和虛擬機完全一致。在我們的業務場景裏還有一個問題：業務需要調整時鐘。
容器和虛擬機的其中一個區別是：虛擬機是獨立的操作系統，修改其中一個虛擬機裏的任何東西都不會影響其他虛擬機。而容器除了前面說的幾種隔離以外，其他東西都不是隔離的，所有的容器都是共享主機時鐘的，這就意味着如果你改了一個容器的時鐘，就相當於改了整個所有容器的時鐘。
如何解決這個問題呢？我們在網上找到一種方案：通過劫持系統調用的方式修改容器的時鐘。但這個方案有一個問題：faketime不能睡着了。
3.9 使用情況
經過幾年的推廣，目前宜信容器雲平臺上已經支持了100多條業務線，運行了3700個容器，累計發佈17萬次，還榮獲了“CNCF容器雲優秀案例”。
四、宜信容器雲未來規劃
前文介紹了宜信容器雲平臺目前取得的一些小成就，即宜信容器雲平臺的A點，接下來介紹宜信容器雲的B點，即未來的一些規劃。
4.1 對象存儲
公司有很多文件需要對外提供訪問，如網頁中的圖片、視頻、pdf、word文檔等，這些文件大部分都是零散地保存在各自系統的存儲中，沒有形成統一的存儲管理。如果文件需要對外提供訪問，則是通過Nginx反向代理掛載NAS存儲的方式，這些文件的維護成本非常高，安全性也得不到保障。
我們基於Ceph開發一個統一的對象存儲服務，把公司零散在各個系統的小文件集中到對象存儲中去，對於可以提供外網或公網訪問的部分，生成外網訪問的HTTP的URL。目前對象存儲已經在業務的測試環境上線。
4.2 站點監控
站點監控是一個正在重點研發的功能。公司開源了智能運維工具UAVstack，側重於應用的監控，還缺乏服務外部的站點監控。站點監控是爲了監控服務接口的運行狀態，併發送告警。
我們通過在公司外部部署採集Agent，這些Agetnt會根據用戶定義的監控URL定時調用接口是否正常運行，如果接口返回數據不符合用戶設定條件則發出告警，如HTTP返回5xx錯誤或者返回的body中包含ERROR字符等。
4.3 大數據容器雲
在大部分業務遷移到容器後，我們開始嘗試將各種大數據中間件（如Spark、Flink等）也遷移到Kubernetes集羣之上，利用Kubernetes提供的特性更好地運維這些中間件組件，如集羣管理、自動部署、服務遷移、故障恢復等。
4.4 混合部署
公司有很多長任務，這些長任務有一個非常明顯的特點：白天訪問量較高，晚上訪問量較低。對應的是批處理任務，批處理主要指公司的跑批任務，如報表統計、財務賬單等，其特點是每天凌晨開始執行，執行時對CPU和內存的消耗特別大，但只運行十幾分鍾或幾個小時，白天基本空閒。
爲了得到更高的資源利用率，我們正在嘗試通過歷史數據進行建模，將批處理任務和長任務混合部署。
4.5 未來規劃——DevOps平臺
最後介紹我們整個平臺的DevOps規劃。
回到之前容器雲的背景，業務需要一套統一的DevOps平臺，在這個平臺上，可以幫助業務完成代碼構建、自動化測試、容器發佈以及應用監控等一系列功能。
其實這些功能我們基礎研發部門都有所涉及，包括自動化測試平臺 Gebat、應用監控UAVStack、容器雲平臺等，但是業務需要登錄到不同的平臺，關聯不同的數據，而各個平臺之間的數據不一致、服務名稱不對應，沒辦法直接互通，操作起來非常麻煩。 我們希望通過建立一個統一的DevOps平臺，把代碼發佈、自動化測試、容器運行和監控放到同一個平臺上去，讓用戶可以在一個平臺完成所有操作。