大家好,我是來自去哪往的DAWOBS產品經理陳敬賢今天將由我和我的同事DAWOBS技術專家鄒聖一起來給大家進行去哪往容器化全面落地實踐的分享今天分享的內容主要包含以下幾個方面首先是容器化落地的背景與挑戰然後會介紹三個實踐案例分別包括時序交付的眼鏡容器化多級群部署和自動化自動遷移接下來我們先看第一部分容器化落地的背景與挑戰我們經常會聽到這樣的聲音服務器資源成本太高了我們必須得降低成本有一台宿主故障了需要把上面的服務趕快恢復測試環境好好的為啥上線就失敗了呢業務高峰來了資源不夠用了趕緊去擴容哎 但是擴容太慢了這些聲音的背後呢反映了一系列的問題這些問題會導致我們的企業無法進行快速迭代嚴重阻礙企業的發展通用電器前CEO傑克威爾奇說過如果外部變化的速度超過內部變化的速度終結就不遠了我們當今的時代呢是一個快速發展的時代同時充滿了各種不確定性和激烈的競爭企業是否能夠對外部變化做出快速的決策和反應呢決定了一個企業的生死存亡與發展面對諸多的問題我們應該怎麼辦呢答案是雲煙生容器技術作為雲煙生的代表技術之一呢目前已經在企業中廣泛應用它可以帶來呃 它可以幫助企業降低成本加速應用創新靈活應對商業發展中的不確定性基於這些特點呢就有了我們今天容器化全面落地的項目呃 自項目開始以來呢然後我們從4月份開始進行遷移然後我們也已經享受到了容器技術所帶來的紅利然後我們通過機組數據來看一下我們的一些收益呃 我們遷移的應用總數呢大概是有3000多個目前已經完成了80%借助容器化的這個技術呢我們的資源利用率提升了76%運位效率提升了400倍交付速度呢 也提升了40%由於KBAR-S提供了呃 容器資育的能力我們 據統計呢我們的那個服務在每個月當中平均每 呃 平均呃 重啟資育的次數大概在2000次左右雖然我們現在是看到了這些收益但是呢 在容器化呃 落地過程當中並不是那麼順利的我們也遇到了一些挑戰那麼接下來呢我們看一下我們的挑戰還有相應的一些應對措施首先第一個呢因為我們要在全公司進行全面推廣所以就涉及到了很多很多的部門包括我們的基礎基礎部門以及20多個業務部門這麼多的部門呃 協同合作是比較困難的呃 好在這次呢是我們是自上而下推行公司制定了企業級的目標就是用暴雲煙聲這樣各部門在這個目標的言令下呢然後協同一致共同向目標邁進第二個是改造範圍大因為容器本身它是無狀態的但是在過去我們的各種工具鏈呢對IP對機器名有比較嚴重的依賴這在容器化環境下呢就已經完全不再適用了針對種種問題然後我們需要對這些工具鏈去進行改造這個困難還是相對比較大一些的但是作為一個基礎服務嘛然後我們就必須得克服困難然後各個擊破了呃 第三點是千億成本的問題因為涉及到三千多個應用每個應用的升級改造呢都需要耗費大量的人力為了去降低業務的成本然後我們把這些呃中間有業務改造層的這些東西呢就是統一在中間階層然後做到了統一的失配然後通過中間階的自動升級以及容器化的自動千億然後來降低業務部門的成本第四點就是學習成本的問題新技術的引入呢就是說涉及到我們千人機研發團隊就需要額外的一些時間然後去學習和使用呃 為了解決這個問題呢我們在平台層然後進行了可視化的配置引導師的操作以及優化流程盡量的然後去屏蔽業務層對呃對整個的這個新技術的一個嗯一個學習成本接下來呢然後我們來看一下呃 在我們雲煙生環境下我們的持續交付都做了哪些嗯 眼鏡早在之前呢我們就已經在公司內部然後推行了DevOps然後呢我們的交付流程也已經採用了是說是以業務價值然後驅動的呃 驅動交付的這樣的一個雙流模型呃 但是呢就是我們的雙流模型裏邊也存在一個比較嚴重的一個問題是說呃 在我們的研發那個持續交付工作流裏邊然後我們的工作流沒有真正的流動起來這是為什麼呢是因為工具平台之間呢就是說缺少一個統一的規範然後還存在著好多的數據孤島所以也沒有辦法擅長的流轉起來然後有些狀態的流轉呢還是要靠人工來驅動然後在這次容器化落地的過程當中呢然後我們通過了一系列的舉措對應用平台進行了規範統一從而做到了工具流從自動呃工具流可以自動流轉然後打到了一鍵部署的這種效果然後極大的提升了交付效率那麼我們是通過什麼樣的方式然後來來使我們的這個整個的工作流流轉起來的呢比較重要的一個因素就是我們制定了這個應用畫像然後呢對應用進行了一些標準化的定義在過去呢開發人員在面對開發測試生產都複雜了環境的時候呢需要辨寫各種各樣的一些配置運為人員呢也需要去對接各種不同的平台所以就導致了我們之前就是剛才在那個工作流流轉當中的各種不能夠自動流轉的問題所以我們參照雲岩生的OEM模型呢建立了應用畫像對應用進行了規範定義然後我們先來看一下應用畫像我們都包含了哪些一個是基本屬性在基本屬性當中呢我們定義了我是誰我從哪來然後我的一些級別就是相當於一個身份的一個標識然後定義了一些發布的一些規則一些參數然後呢在環境運為屬性當中呢然後會去定義有關於資源啊軟件版本環境配置以及擴縮龍的一些規則服務依賴裡邊呢就包括了網絡依賴數據庫依賴服務依賴等等這樣的話我們在對一個應用是去新增機器或刪減機器的時候呢就不需要在額外的去申請權限然後可以基於應用層然後去進行自動授權這樣呢我們整個過程交付過程當中的各工具平台是以應用為中心的然後通過這個應用描述然後去進行協作然後從而達到了剛剛我們所提到的就是工作流的自動流轉在持續交付過程當中呢另外一個比較突出的一個改造呢就是說我們那個部署方式的一個改變我這裡是列了幾個維度然後首先呢是在對於部署方式來說KVM是原地部署也就是說我們把一個服務先進行下線然後再下線操作然後通過同步代碼然後去部署上線這樣的一個過程但是在容器裡邊呢我們所做的是滾動升級也就是說是先把版本升上去之後沒有問題然後服務啟動沒有問題之後呢是把原有的版本然後去進行銷毀這樣的一個優勢呢就是說反映出來就是說我們的部署速度會更快然後發布過程當中呢服務的穩定性不會受到任何的影響為什麼會這麼說呢因為就是說原地部署的問題如果我們是批一個批次對操作的那個服務器數量過多的話會對線上的那個再建服務器的數量會產生一些影響會影響服務的那個負載情況所以在KVM時代呢我們是分了很多批次但是基於容器化的滾動升級這一特性呢然後我們可以在一個批次當中然後就完成了這個部署升級的這樣一個過程過去呢我們可能對一個稍微大一些的應用需要30多分鐘目前來說呢可能就是說是幾分鐘兩三分鐘就可以完成另外的一個儀點呢就是說是灰度方式在KVM時代呢我們的灰度相當於是從摘取了線上機器然後來進行部署的這樣摘取了線上機器然後就是說線上的那個原有版本的那個機器數就會變少了嗎像當員然後出現問題啊或者是什麼然後如果進行下線操作然後一些然後的處理然後對線上服務是存在一定影響的但是在容器化的這個方式下呢我們是通過了一種新的方式我們可以增加少量的灰度容器然後進行版本升級然後不用加入到線上機群一旦發現問題呢我們對這些直接繼續進行下線不管操作線上的影響非常非常小這些呢就是說我們選取了幾點在持續交付過程當中改進比較突出的幾個點然後來進行來跟大家進行分享接下來呢然後又請我的同事然後再進行其他內容的分享好我給大家介紹一下我們的多級群部署架構首先大家看一下這個架構圖我們這個架圖裡一共分了三層第一層就是Porto CD平台這一層裡主要是包括了我們的應用畫像信息應用了部署參數等等依賴信息那第二層就是比較重要的資源調度層資源調度它下面會對接了我們的私有員的平台比如說我們的OpenStack還有新介入的KFRS平台還有就是我們最近強調的公用員強調雲端協同利用公用員的一些彈性彈性伸縮的能力來解決我們就是資源警覺的一些問題那在這裏KFRS我們是採用了KFRSphere這個國內比較有名的一些企業級多級群管理方案因為KFRSphere它這個是對運位非常友好而且多端統一還有一些是安全性比較好所以我們採用了KFRSphere來管理這個KFRS然後我們在資源調度層其實主要考慮了三個策略第一個就是清合性就是我們上網KFRS之後因為有一些舊的機器可能要退還有一些配置比較低的就是我們針對於這些機器給它設定了一些優先級就是之前的機器配置低的我們讓一些優先機低的應用比如說P3P4的會往這些機器上調度對於優先機高的P2我們會把它調度到一些配置高的機器上比如說ICD換在網卡的這是清合性方面的然後第二個是容量預估就是我們在資源調度之前我們會估算好就是我們KFRS各個集群的集群容量是否充足如果不夠的話我們可能這次發布就直接禁止了免得它現有的應用發布然後第三個就是機器復甩因為KFRS默認的調度其實它是不關心機器復甩的它只是關心容量那我們是利用我們譬如是歷史數據收集了它的機器的各個指標然後分析這些指標然後作為判斷條件做一些調度的這是資源調度的一塊另外這個圖裡大家還能看到有Eastel還有Sirlace這兩個原生的你們的應用兩個技術Eastel這塊是老師是Mess的一個代表它解決了是應用的把基礎能力非功能性的一些需求功能能下沉到底層業務不需要關心不需要關心底層的一些功能只需要關心它的業務代碼就可以了那我們在這塊也是投入了很多現在也是在測試一段Sirlace這一塊其實是未來的一個大趨勢它能釋放延伴的生產力所以這一塊我們也在調研做一些技術儲備這是我們多級巡駕口那對於當個級權力部署我們是什麼做呢那這裡我們主要採取的策略就是雙敵部門的策略那這裡我們為什麼採用雙敵部門的策略它主要是因為有三個優勢第一個就是它降低了操作複雜度你看這裡我們拿個取個例子比如說因為它從唯一升級到二那它的升級過程其實只要設計了五個步驟第一個是創建一個新的部門然後做技術操作第二個操作就是對於原來的版本做縮容操作然後第四個就是對新版本做擴容操作最後一步就是把原來版本刪除那這個操作非常簡單而對於原有的原生的敵部門的更新操作的話它有一場情況如果說新版本有問題它卡在中間但是由於應用問題或者其他問題導致這個時候可能卡在中間狀態你回滾肉脈有可能回滾不了所以這個時候雙敵部門的優勢就體現出來了就採用上面的話就不會影響原先的應用第二個優勢就是分皮操作分皮操作其實可以讓整個發佈更可控按照上圖看到的第一批發佈完之後大家QA員可以對線上操作做驗證如果沒問題之後再進行第二批這對發佈的質量就是很有幫助的第三個就是更新Department Label變為可能我單Department其實更新 Label其實是不可能的那雙Department其實這就不是問題了這是我們的雙Department的策略第四部分是我們主要關注的就是自動遷移這個方案其實是為業務人員節省了很多人力的所以這個是也是很有期限意義的為什麼我們為什麼要做這部分主要就是因為他節省了人力還有他採用了一些工程化的方法能解決這些大量人力那大家看看這部分是怎麼做的我們主要採用了七個步驟去來實現自動遷移第一部分就是前置交驗就是遷移檢驗的應用的交驗那這裡包括幾個部分舉個例子就是其他應用的SDK是否引用了我們的就是TCDV BOMB這個TCDV BOMB包含了就是我們容量化遷移的一些必須的業組件如果沒有引用的話其實它是不支持的第二個就是它還對一些比如說有狀態應用做了檢查是否包含一些後生內幕信息還有一些日治的一些標準化做了交驗如果這些不符合我們能規範的話其實這交驗會是失敗的那第二步就是測試環境驗證這一塊就是我們升級完SDK之後會發不到測試環境驗一下功能第三部分就是線上驗證發不到線上之後也分為幾個步驟首先它是不接領料的然後做一下自動化CASE驗證如果通過的話再接線上的流量再去做一些成功的驗證還有自動化CASE第四步就是這時候就是我們上線之後就是KVM和容器它是混合部署的會按照一定的權重比例去分配這個流量那這個時候就是我們會持續關注它一個指標和監控如果沒問題的話就是到了第五步我們會為全量部署容器然後KVM的實力會下線那第六步其實就是還是我們會觀察一周如果一周之內沒有任何問題也非常穩定的話就我們會把KVM回收放到回收的對立等待機器的自動刪除那這裡為了實現這個自動化方案我們這裡有幾個技術點需要提一下比如說第一個就是我們的二方二方包和三方包的統一管理我們是用的SuperFarmTEDVBOMB把我們的核心組件比如說Double還有各種Metal SDK還有其他的 SDK統一還有配置中心吊還有吊度分布式吊度等等這些組件統一放到這些TEDVBOMB管理了如果要做容力化遷移只需要引用我們核心版本就可以所以這個是我們自動化遷移的前提條件第二個是這輛門徑這輛門徑是主要是做代碼檢查的它會檢查我們就是代碼裡的一些版本它使用的中間鍵的版本是否兼容和容器遷移是否兼容如果不兼容的話上線前其實它是會有問題的所以在我們做編譯的時候就會提前檢測第三部分就是我們自動驗證這個組件兼容性比如說我們Double我們在自動生體的時候會驗證我們Double和業務線裡和那些場景是否兼容那我們做完了容器化之後是我們跑自動化Case就拿業務線的Case跑多個營養多組營養去驗證生體後的TEDVBOMB的組件然後跑出的結果並和Master分支跑出的結果做DVBOMB然後超過一定比例就我們認為這個其實版本是OK的然後我們就可以讓業務線可以使用這些升級的中間鍵第四個其實就是我們一定要有發布的超管學線因為我們要做自動的升級回渡上線等等這些都需要超級管理學線那再說一下這裡比較有意思的技術就是我們是怎麼做的就是自動升級的其實這部分在敲碗裡我們編譯都是一種沒穩所以我們也是在沒穩的編譯階段做了一些文章比如說我們加了一個插線Upgrade在執行編譯以前我們用這個命令首先做了一下判斷判斷這個TEDVBOMB如果它它如此的指定版本我們就會就更改它這個POM文件更改為最新版本這樣它就滿足升級容器的條件了接著我們就為基於它的Mass分支然後去做編譯然後去做部署這裡部署我們會部署到測試環境恢徒環境和線上環境但這裡測試環境恢徒環境和線上環境其實每個上線前我們都做了功能卡點會教驗對線上是否有影響因為這個是非常必要的同時執行這些部署的過程中我們也要持續關注核心核心醫務的監控和指標最後我們在如果都OK了之後我們會回收KM但在整個過程中其實還有幾個注意事項第一個就是先以前資源容量一定要做好評估因為我們就是就在這一塊由於沒有做好導致集群容量有一陣子爆滿了因為有些大應用就是幾百個實例同時並發遷移的然後把整個我們GIRS基訓資源打爆了所以之前遷移前已經要規號有條例的就應用有條例的去遷移上線第二點就是上線前的功能卡點比如說就是我們每個P4應用分批發佈每個P4發佈前我們可能需要驗證下它是否更新到線上呢Ingris裡就是我們的NGNG裡如果沒有更新成功我們就是會阻斷其實這一塊我們也遇到過幾個故障所以就是為了解決這些隱患所以我們在每個P4就是更新後我們會加一個卡點它更新成功了我們再去再去刪除老的版本這次功能卡點必要行第三個就是一定要保證我們發佈系統有回滾到KMM的功能因為之前就有一些業務遷移到容器之後其實上線之後是OK的但突然發現有個故障就是之前你其實應該是強以來但是它設置為弱以來所以上線成功了它的CheckR也過了但是其實發生故障了那這時候回滾是由於之前有點問題就是回滾KMM就稍微慢一些所以這也給我們一個教訓就是回滾到KMM的功能一定要快速有效所以這三點是遷移過程中要注意的思想這是今天我要分享的關於自動遷移的方案的這些實踐以及注意思想如果大家有什麼疑問還有興趣點以後我們可以在線上繼續交流謝謝大家