這陣子終于把公司那套亂糟糟的微服務(wù)發(fā)布流程理順了。這次聊的這套基于Docker容器和DevOps理念搭建的企業(yè)業(yè)務(wù)代碼發(fā)布系統(tǒng)算是我自己在生產(chǎn)環(huán)境里踩了無數(shù)坑之后慢慢沉淀下來的方案。標(biāo)題里雖然掛著“enterprise-microservices-deployment-practice”其實就是想講清楚一件事幾十個微服務(wù)怎么用Docker管起來、怎么讓發(fā)布變成一條自動化的流水線以及這套東西在企業(yè)真實業(yè)務(wù)里怎么落地。如果你正在搭DevOps平臺或者被多環(huán)境、多服務(wù)的發(fā)布搞得焦頭爛額這篇應(yīng)該能給你指個方向。我先說結(jié)論這套方案不是某種“開箱即用”的軟件也不是非得有多少臺機(jī)器才能跑起來的重平臺。它本質(zhì)上是一套組合拳——Docker做運(yùn)行環(huán)境標(biāo)準(zhǔn)化Harbor管鏡像GitLab CI/CD負(fù)責(zé)打通“代碼提交→鏡像構(gòu)建→遠(yuǎn)程部署”的鏈路再用Docker Compose做單機(jī)或小集群上的服務(wù)編排。服務(wù)規(guī)模在幾個到幾十個之間的時候這套組合足夠穩(wěn)等真到了需要彈性伸縮和跨機(jī)房調(diào)度的規(guī)模再平滑往K8s上遷也不遲。1. 先說背景微服務(wù)多起來之后發(fā)布就成了災(zāi)難1.1 這套發(fā)布系統(tǒng)到底解決什么問題我是在業(yè)務(wù)從單體應(yīng)用拆分成30多個微服務(wù)之后開始認(rèn)真做這件事的。拆分之前發(fā)布就是一臺上線機(jī)把war包或jar包扔上去重啟Tomcat完事。但服務(wù)一拆多問題全冒出來了。首先是環(huán)境的差異性。開發(fā)、測試、生產(chǎn)三套環(huán)境配置內(nèi)容不一樣連數(shù)據(jù)庫地址、Redis地址、注冊中心地址都要跟著改。以前靠人肉改配置文件改錯一個字段測試環(huán)境就崩一次。加上服務(wù)之間的依賴關(guān)系復(fù)雜A服務(wù)依賴B服務(wù)的接口B服務(wù)依賴C服務(wù)每次發(fā)布都像疊樂高順序錯了就全盤推倒重來。其次是手工操作步驟的不可控。早期發(fā)布靠運(yùn)維手工執(zhí)行腳本備份舊包、停服務(wù)、替換jar包、起服務(wù)、看日志。操作步驟本身不難難的是30多個服務(wù)都要來一遍而且還要保證每個服務(wù)都在正確的順序、正確的時間點(diǎn)發(fā)布。人不是機(jī)器半夜兩三點(diǎn)發(fā)布的時候特別容易漏掉某一步。這套“業(yè)務(wù)代碼發(fā)布系統(tǒng)”本質(zhì)上是把發(fā)布這件事從“手工流程”變成“標(biāo)準(zhǔn)化流水線”。代碼推送到倉庫之后剩下的構(gòu)建、打鏡像、推送鏡像、遠(yuǎn)程拉取鏡像、重啟容器、健康檢查全部由流水線自動完成。開發(fā)人員只需要點(diǎn)擊一個“發(fā)布”按鈕或者打一個Git tag系統(tǒng)就把后續(xù)工作接過去了。這樣做的直接收益有三個發(fā)布耗時從過去的一次平均20分鐘降到3分鐘左右發(fā)布失敗率明顯下降回滾變成了一條命令而不是又一輪手工操作。1.2 為什么選擇Docker DevOps這套組合而不是直接上K8s當(dāng)初做技術(shù)選型的時候團(tuán)隊內(nèi)部不是沒有爭論過要不要直接上Kubernetes。我個人的看法是在團(tuán)隊運(yùn)維能力還比較薄弱、服務(wù)規(guī)模還沒到需要大規(guī)模彈性伸縮的時候直接上K8s反而會引入一堆新的復(fù)雜度。K8s本身要維護(hù)Master節(jié)點(diǎn)、Etcd、Ingress Controller、RBAC權(quán)限還得理解Pod、Service、Deployment、Namespace這些抽象概念學(xué)習(xí)成本很高。而且K8s在企業(yè)內(nèi)部落地通常還要搭配一套完整的網(wǎng)絡(luò)插件和存儲方案。對于只有二三十個微服務(wù)、流量相對平穩(wěn)的業(yè)務(wù)來說這些復(fù)雜度完全用不上。Docker解決的恰恰是最關(guān)鍵的問題——環(huán)境一致性。本地能跑的服務(wù)容器里跑不起來不存在。開發(fā)、測試、生產(chǎn)環(huán)境用的是同一份鏡像差異只體現(xiàn)在配置和環(huán)境變量上。鏡像構(gòu)建一次到處運(yùn)行這就在源頭避免了“我本地是好的啊”這類經(jīng)典甩鍋。Docker Compose雖然看著簡陋但在單機(jī)和少量宿主機(jī)場景下非常好用。它把多個容器的啟動方式、網(wǎng)絡(luò)配置、端口映射、依賴關(guān)系寫在一個YAML文件里一條docker compose up -d就把整個服務(wù)棧拉起來。沒有K8s的負(fù)擔(dān)又能解決“一堆容器怎么統(tǒng)一管理”的問題。這套方案跑了一年多線上穩(wěn)定性很可靠。等以后服務(wù)量再翻幾倍需要彈性伸縮的時候再往K8s遷移也不遲——因為鏡像沒變Compose里的服務(wù)模型也很容易映射成Deployment。DevOps這套理念之所以要引入是因為它把開發(fā)和運(yùn)維的邊界打通了。開發(fā)者不再需要提工單求運(yùn)維幫忙部署而是自己就能把代碼發(fā)到測試環(huán)境運(yùn)維不再把時間耗在重復(fù)的執(zhí)行腳本上而是專注優(yōu)化流水線、監(jiān)控告警和穩(wěn)定性。本質(zhì)上DevOps不是某個工具而是一種協(xié)作方式。Docker和CI/CD工具只是這種協(xié)作方式的載體。2. 環(huán)境搭建三臺物理機(jī)上的容器化基座2.1 Docker CE和Compose V2的安裝細(xì)節(jié)先交代一下我這邊的基礎(chǔ)環(huán)境三臺Linux物理機(jī)統(tǒng)一用的CentOS 7.9配置大體是8核16G內(nèi)存、200G SSD數(shù)據(jù)盤。為什么要統(tǒng)一操作系統(tǒng)版本因為不同發(fā)行版的包管理器和內(nèi)核特性有差異統(tǒng)一能少踩很多坑。理論上這套方案在Ubuntu 22.04上也能跑命令換成apt就行。安裝Docker CE的步驟其實已經(jīng)非常成熟但還是有幾個細(xì)節(jié)值得單獨(dú)提醒。第一CentOS系統(tǒng)的yum源默認(rèn)不帶Docker包需要先安裝yum-utils再添加Docker官方y(tǒng)um倉庫。倉庫地址在/etc/yum.repos.d/docker-ce.repo里。設(shè)置好之后yum install docker-ce docker-ce-cli containerd.io一步到位。第二裝完之后先別急著啟動先把/etc/docker/daemon.json寫好。我給一份目前生產(chǎn)環(huán)境在用的配置每一行的作用都標(biāo)注過{ registry-mirrors: [https://你的加速地址.mirror.aliyuncs.com], data-root: /data/docker, exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 }, storage-driver: overlay2 }>sudo groupadd docker sudo usermod -aG docker $USER newgrp docker這一步對應(yīng)網(wǎng)上經(jīng)常有人問的“docker權(quán)限錯誤怎么解決”。報錯信息Got permission denied while trying to connect to the Docker daemon socket幾乎都是當(dāng)前用戶不在docker組導(dǎo)致的。改完重新登錄shell就生效。2.2 鏡像倉庫與CI/CD工具的選擇鏡像倉庫和CI/CD工具是整個發(fā)布系統(tǒng)的兩個“心臟”。鏡像倉庫負(fù)責(zé)存鏡像CI/CD工具負(fù)責(zé)把代碼流變成鏡像流。我這邊選的是Harbor GitLab CI這個組合。為什么不用Docker官方Registry因為私有化部署的企業(yè)場景Registry過于簡陋。Harbor自帶Web管理界面、鏡像復(fù)制、訪問控制配額、漏洞掃描最重要的是它支持鏡像的tag保留策略和回收機(jī)制能防止倉庫里的鏡像無限膨脹。GitLab CE安裝本身也可以直接用Docker容器跑起來官方提供了docker compose部署方式一條命令就能拉起一個帶PostgreSQL和Redis依賴的GitLab實例。至于CI/CD工具早期我糾結(jié)過Jenkins還是GitLab CI。Jenkins插件生態(tài)豐富幾乎什么場景都有現(xiàn)成插件但它的缺點(diǎn)是Pipeline定義和代碼倉庫是分離的維護(hù)成本高。GitLab CI的優(yōu)勢在于“Pipeline即代碼”——.gitlab-ci.yml文件直接放在倉庫里改代碼和改流水線一起走版本控制可追溯性完全不一樣。兩者選型做個簡單對比對比維度JenkinsGitLab CI配置存放位置集中在Jenkins服務(wù)端靠Job配置或Jenkinsfile.gitlab-ci.yml跟隨代碼倉庫天然版本可控并發(fā)構(gòu)建依賴Agent節(jié)點(diǎn)數(shù)量Runner支持Docker自動伸縮并發(fā)能力強(qiáng)學(xué)習(xí)門檻插件多功能雜新手容易迷失語法簡潔只保留必要的stages/jobs關(guān)鍵字與代碼平臺集成需要額外裝GitLab插件并配Token同一個GitLab體系權(quán)限模型復(fù)用適合場景異構(gòu)腳本多、已有維護(hù)團(tuán)隊GitLab重度用戶、DevOps流程標(biāo)準(zhǔn)化選GitLab CI還有個原因企業(yè)里代碼權(quán)限管理本來就靠GitLabCI的權(quán)限模型直接沿用下來什么人能觸發(fā)正式發(fā)布、什么人只能跑測試構(gòu)建在項目設(shè)置里就能精細(xì)控制。2.3 基礎(chǔ)網(wǎng)絡(luò)規(guī)劃與數(shù)據(jù)卷設(shè)計容器網(wǎng)絡(luò)是Docker方案里最容易被忽略、后期最頭疼的一環(huán)。我的做法是先在每臺宿主機(jī)上建一個統(tǒng)一的外部Docker網(wǎng)絡(luò)所有跨容器的通信都走這個網(wǎng)絡(luò)docker network create -d bridge ops_net業(yè)務(wù)服務(wù)在docker-compose.yml里聲明使用這個外部網(wǎng)絡(luò)。這樣即使多個Compose項目之間需要互相訪問也不需要依賴links或暴露端口直接用服務(wù)名通信即可。links在Compose V2里已經(jīng)標(biāo)記為廢棄跨項目容器互聯(lián)的唯一合理方式就是把它們拉到同一個自定義網(wǎng)絡(luò)上。數(shù)據(jù)卷設(shè)計上凡是需要持久化的數(shù)據(jù)都必須掛載宿主機(jī)的指定目錄。MySQL的數(shù)據(jù)目錄掛在/data/mysqlRedis的AOF和RDB文件掛在/data/redis統(tǒng)一規(guī)劃的好處是備份只需針對這個目錄做快照。容器本身被視為“無狀態(tài)”的隨時可以刪除重建數(shù)據(jù)留在宿主機(jī)上這是容器化運(yùn)維的基本原則。3. 微服務(wù)容器化改造從一堆Jar包到標(biāo)準(zhǔn)鏡像3.1 多階段Dockerfile怎么寫得又快又小微服務(wù)層面我這邊技術(shù)棧以Java Spring Boot為主。給Java服務(wù)寫Dockerfile最推薦的方式就是多階段構(gòu)建。多階段構(gòu)建的好處有兩點(diǎn)一是構(gòu)建環(huán)境用Maven鏡像運(yùn)行環(huán)境用JRE鏡像兩者隔離最終鏡像不包含編譯工具鏈體積能小很多二是構(gòu)建過程可以充分利用Docker層的cache單一層變化時不會讓整個build cache失效。給一份生產(chǎn)環(huán)境正在用的Dockerfile做了詳細(xì)注釋# 第一階段編譯打包 FROM maven:3.8-openjdk-11 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests -B # 第二階段運(yùn)行 FROM eclipse-temurin:11-jre WORKDIR /app COPY --frombuilder /app/target/*.jar app.jar ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone EXPOSE 8080 ENTRYPOINT [sh, -c, java -Xms512m -Xmx512m -XX:UseG1GC -jar app.jar]為什么第一階段的Maven命令要拆成兩行第一次只拷貝pom.xml然后執(zhí)行dependency:go-offline是為了讓Maven拉取依賴這一步單獨(dú)成為一個Docker緩存層。后續(xù)如果只改源碼不會觸發(fā)依賴重新拉取構(gòu)建速度會快很多。如果直接把源碼一次性拷進(jìn)去再統(tǒng)一構(gòu)建改一行代碼就要重新拉一遍所有依賴幾十個服務(wù)累計下來的時間成本非常嚇人。運(yùn)行階段用eclipse-temurin而不是老的openjdk鏡像是因為OpenJdk官方鏡像已經(jīng)停止維護(hù)ADOPTEclipse的Temurin項目是目前社區(qū)推薦的Java運(yùn)行鏡像?；A(chǔ)鏡像一定要選長期維護(hù)的這同樣是踩過坑得出的教訓(xùn)——之前用的某個鏡像因為不再更新遇到廠商的CVE通告之后根本沒法升級補(bǔ)救。-Xms512m -Xmx512m這個JVM參數(shù)組合值得單獨(dú)說。容器限制512M內(nèi)存JVM堆最大也設(shè)為512M很多人會覺得“給滿了”。但實際情況是JVM除了堆內(nèi)存還有元空間、線程棧、直接內(nèi)存等開銷。如果容器限制是1GJVM最大堆絕不要設(shè)到1G至少預(yù)留25%給非堆內(nèi)存和系統(tǒng)本身否則會被容器OOM Kill。我給一般服務(wù)定的基線是容器內(nèi)存1GJVM堆512M這個比例在實戰(zhàn)中表現(xiàn)很穩(wěn)定。3.2 依賴中間件容器化MySQL 8和Redis主從的部署坑業(yè)務(wù)服務(wù)都容器化之后中間件如果還在物理機(jī)上裸奔管理上依然不通。我這邊把MySQL 8.0、Redis主從、RocketMQ都陸續(xù)遷到了Docker里。這里只挑最容易踩坑的兩個講。MySQL 8.0容器化最需要注意的是數(shù)據(jù)目錄和初始化腳本。直接docker run命令其實夠用docker run -d \ --name mysql8 \ -e MYSQL_ROOT_PASSWORD你的密碼 \ -e TZAsia/Shanghai \ -v /data/mysql:/var/lib/mysql \ -v /data/mysql-conf:/etc/mysql/conf.d \ -p 3306:3306 \ mysql:8.0 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_bin數(shù)據(jù)卷必須掛載否則容器刪除之后MySQL數(shù)據(jù)全部丟失這是Docker化中間件的底線。第二個容易忽略的是字符集參數(shù)8.0默認(rèn)字符集雖然是utf8mb4但排序規(guī)則在某些場景下會踩索引坑顯式指定更穩(wěn)妥。還有一點(diǎn)不要用latest標(biāo)簽拉取MySQL鏡像一定要鎖定具體版本號比如mysql:8.0.36。中間件的鏡像版本不能漂移否則哪天升級了個小版本行為變化導(dǎo)致宕機(jī)再排查就晚了。Redis主從的容器化同樣要掛載數(shù)據(jù)和配置文件。先起主節(jié)點(diǎn)docker run -d \ --name redis-master \ --network ops_net \ -p 6379:6379 \ -v /data/redis/master:/data \ redis:7.0 redis-server --appendonly yes --requirepass 你的密碼再起從節(jié)點(diǎn)關(guān)鍵點(diǎn)是讓從節(jié)點(diǎn)通過Docker網(wǎng)絡(luò)內(nèi)的容器名連接主節(jié)點(diǎn)而不是寫死IP。因為主節(jié)點(diǎn)容器一旦重啟IP可能變化重新拉起從節(jié)點(diǎn)時找不到原來的IP主從關(guān)系就直接斷了。docker run -d \ --name redis-slave \ --network ops_net \ -p 6380:6379 \ -v /data/redis/slave:/data \ redis:7.0 redis-server --appendonly yes \ --slaveof redis-master 6379 \ --masterauth 你的密碼這里有個很實用的細(xì)節(jié)從節(jié)點(diǎn)端口映射到了宿主機(jī)的6380這是為了方便本地調(diào)試直連容器內(nèi)部的服務(wù)通過redis-master:6379訪問完全不用關(guān)心映射端口。Redis主從在容器環(huán)境里的坑主要就兩個一個是網(wǎng)絡(luò)模式?jīng)]選對導(dǎo)致主從間通信失敗另一個是認(rèn)證配置不一致masterauth沒配上就抓瞎。3.3 服務(wù)之間如何通信網(wǎng)絡(luò)模式與服務(wù)發(fā)現(xiàn)微服務(wù)之間通信我這邊統(tǒng)一用Nacos做注冊中心和配置中心。在Docker環(huán)境里Nacos本身也是跑在容器里的。但Nacos的服務(wù)注冊地址有個大坑如果微服務(wù)往Nacos注冊的是容器內(nèi)網(wǎng)IP橋接網(wǎng)絡(luò)分配的IP其他服務(wù)通過這個IP訪問時會發(fā)現(xiàn)根本連不通——因為另一個服務(wù)可能根本不在同一個宿主機(jī)上或者雖然在同一宿主機(jī)但容器網(wǎng)絡(luò)的IP段并不對外路由。解決思路有三種我最終采用的是最簡單的一種所有微服務(wù)在注冊到Nacos時上報的地址是宿主機(jī)IP端口用映射出來的宿主機(jī)端口。可以通過配置spring.cloud.nacos.discovery.ip宿主機(jī)IP和spring.cloud.nacos.discovery.port映射端口來顯式指定。這樣服務(wù)調(diào)用的時候走的是宿主機(jī)端口既有Nacos的注冊發(fā)現(xiàn)優(yōu)勢又不依賴Docker內(nèi)部網(wǎng)絡(luò)的可達(dá)性。等以后服務(wù)規(guī)模進(jìn)一步增長再切換到K8s環(huán)境時這個方案可以直接升級成K8s的Service或者Headless Service加DNS解析。所以現(xiàn)在雖然土一點(diǎn)但演進(jìn)路徑是清晰的不會白做。4. 發(fā)布流水線落地從git push到docker run4.1 GitLab CI的任務(wù)拆分與Runner配置流水線設(shè)計是整個發(fā)布系統(tǒng)的核心。我的設(shè)計思路是把流水線拆成三個階段構(gòu)建build、打包鏡像image、發(fā)布release。這樣拆的好處是每個階段職責(zé)單一出問題也好定位。.gitlab-ci.yml文件的關(guān)鍵部分長這樣variables: MAVEN_OPTS: -Dmaven.repo.local/cache/m2 stages: - build - image - release build: stage: build image: maven:3.8-openjdk-11 script: - mvn clean package -DskipTests artifacts: paths: - target/*.jar expire_in: 1 day only: - tags image: stage: image image: docker:20.10 services: - docker:20.10-dind script: - docker build -t registry.ops.com/enterprise/user-svc:$CI_COMMIT_TAG . - docker login -u $HARBOR_USER -p $HARBOR_PASSWORD registry.ops.com - docker push registry.ops.com/enterprise/user-svc:$CI_COMMIT_TAG only: - tags release: stage: release script: - ssh deploy目標(biāo)服務(wù)器 cd /opt/deploy/user-svc ./deploy.sh $CI_COMMIT_TAG only: - tags注意到我這里對正式發(fā)布只允許tags觸發(fā)。為什么不用分支直接發(fā)布因為分支的粒度太粗開發(fā)隨便push一個unstable的提交到develop如果自動觸發(fā)生產(chǎn)發(fā)布后果不堪設(shè)想。用git tag v1.2.3這種方式發(fā)布行為就變成一個經(jīng)過測試驗證的、有明確版本號的“正式操作”。開發(fā)環(huán)境可以用分支自動構(gòu)建生產(chǎn)環(huán)境必須打tag。Runner我選擇了shell executor而不是docker executor。原因是release階段需要訪問目標(biāo)服務(wù)器的docker socket和SSH密鑰shell執(zhí)行器在這些權(quán)限控制上更直接。代價是Runner所在機(jī)器需要預(yù)裝Docker和JDK但這些都是一次性配置可接受。4.2 遠(yuǎn)程服務(wù)器上的滾動發(fā)布與健康檢查release階段通過ssh deploy目標(biāo)服務(wù)器執(zhí)行deploy.sh這是整個發(fā)布動作的關(guān)鍵一步。deploy.sh腳本的設(shè)計決定了發(fā)布是優(yōu)雅還是粗暴。我的腳本里強(qiáng)制做了三件事拉取新鏡像、用Compose重啟、健康檢查不通過就報錯。#!/bin/bash set -e APP_NAMEuser-svc IMAGE_TAG$1 BASE_DIR/opt/deploy/$APP_NAME cd $BASE_DIR docker compose down --remove-orphans || true docker pull registry.ops.com/enterprise/$APP_NAME:$IMAGE_TAG docker compose up -d for i in $(seq 1 30); do code$(curl -s -o /dev/null -w %{http_code} http://127.0.0.1:8080/actuator/health) if [ $code 200 ]; then echo 服務(wù)啟動成功health check通過 exit 0 fi echo 等待服務(wù)啟動... $i/30 sleep 2 done echo 健康檢查失敗發(fā)布不通過 exit 1set -e保證任何一步出錯腳本立刻終止避免帶著殘缺狀態(tài)繼續(xù)往下走。docker compose down --remove-orphans是為了把舊的容器實例和孤兒容器一并清掉確保容器名不會沖突。docker compose up -d重新以新鏡像啟動服務(wù)容器名保持不變外部依賴的端口映射也不會變更。健康檢查是這套方案里我認(rèn)為最重要的一環(huán)。為什么不只是看docker ps -q是否返回容器ID因為容器進(jìn)程雖然在不代表業(yè)務(wù)已經(jīng)準(zhǔn)備好了——Spring Boot啟動一個服務(wù)可能持續(xù)二三十秒如果這時候Nginx就把流量導(dǎo)進(jìn)來用戶看到的一定是502。網(wǎng)上很多微服務(wù)發(fā)布方案沒有健康檢查這一步等于賭博。我這里用Spring Boot Actuator的/actuator/health接口做探針30次循環(huán)每隔2秒探一次最多等60秒。超過60秒沒通過就直接fail流水線會打出紅叉。這個機(jī)制上線后成功攔截過好幾次鏡像配置錯誤導(dǎo)致的啟動失敗。4.3 版本回滾與多環(huán)境隔離怎么做Docker鏡像的tag天然就是版本所以回滾變得異常簡單。我發(fā)現(xiàn)新版本有Bug想回滾到上一個版本只需要重新執(zhí)行一次舊的發(fā)布cd /opt/deploy/user-svc docker compose down docker pull registry.ops.com/enterprise/user-svc:v1.2.2 docker compose up -d舊鏡像的tagv1.2.2還在Harbor里pull下來直接跑通。整個回滾動作在1-2分鐘之內(nèi)完成相比過去手工替換jar包、重啟、盯著日志看十分鐘這個體驗是完全不一樣的。多環(huán)境隔離方面我采取的策略是一個環(huán)境一套Compose運(yùn)行目錄通過環(huán)境變量文件區(qū)分配置。比如/opt/deploy/user-svc/.env.test和/opt/deploy/user-svc/.env.prodCompose文件里用${SPRING_PROFILES_ACTIVE}這樣的變量占位具體值由環(huán)境文件注入。發(fā)布腳本針對不同環(huán)境傳不同的參數(shù)./deploy.sh user-svc v1.2.3 test ./deploy.sh user-svc v1.2.3 prod這樣做的好處是整個Compose編排文件只有一份不會因為環(huán)境不同而維護(hù)出多個副本。差異點(diǎn)全部收斂到環(huán)境變量里任何一個環(huán)境的配置變更都能在git里看到歷史記錄。5. 生產(chǎn)環(huán)境踩坑實錄與排查方法5.1 Docker服務(wù)起不來的幾個高頻原因這套方案跑了一年多生產(chǎn)環(huán)境里Docker本身出過的問題不算多但一旦出了問題就是大事。我列一下出現(xiàn)頻率最高的幾個以及我的排查順序?！癲ocker服務(wù)啟動失敗”這個現(xiàn)象在安裝初期最容易遇到。比如我遇到過systemctl start docker報Job for docker.service failed because the control process exited with error code。第一反應(yīng)應(yīng)該是journalctl -xu docker.service看日志而不是反復(fù)重啟。造成這個報錯最常見的原因有三個一是daemon.json寫壞了JSON格式不對Docker進(jìn)程一啟動就解析失敗退出二是>environment: - TZAsia/Shanghai同時掛載宿主機(jī)的localtime文件。Compose文件里統(tǒng)一寫volumes: - /etc/localtime:/etc/localtime:roJava服務(wù)的JVM本身會讀取user.timezone和系統(tǒng)時區(qū)這兩項設(shè)置好之后無論是Spring Boot的日志時間還是new Date()輸出的時間都會恢復(fù)正常。5.3 鏡像構(gòu)建慢、鏡像運(yùn)行內(nèi)存溢出怎么辦鏡像構(gòu)建慢分兩個層面看。一個是網(wǎng)絡(luò)層面基礎(chǔ)鏡像和Maven依賴都要從外網(wǎng)拉取國內(nèi)網(wǎng)絡(luò)環(huán)境有時候很不穩(wěn)定。解決辦法有兩個Docker的daemon.json里面配置鏡像加速器我在前面已經(jīng)寫過了Maven依賴則用本地私服Nexus把中央倉庫的依賴全部代理到內(nèi)網(wǎng)這樣構(gòu)建階段就不再依賴公網(wǎng)。第二個層面是緩存利用不充分構(gòu)建過程中反復(fù)拉取同一份依賴。最好的解決辦法就是我在Dockerfile里寫的那個緩存技巧先單獨(dú)COPY pom.xml并執(zhí)行dependency:go-offline讓依賴層穩(wěn)定落在Docker cache里。容器運(yùn)行內(nèi)存溢出這是Java服務(wù)容器化后比較常見的“隱形殺手”。表面看容器運(yùn)行正常日志里也沒有OutOfMemoryError但服務(wù)突然無響應(yīng)。這時候docker inspect看狀態(tài)往往會發(fā)現(xiàn)容器處于Exited狀態(tài)查看docker inspect 容器名 -f {{.State.OOMKilled}}返回true。說明容器被內(nèi)核OOM Killer殺掉而不是JVM自己拋異常退出。這種情況基本就是容器內(nèi)存限制設(shè)置得太緊或者JVM堆參數(shù)分配不合理。我調(diào)整參數(shù)的思路是先給容器內(nèi)存1G起步JVM堆內(nèi)存在512M觀察一段時間docker stats的輸出。如果實際內(nèi)存峰值在700M-800M且穩(wěn)定說明容器內(nèi)存正好如果經(jīng)常800M以上就適當(dāng)放寬JVM堆或容器內(nèi)存。實際部署中業(yè)務(wù)高峰期內(nèi)存容易緩慢爬升建議給足15%-20%的余量別卡得太死。5.4 日志與監(jiān)控的落地建議容器化之后日志收集方式也變了。默認(rèn)的docker logs只適合調(diào)試時看生產(chǎn)環(huán)境里幾十個服務(wù)分布在三臺機(jī)器上用docker logs一個個翻實在低效。我這邊目前的處理方式是每個容器統(tǒng)一把日志寫到掛載的宿主機(jī)目錄比如/opt/logs/服務(wù)名然后一臺日志服務(wù)器上用Filebeat采集推給ElasticsearchKibana做檢索和可視化。這套EFK方案相比直接裝一堆日志采集插件靈活度更高也不侵入業(yè)務(wù)代碼。容器的資源監(jiān)控我先用的還是docker stats配合宿主機(jī)的基礎(chǔ)監(jiān)控系統(tǒng)。docker stats的問題是不能持久化和報警所以我又加了cAdvisor來采集容器級指標(biāo)然后輸出到Prometheus再用Grafana展示。這三個工具都是容器化直接可以跑的配置比較簡單但對排查線上問題幫助非常大。有一次線上某個服務(wù)CPU飆高就是通過Grafana上容器CPU曲線和發(fā)布記錄的對應(yīng)關(guān)系快速定位到是某個新版本代碼引入了死循環(huán)然后果斷回滾。還有一個細(xì)節(jié)所有發(fā)布動作盡量安排在低峰期并且每次發(fā)布只動一個服務(wù)不要批量并發(fā)發(fā)布多個服務(wù)。因為微服務(wù)之間有調(diào)用關(guān)系同時發(fā)布多個服務(wù)風(fēng)險疊加出了問題連排查基準(zhǔn)都沒有。我吃過一次虧同時發(fā)布了三個服務(wù)結(jié)果線上報錯根本分不清是哪個服務(wù)引入的回歸。后來定了規(guī)矩一次只發(fā)布一個服務(wù)等健康檢查通過之后再發(fā)下一個。這個規(guī)矩雖然保守但在企業(yè)環(huán)境里穩(wěn)定壓倒一切。最后再說幾句個人經(jīng)驗。這套基于Docker和DevOps的發(fā)布系統(tǒng)真正難的不是某個具體技術(shù)點(diǎn)而是“習(xí)慣”的養(yǎng)成。開發(fā)人員要接受用tag發(fā)布、要主動看流水線日志、要在PR描述里寫清楚變更內(nèi)容運(yùn)維要接受從手工操作轉(zhuǎn)為寫腳本和排查平臺問題。我把這套流程跑通之后業(yè)務(wù)方最大的感受是“發(fā)布變快了”但只有團(tuán)隊內(nèi)部知道這份快是建立在一層一層的檢查和約束之上的。如果你也在企業(yè)里搭發(fā)布系統(tǒng)我建議別想著一步到位先把一個服務(wù)從代碼提交到健康檢查跑通整個閉環(huán)再橫向鋪開。等技術(shù)成熟了再上K8s就是水到渠成的事。