宜信公司從2018年初開始建設容器云，至今，容器云的常用基本功能已經趨于完善，主要包括服務管理、應用商店、Nginx配置、存儲管理、CI/CD、權限管理等，支持100+業務線、3500+的容器運行。
主講人介紹
[[287112]]
陳曉宇：宜信高級架構師 & 宜信PaaS平臺負責人
導讀：宜信公司從2018年初開始建設容器云，至今，容器云的常用基本功能已經趨于完善，主要包括服務管理、應用商店、Nginx配置、存儲管理、CI/CD、權限管理等，支持100+業務線、3500+的容器運行。伴隨公司去VMware以及DevOps、微服務不斷推進的背景，后續還會有更多的業務遷移到容器云上，容器云在宜信發揮著越來越重要的作用。本次分享將圍繞容器云展開，主要介紹其設計思想、技術架構和核心功能，以及容器云在宜信落地的實踐經驗。
分享大綱：
一、宜信容器云平臺背景
二、宜信容器云平臺主要功能
三、容器容器云平臺落地實踐
四、宜信容器云未來規劃
以下為直播視頻，可點擊回放，時長59m21s，建議在WiFi環境下觀看。
分享實錄
宜信公司從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切換多集群的流量，保障服務的高可用。
- 存儲遷移。底層提供了多機房共享的分布式存儲，可以隨著容器的遷移而遷移。
- 網絡互通。網絡是通過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不能睡著了。 經過幾年的推廣，目前宜信容器云平臺上已經支持了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平臺，在這個平臺上，可以幫助業務完成代碼構建、自動化測試、容器發布以及應用監控等一系列功能。其實這些功能我們基礎研發部門都有所涉及，包括自動化測試平臺 Gebat、應用監控UAVStack、容器云平臺等，但是業務需要登錄到不同的平臺，關聯不同的數據，而各個平臺之間的數據不一致、服務名稱不對應，沒辦法直接互通，操作起來非常麻煩。我們希望通過建立一個統一的DevOps平臺，把代碼發布、自動化測試、容器運行和監控放到同一個平臺上去，讓用戶可以在一個平臺完成所有操作。
【本文是51CTO專欄機構宜信技術學院的原創文章，微信公眾號“宜信技術學院( id: CE_TECH)”】
戳這里，看該作者更多好文
