互聯網新兵的云原生改造
日期：2023-06-16
摘要(yao)
案例(li)背景：中亦客戶——某中型互聯網公司處于快速(su)發展(zhan)階段，重度依賴公有(you)云(yun)服務(wu)，隨著業務(wu)壓力(li)增大(da)，許多產(chan)品線引入微服務(wu)，給運(yun)維帶來更高的要求(qiu)。
中亦建(jian)議：先通過改(gai)善一個產品線的(de) DevOps 過程，形成最佳實踐，建(jian)立一個 DevOps 平臺，積累專屬于該公司的(de)經驗，最終逐步推廣到整個公司。
實(shi)踐成果：整個 DevOps 平臺經過了(le)(le)可用(yong)性和性能的(de)挑戰(zhan)，截(jie)止(zhi)到項目結束，整個公司的(de)研發過程已經實(shi)現了(le)(le)云原生的(de)轉型。生產集群支撐了(le)(le) 2000+ 個 Pod ，每天 500 次(ci)以上的(de)構建。
案例詳情(qing)
中亦客(ke)戶——某中型互(hu)聯網公司正處(chu)在快(kuai)速發展(zhan)階段，短(duan)短(duan)幾(ji)年時間(jian)，研(yan)發團隊從幾(ji)十人(ren)(ren)發展(zhan)到(dao)了(le)(le)(le)超過 500 人(ren)(ren)，單(dan)一(yi)研(yan)發部門也(ye)變成了(le)(le)(le) 5 個產品線。該(gai)公司重度(du)依賴公有云(yun)服務(wu)，大多數運(yun)維工(gong)程(cheng)師技能有限，僅僅了(le)(le)(le)解阿(a)(a)(a)里(li)云(yun)的(de)一(yi)些操作。部分工(gong)程(cheng)師開始嘗試使(shi)用阿(a)(a)(a)里(li)云(yun) Kubernetes ，但并(bing)沒有足夠的(de)經驗(yan)，非常依賴阿(a)(a)(a)里(li)云(yun)提供的(de)界面。隨(sui)著業務(wu)壓力的(de)增大，許多產品線已(yi)經引入(ru)了(le)(le)(le)微服務(wu)，這也(ye)給運(yun)維帶來了(le)(le)(le)更高(gao)的(de)要求。
針(zhen)對(dui)這個(ge)(ge)局(ju)面，中(zhong)亦(yi)云原生團隊的(de)(de)認為，沒有(you)強大的(de)(de)部門墻是該公司(si)的(de)(de)一個(ge)(ge)優勢(shi)，可(ke)以先通過(guo)(guo)改善一個(ge)(ge)產(chan)品線(xian)的(de)(de) DevOps 過(guo)(guo)程，形(xing)成(cheng)最佳實踐，建立(li)一個(ge)(ge) DevOps 平臺，積(ji)累專(zhuan)屬于該公司(si)的(de)(de)經驗，最終逐(zhu)步推廣到(dao)整個(ge)(ge)公司(si)。
選擇試點(dian) DevOps 團(tuan)隊
首先，要(yao)選擇一(yi)個進行改造的產品(pin)線團隊。
L 產品線團(tuan)隊已經(jing)引入了(le)(le)微服(fu)(fu)務(wu)(wu)架構(gou)，應用(yong)拆(chai)分成了(le)(le)幾十(shi)個(ge)(ge)微服(fu)(fu)務(wu)(wu)，但應用(yong)部署還(huan)采用(yong)手動復制粘貼的方法。盡管(guan)為(wei)了(le)(le)避免(mian)進一步的復雜性，所有(you)微服(fu)(fu)務(wu)(wu)部署在同一個(ge)(ge)主機上(shang)，但每次發布，配(pei)合(he)修改配(pei)置，都要(yao)花費一個(ge)(ge)多小時，還(huan)經(jing)常出錯，排查這類(lei)問題又要(yao)花費大(da)量的時間。
而且，因為研發團(tuan)隊根據不(bu)同(tong)的(de)需求來(lai)源制(zhi)定(ding)迭代計(ji)劃(hua)，經常會出現連續幾(ji)天都有應用上線(xian)(xian)的(de)情況，讓應用發布(bu)過程更加苦不(bu)堪(kan)言。L 產品(pin)(pin)線(xian)(xian)團(tuan)隊的(de)負責(ze)人也十分認同(tong)需要(yao)改善開發和運維的(de)上線(xian)(xian)體(ti)驗。于是我們(men)的(de)改造工作決定(ding)先(xian)從(cong) L 產品(pin)(pin)線(xian)(xian)團(tuan)隊展開。
改變發布管理(li)
L 產品線(xian)團隊之前的軟件(jian)發布(bu)過程是(shi)這樣的：
可(ke)以看到(dao)團隊會根據不同的需求來源(yuan)創建項目，然后每個項目按照自己(ji)的節奏發布。每次上線，都需要反(fan)復經歷合(he)并(bing)代(dai)碼、回歸測試和應用部署等工(gong)作(zuo)。
在開源世界(jie)，以及許多(duo)成熟企(qi)業(ye)的研發(fa)(fa)(fa)過程中，已(yi)經采用了定(ding)期和按特(te)性發(fa)(fa)(fa)布的模式，即將需求(qiu)拆分(fen)成一個個可(ke)獨立(li)交(jiao)付的用戶故事，然(ran)后定(ding)期發(fa)(fa)(fa)布。
中(zhong)亦建議(yi)將上(shang)述(shu)過程改造為：
這樣(yang)，我們將同一時(shi)期的不(bu)同需求的項(xiang)目納(na)入同一個發布計劃(hua)，避(bi)免了過多的重復操作，可以降低(di)相關方(fang)的工作量。
Note
這個模式的順利實施，也需要用敏捷的方法管理(li)需求。為此(ci)，中亦團(tuan)隊引入了 Scrum 課程(cheng)，強調了敏捷方法對(dui)于(yu)整個過程(cheng)的意義。
改造(zao)研發(fa)流程
L 產品線團(tuan)隊之前的(de)研發流(liu)程(cheng)，存在著較多的(de)問題(ti)。例如(ru)，軟件并沒有版本，這(zhe)就造成了(le)上線回退非常麻(ma)煩，為(wei)此我(wo)們結合 12 factor 和現狀，設計了(le)一套標準的(de) DevOps 流(liu)程(cheng)：
這個流程需要結合持續集成和(he) Kubernetes 的(de)(de)功能，最重要的(de)(de)，也確實讓(rang)開發者的(de)(de)工(gong)(gong)作更(geng)簡(jian)單(dan)了。例如，構建(jian)(jian)工(gong)(gong)作融入到了開發者的(de)(de)日常工(gong)(gong)作中，根據(ju)預(yu)先設(she)計，當開發推送的(de)(de) Git 特定分支或打 Tag 時，就會觸發構建(jian)(jian)或集成環境的(de)(de)更(geng)新。其次，因為(wei)有一個標準(zhun)的(de)(de) Chart 發布工(gong)(gong)作，可(ke)以(yi)(yi)讓(rang)測試與生產環境的(de)(de)差異(yi)更(geng)加明晰，可(ke)以(yi)(yi)減少環境差異(yi)導(dao)致(zhi)的(de)(de)問(wen)題。
Note
這個(ge)過程涉及到了(le)敏捷方法、12 factor、DevOps 等(deng)多(duo)方面的知識，中亦團隊也進行(xing)了(le)相關的知識傳遞(di)工作(zuo)。
打造 DevOps 平臺
DevOps 平臺的(de)搭建過(guo)程更加直接，但(dan)是為了保證可維(wei)護(hu)(hu)性(xing)和擴展性(xing)，也做了許多細(xi)節設計(ji)。例(li)如，Jenkins 采(cai)用多 Agent 模(mo)式，采(cai)用 MultiBranch Pipeline，代碼(ma)中存放 Jenkinsfile 和 Dockerfile 等(deng)方法，基本上省掉(diao)了 Agent 的(de)維(wei)護(hu)(hu)。
Harbor 存(cun)放的是所有的鏡像，所以(yi)必須要實現備(bei)份和恢復。Helm Chart 存(cun)放的是我們的發布(bu)信息，所以(yi)我們也需要一個高可用的 Git 服務。
Kubernetes 是一個(ge)標(biao)準化(hua)的(de)平臺，但是各(ge)個(ge)云廠(chang)商(shang)也做了許(xu)多自己的(de)界面(mian)。因為需(xu)要對(dui)接(jie)阿里(li)云、華為云、 AWS 以(yi)(yi)及許(xu)多合作伙伴的(de)私(si)有化(hua)部署的(de) Kubernetes ，所以(yi)(yi)對(dui)于 Kubernetes 的(de)使(shi)用(yong)，盡可能(neng)采用(yong)標(biao)準的(de)方式，這避免了廠(chang)商(shang)的(de)綁定。
應用改造(zao)
微服務模式下，模塊在可觀(guan)測性(xing)上(shang)有了更(geng)高的要求，需要開發探針和 Metrics 接(jie)口。還有一些應用，沒(mei)有實現配置文件與程(cheng)序分(fen)離，也需要做相應的改造。
Note
云原生時代與(yu)傳統運維的(de)穩定性有著不同的(de)內涵，需要(yao)理解新的(de)理念，并結合 Kubernetes 的(de)功(gong)能。另一方(fang)面，為了更好地持續交付，也需要(yao)改造(zao)應(ying)用配(pei)置的(de)方(fang)式(shi)。為了讓(rang)開(kai)發(fa)對改造(zao)有更深刻(ke)的(de)認識，中亦團隊組織了《穩定性的(de)模式(shi)與(yu)反(fan)模式(shi)》、《12-factor》 、《Kubernetes 基礎(chu)》和(he)《Kubernetes 最(zui)佳(jia)實踐》等課程。
CI/CD 實(shi)施
盡管(guan) L 產品線的服(fu)務(wu)分為幾個不同(tong)的類型，但實際上并不是特別(bie)的標準(zhun)，所以選擇在模塊(kuai)源(yuan)代碼(ma)種存放(fang) Jenkinsfile 和 Dockerfile ，各個模塊(kuai)的負責人可(ke)以根(gen)據具體項目進行調整。中(zhong)亦(yi)團隊編寫了幾類模塊(kuai)的標準(zhun) Jenkinsfile 和 Dockerfile，并制定了標準(zhun)的 Jenkins Job 模板 ，研發團隊可(ke)以根(gen)據自己的情況采用。
Helm Chart 編寫
這個項目雖然是微(wei)服務架構(gou)，但是部(bu)(bu)署(shu)(shu)時，往往存在一定(ding)的(de)(de)關聯性，所(suo)以(yi)中(zhong)(zhong)亦團(tuan)隊將整個應用(yong)封裝成一個 Helm Chart，可(ke)以(yi)實現(xian)應用(yong)的(de)(de)一鍵部(bu)(bu)署(shu)(shu)。另外，也有許多細節的(de)(de)設計(ji)。比較簡單的(de)(de)諸如(ru)將一些全局配置(zhi)做成變(bian)量，復(fu)雜的(de)(de)包括當(dang)某個配置(zhi)發(fa)生變(bian)化，直接觸(chu)發(fa)相(xiang)關應用(yong)重啟的(de)(de)設計(ji)。中(zhong)(zhong)亦團(tuan)隊也將 Helm Chart 的(de)(de)調用(yong)整合到了(le) Jenkins ，這樣研發(fa)團(tuan)隊可(ke)以(yi)在界面上選擇特定(ding)的(de)(de) chart 版本(ben)，進行部(bu)(bu)署(shu)(shu)，當(dang)然也能實現(xian)回(hui)退(tui)。
可觀測性(xing)儀表盤
針對應(ying)用(yong)的(de)架構，開發相(xiang)應(ying)的(de)儀表(biao)盤(pan)，便于應(ying)用(yong)運維(wei)人員(yuan)及時(shi)發現問題(ti)。
L 產品線(xian)改造(zao)總結
開發(fa)(fa)者的(de)(de)(de)(de)工作(zuo)更(geng)輕松(song)了，這是(shi)實現(xian) DevOps 改造(zao)必須(xu)要(yao)做(zuo)到的(de)(de)(de)(de)。新的(de)(de)(de)(de)流程沒有給開發(fa)(fa)者增加任何額外的(de)(de)(de)(de)任務，可(ke)以專注于(yu)開發(fa)(fa)工作(zuo)。每一次發(fa)(fa)布(bu)更(geng)穩了，因為嚴格(ge)的(de)(de)(de)(de)區分了構建、發(fa)(fa)布(bu)和運行三個過程，我們可(ke)以清楚的(de)(de)(de)(de)知道每次發(fa)(fa)布(bu)的(de)(de)(de)(de)內容(rong)，可(ke)以輕松(song)的(de)(de)(de)(de)切換到各個版本。
另外(wai)，這個過程也徹底避免(mian)了對廠(chang)商的依賴。L 產品線團隊的產品，后來分別部署到了華(hua)為(wei)云、AWS 和幾個客(ke)戶的私(si)有 Kubernetes ，基本上(shang)實現了一個命令(ling)部署，大大提升(sheng)了客(ke)戶的滿意度(du)。
全(quan)公司推廣
中亦通過 L 產(chan)品線的 DevOps 實踐，總結出了一套適用于該互聯網公司的行之有效的流程和(he)平(ping)(ping)臺，所以(yi)下一步就是將這(zhe)些積累推(tui)廣(guang)到(dao)整個公司。在這(zhe)個過程中，又經(jing)歷許多復雜的技(ji)術棧，其中包括 Java, .NET Core, Python, Golang, .NET Framework 等，整個 DevOps 平(ping)(ping)臺經(jing)過了可(ke)用性和(he)性能的挑戰，截(jie)止到(dao)項目結束(shu)，生產(chan)集群支撐(cheng)了 2000+ 個 Pod ，每天 500 次以(yi)上的構建。
最近中亦科技還(huan)有一些新動(dong)態，讓我們快速回顧一下(xia)。
中(zhong)亦科(ke)技榮獲華(hua)為商(shang)業新銳獎
中(zhong)亦與(yu)華為(wei)的合(he)作持續多(duo)年，深入華為(wei)政(zheng)企業(ye)務，保持業(ye)績高(gao)速(su)增長。自雙方合(he)作以來，戰略定位協同(tong)，戰略資源共享(xiang)，在時代新局(ju)下共育新機(ji)，實現了價值創新和整(zheng)合(he)共贏(ying)。
表(biao)揚信+1，中亦(yi)實力再(zai)獲認可(ke)！
中(zhong)亦(yi)科(ke)技(ji)在國網(wang)(wang)湖南信通(tong)公(gong)司新一代能源互聯網(wang)(wang)營(ying)銷系統的重點(dian)保障(zhang)工作(zuo)中(zhong)，認真負責、耐(nai)心細致、高質量協助完(wan)成了(le)保障(zhang)工作(zuo)。國網(wang)(wang)湖南信通(tong)公(gong)司對中(zhong)亦(yi)科(ke)技(ji)及楊杰工程師的飽(bao)滿工作(zuo)狀態(tai)和專(zhuan)業(ye)能力表(biao)示高度認可(ke)與感謝。
中山農(nong)商行(xing)來(lai)中亦廣(guang)州分公司參觀考察(cha)
近日，中山(shan)農商行(xing)(xing)客(ke)(ke)戶(hu)來(lai)到中亦廣州(zhou)分公司(si)(si)進行(xing)(xing)參(can)觀考察(cha)，中亦廣州(zhou)分公司(si)(si)的(de)同事們向(xiang)客(ke)(ke)戶(hu)詳細介(jie)紹了(le)公司(si)(si)整體情(qing)況以(yi)及針對(dui)客(ke)(ke)戶(hu)項目是如何高效有序(xu)開展的(de)。中山(shan)農商行(xing)(xing)客(ke)(ke)戶(hu)對(dui)中亦科技與此次參(can)觀均表示(shi)高度(du)認可，并表達了(le)對(dui)未來(lai)能與中亦繼續合(he)作，助推事業(ye)提質增效的(de)期待！
