云效合作上海博卡：DevOps轉型之路

774次閱讀

(1)客戶介紹

博卡軟件于2004年在上海成立，是一家專注于為本地美麗生活相關行業提供軟件服務的SaaS軟件提供商。主要產品是門店運營所需要的，管理軟件，智能硬件以及營銷小程序等。

作為一個不足30人的研發團隊,并且沒有真正專職的運維人員，面對快速增長的客戶以及越來越多的需求，擁有20多個微服務，幾十個前端應用（web，小程序，app等），傳統的開發和部署的方式已經逐漸成為了我們研發團隊的瓶頸,為了能高效的完成交付，我們開始了DevOps轉型之路。

因為我們的SaaS應用完全部署在阿里云上，通過一個偶然的機會接觸到云效后，我們開始了使用云效+阿里云ACK替代我們現有的Gitlab+Jenkins+ECS的CI/CD來實現DevOps。

(2)項目背景

因為我們服務的客戶都是小商戶為主，通常有需求或者遇到問題都不愿意等待一周或者幾天時間,大多數時候都需要我們快速解決，并且因為我們客戶量比較大，使得我們必須快速反應，做到持續交付，交付周期可能是一天一次，甚至一天幾次。

(3)解決方案

源碼管理

在對比了經典的Git Flow,Github Flow,以及Gitlab Flow之后,我們最終選擇了更適合我們團隊的Gitlab Flow來作為我們的Git工作流。

每個代碼庫的master分支通過webhook觸發綁定測試環境的流水線構建，release分支綁定生產環境的流水線構建。同時設置master分支和release分支的保護規則，除了管理員外開發者不能直接push到master分支，需要通過評審后才能合并到master分支并觸發測試環境構建，release分支只能通過合并請求的方式來push代碼觸發構建。

云效的代碼管理Codeup的內置評審功能，能高效的完成Code Review。

內置的代碼檢測開箱即用，促進編碼規范執行。

流水線

通過Flow流水線可以很簡單的實現持續交付。Flow流水線比起Jenkins來最大的好處就是簡單易用。

支持Ram子賬號權限管理，可以統一賬號體系，不用獨立管理賬號體系。在沒有專門運維人員的情況下，針對不同的開發人員配置不同權限，可以方便安全的讓所有開發人員去看構建失敗原因，控制只有管理員或者指定人員觸發人工卡點等各種操作，安全使用流水線。

內置多種語言的流水線模板，基本上主流的CI/CD模式都可以開箱即用。并且通過通用變量組可以配置不同環境的變量組來區別不同環境的集成和部署。

測試環境或生產環境通過通用變量組以及鏡像名前綴區分

生產環境可以增加人工卡點提前構建生成鏡像，再選擇合適的時間通過卡點以控制發布時間，或者實現了零停機部署的話可以直接部署。

單頁面前端項目流水線則簡單不少，只需要編寫npm腳本，實現webpack打包并生成html產物，然后自動上傳靜態資源到cdn，最后把html產物上傳到oss中，即可完成。

容器化部署

阿里云上最優選擇

部署的最佳選擇，自然是Flow流水線的最佳搭檔ACK。容器服務Kubernetes版（ACK）是簡化了集群的搭建和擴容等工作，整合了阿里云虛擬化、存儲、網絡和安全能力，開箱即用的阿里云上最佳Kubernetes 容器化應用運行環境。其最大的優勢就是低門檻，上手簡單，運維簡單。對于我們這種沒有真正專職的運維人員的團隊來說，是一大福音。因為Kubernetes本身較高的學習成本，一開始直接勸退了我們這種小團隊。直到后面看到阿里云ACK后，因其免費使用，我們抱著試一試的心態嘗試了一下，短時間就完成了demo的部署。已過一系列的測試和嘗試后，我們決定把我們當時部署在ECS上的整套微服務，在ACK上通過Flow流水線部署一套克隆環境，最后通過Ingress的灰度能力逐步把流量切換到ACK上，順利完成了ECS上自建的Tengine + Spring Cloud微服務應用的零停機的無縫遷移。上線ACK后，我們切實感受到了Kubernetes的強大。自動化的運維，包括自動故障遷移，自動資源調度，環境隔離，動態存儲，負載均衡，零停機部署，自動擴容，以及故障時自動重啟等各種強大的功能。通過簡單配置甚至默認配置，即可享受這些功能。使用ACK后，我們的最大收益，主要是以下3點。

節約成本。因為我們使用的微服務架構，有較多的微服務，部署的時候都做高可用，一個服務至少2個實例來做負載均衡。在使用ACK之前，主要是自己來根據經驗等預判一個服務需要的cpu資源和內存資源，然后通過cgroup限制單個實例的cpu使用上限，并且通過jvm的配置來限制最大內存使用。按照這種方式來決定一臺ECS可以部署多少實例。且不說手動配置cgroup有一定的運維知識，自行規劃一般比較難做到非常高的資源利用率，而且如果有的實例發生問題甚至可能影響整個ECS上的其他應用。使用ACK的話，可以直接配置每個Pod的cpu和內存資源需求，然后交由Kubernetes來自己調度，配合上HPA的動態擴容，可以做到資源的極致利用，同時也保證了應用的穩定性，使得硬件成本大幅下降的同時也沒有犧牲穩定性。

故障自動重啟。通過Pod的健康監測和就緒監測，再加上應用暴露一個健康監測接口（比如SpringBoot的Actuator的health）即可簡單實現故障自動重啟，在應用初期問題較多的時候，或者發生突發問題的時候，自動重啟大多數都能立馬緩解問題，雖然不能根本解決，但是至少解決了小公司沒有24*7快速響應運維人員的問題，可以做到自動化最高效的緩解問題。

自動擴容。如果某些應用可能出現某個時間點非常高的流量或者應用突然需要很大的計算量，可以直接配置HPA自動擴容，設置規則后Kubernetes會根據條件自動擴容以保證應用的穩定性。

回滾

小團隊持續交付，頻繁發布，自然更容易出現問題，所以這就意味著我們需要時刻準備著滾回到上一個版本，或者說之前某一次更可靠的版本。通過Flow流水線可以回滾基本上所有部署方式。如果選擇了阿里云ACK這種Flow的最佳搭檔，則可以實現快速零停機回滾任意版本（通過健康監測以及重啟策略確保啟動的容器必然是可運行版本，如果出現無法啟動或者啟動異常的版本，則因為就緒監測無法通過是無法接收流量的，所以可以完成零停機或回滾），并且因為ACK是基于Docker鏡像的升級，回滾的版本不會出現環境變化等各種其他因素造成的意外導致回滾失敗。

效果

使用云效+ACK后的明顯帶來了以下提升:


對比內容	使用云效前	使用云效后
發布時長	10分鐘	3分鐘
代碼評審	很少	合并主分支強制要求
構建通知	不通知	自動釘釘通知
版本回滾時長	1小時	3分鐘
日常和生產環境區分	代碼中配置文件區分,存在開發人員誤修改影響部署環境配置的風險	自動注入環境變量來區分,最大程度防止代碼庫的配置文件影響部署環境配置
代碼掃描	IDE中插件自己掃描,比較隨意	提交后自動掃描,清晰提示掃描結果
定時部署	人工等待到時間進行操作	設置定時發布
交付質量	依靠開發人員個人水平以及隨機檢查保證	通過各種檢測插件進行質量檢測,阻止異常構建或者部署


	使用ACK前	使用ACK后
零停機部署	不支持	支持
應用異常自動修復	不支持	支持
擴容耗時	1小時	1分鐘
擴容方式	手動修改nginx配置	自動擴容
敏感信息安全	代碼庫保存,存在泄露風險服務器配置文件,管理成本高以及有丟失風險不容易復用	配置項,以及保密字典存儲,簡單復用以及保密性高,不容易暴露
新應用部署	半天	10分鐘
生產環境穩定性	出現問題客戶發現或者監控發現后,手動回滾再修復問題重新發布,影響時間長	通過健康監測等手段阻止異常容器接收流量,以保證線上應用的基本質量