背景
01 應用運維背景
隨着數字化轉型的發展，線下業務逐漸線上化，應用數量與日俱增，應用架構也趨於多樣化和複雜化，而 IT基礎設施逐步雲化標準化並趨於穩定，因此運維的重心和價值漸漸聚焦於應用。應用運維團隊肩負着保障業務系統正常運轉的重大責任。同時伴隨着新業務形態，新技術架構的誕生，對應用運維提出了更高的要求。
02 應用發佈存在的問題
因業務的需求，應用迭代的頻率越來越高，如果依舊爲人工發佈，出錯概率大大提升，迫使人工運維轉向自動化。
SLA的要求越來越高，那麼就促使發佈過程中，不同發佈策略的靈活使用。
應用的數量越來越多，架構越來越複雜，需要一套配置管理工具快速響應應用的變化，並且能支持多種應用架構。
環境的管理，從開發到上線，不同環境的切換繁瑣，難控制，易出錯。
標準化，自動化的前提工作是先做好標準化，如果無法有效協同資源對象，那麼在構建相應應用運維工具時就會陷入無窮無盡的適配工作中。
應用發佈系統設計
01 設計理念和原則
隨着分佈式系統的不斷推廣，應用發佈越來越頻繁，應用數量越來越多，建立一個功能齊全、靈活的發佈工具成爲自動化最緊急重要的需求。
在設計一個發佈系統時應考慮可複用性，和易用性，設計原則如下：
配置管理：應用發佈的前提是做好配置管理，基於CMDB，支持不同類型的應用架構，打通其他系統形成一體化的發佈平臺。
原子化：將發佈中的操作進行建模拆解，建立細顆粒度的操作原子，通過編排進行操作場景的組合，提升可複用性和可擴展性
標準化：一切自動化的前提都是標準先行，發佈系統需要引導與規範應用運維人員操作和配置。
自動化：發佈操作儘可能的自動化，防止過多的人工干預。
發佈策略：支持常用的發佈策略，並行發佈，滾動發佈等
發佈模式：支持多模塊的發佈，支持多模塊的發佈順序的編排。
整體架構圖如下：
02 發佈系統架構
我們使用藍鯨平臺，在此之上構建應用發佈系統，設計思路如下：
以應用爲中心建設CMDB：
着眼於應用而不是資源對象，以縱向的維度劃分模塊，使用服務樹拓撲管理應用，拓撲的設計支持傳統應用架構和互聯網應用架構，支持多環境，多集羣管理。
▲ 服務樹拓撲
在CMDB之上擴展應用配置中心：
納管應用相關聯的信息：應用的程序包，配置文件、SQL包，模板集、Helm、進程，基礎資源，主機，發佈參數，並支持模塊與模塊之間的調用關係管理，從而向上支撐應用運維場景。
程序包管理：提供基礎文件存儲，版本管理的能力，但是更加推薦對接製品庫的方式。
應用配置文件管理：提供基礎的文件儲存，版本管理能力，還可以通過變量配置與實例化的能力，來支持不同環境下配置文件的變化。
模板集：是一組以應用爲視角的k8s配置yaml文件的集合，通過參數管理與版本管理，簡化資源管理的複雜度。
對接harbor倉庫實現Helm的管理與發佈。
▲ 應用配置管理
完備的底層能力
發佈的過程終歸是對於發佈對象的操作執行，藍鯨平臺強大的腳本作業的執行，文件的分發是操作的基礎。
雙流程編排
管理與執行的天然結合，更加貼切企業發佈場景：
發佈方案強大的可視化編排能力，支持單/多應用的發佈編排，支持定時，並行，滾動發佈。
發佈過程提供實時的過程跟蹤與豐富的控制能力。
執行流程原子化與編排，提供靈活的編排能力，可以將操作原子編排組合起來，並提供參數化管理，使得編排出來的流程可以靈活複用，當內置原子無法滿足對應操作場景時，可以自定義開發實現。
發佈場景與發佈策略
我們按照上述發佈系統的設計，可以支撐企業中不同發佈場景的需求。
01 發佈策略
爲了保證發佈過程中，保證應用對外提供正常的服務，應用發佈自動化支持不同的發佈策略。
一次性全部部署（並行發佈）
將應用下所有實例同時停止運行，並行更新版本，然後同時啓動所有實例，這種策略在發佈時不需要額外的資源，但是存在服務中斷。
▲ 並行發佈
滾動發佈
滾動的策略，設置停止實例的數量，例如1，意味着在發佈過程中，先停止一箇舊實例，更新完成後啓動它，然後週而復始，直至所有實例更新完畢，這樣就可以保證發佈過程中服務不中斷，也不需要額外的資源，但是它的缺點是發佈需要的時間很長。
▲ 滾動發佈
藍綠髮布
這種發佈策略是爲了解決滾動發佈中，承擔負載的實例數量減少，可能會帶來未知的壓力，藍綠部署的方式是，先額外創建一批新的實例，並更新版本，然後將流量切換到新的實例上，由新的一批實例對外提供服務，在測試觀察新版本沒有問題後，將舊的實例銷燬。這種方式意味着在升級的過程中，需要同時運行兩套程序，所需要的資源是日常的兩倍。但是這種策略的好處是，不中斷服務，並且在發佈過程中出現了問題，可以快速回滾。
▲ 藍綠髮布
金絲雀發佈（灰度發佈）
這種策略的做法是，先在舊的實例中，挑出少量的實例，將他們踢出負載均衡進行更新，然後將部分流量引導到新的實例上進行流量驗證（金絲雀測試），保證新版本沒有問題之後，將剩下的實例進程更新。這個過程就像，礦工開礦下礦洞前，先會放一隻金絲雀進去探是否有有毒氣體，看金絲雀能否活下來，再決定是否能進入礦洞。
在金絲雀過程中就需要對流量進行篩選，通常我們可以使用nignx針對於IP，設備類型，瀏覽器類型進行流量的切割，針對於特定用戶類型的流量，我們可以通過定製http請求頭的方式進行條件的篩選。
▲ 金絲雀發佈
02 發佈窗口模式
目前大部分企業的應用發佈模式一般還是以發佈窗口的形式存在。
發佈窗口指一個特定的時間段（一般選擇系統負載較低的時候進行），在這個時間段內一個或多個團隊可以發佈應用到生產環境。應用數量多，且應用之間存在依賴，這時針對於多模塊發佈的場景，編排就成了發佈系統重要的功能之一。
▲ 發佈窗口模式
03 傳統應用的發佈場景
在傳統的應用發佈場景中，經常會存在着同一個模塊下的不同主機可能運行着不同的進程（或是進程不同，或是端口不同，或是啓動命令不同），但使用的程序包是一樣的。
▲ 傳統應用發佈場景
如圖，我們可以看到的一種單模塊多服務的場景：
Service unit A，服務A運行在不同主機上，每個主機上運行着一個實例，並對外提供相同的端口服務。這樣在發佈時，同一模塊不同應用實例是統一的，我們只需要關注每一個服務實例的配置信息即可。
Service unit B，服務B在不同實例上運行着相同的進程，但是實例監聽着不同的端口。這樣在發佈時，我們需要對於參數的管理需要下沉到主機，這樣大大增加了適配上的工作量。
Service unit C，服務C在不同實例上運行着不同的進程，且存在多個實例運行在同一個主機上，那麼在發佈時，我們要關注的顆粒度就會非常的小，細化到進程的管理，管理上的難度隨着場景的複雜度成倍增加。
面對於這種傳統的場景，我們通過對於進程的管理來實現這種細顆粒度參數管理，從而滿足傳統應用的發佈。
總結
以CMDB爲基礎，在此之上擴展應用配置管理完成對於應用配置信息的納管，底層抽象發佈中的執行流程，以應用發佈自動化爲樞紐，通過上層編排聯動應用配置管理與執行流程，實現單/多模塊發佈，可視化任務編排、任務執行實時跟蹤，發佈策略，和多種人工干預方式等。
本文出自嘉爲藍鯨公衆號，如您有興趣，歡迎聯繫我們。