从本地Docker到华为云CCE：一个Spring Boot应用的完整上云迁移实战（含GitHub Actions自动化）

从本地Docker到华为云CCESpring Boot应用迁移实战与自动化演进当我们在本地开发环境用Docker跑Spring Boot应用时一切看起来都很美好——直到需要把这个小可爱搬到生产环境。去年我负责的一个电商促销系统就经历了这样的蜕变从开发机的Docker Compose到华为云CCE的完整迁移。这中间踩过的坑、省下的时间今天就用实战经验告诉你如何优雅完成这场云上搬家。1. 迁移前的全景规划迁移不是简单的复制粘贴。我们团队最初低估了环境差异带来的影响结果在第一次试运行时遭遇了数据库连接池爆满的灾难。后来总结出三个必须提前验证的维度基础设施差异矩阵本地vs云端:对比项本地Docker环境华为云CCE环境网络拓扑桥接/NAT模式VPC安全组ELB存储持久化本地volume云硬盘/EIP服务发现手动配置hosts内部DNSService Mesh监控体系Docker statsAOMAPM全链路监控镜像仓库的生死时速本地构建的镜像直接docker run的日子结束了。我们为镜像仓库设计了双保险策略# 镜像同步脚本示例华为云SWR为主仓库 docker pull local-registry:5000/order-service:v1.2 docker tag local-registry:5000/order-service:v1.2 swr.cn-north-4.myhuaweicloud.com/prod/order-service:v1.2 docker push swr.cn-north-4.myhuaweicloud.com/prod/order-service:v1.2配置管理的成人礼从硬编码的application.yml到云原生的配置中心我们用了三阶段演进环境变量注入初期ConfigMap挂载中期Nacos配置中心当前关键教训在预生产环境完整模拟一次全链路部署包括压测和故障注入。我们当时漏测了云数据库连接数限制导致上线当天订单服务雪崩。2. CCE部署的进阶姿势华为云CCE的控制台向导适合新手但真实企业部署需要更工程化的方法。这是我们打磨出来的最佳实践2.1 声明式部署模板优化原始的deployment.yaml需要强化这些要素apiVersion: apps/v1 kind: Deployment metadata: annotations: # 华为云特有注解 cce.io/elastic-resources: true spec: strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 0 # 确保零停机更新 template: spec: affinity: podAntiAffinity: # 避免单节点故障 preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: [order-service] topologyKey: kubernetes.io/hostname containers: - livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 failureThreshold: 3 periodSeconds: 15 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 20 # Spring Boot启动较慢2.2 服务暴露的智能选择根据流量特征选择最佳暴露方案IngressHTTP/HTTPS流量推荐Nginx Ingress ControllerapiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/affinity: cookie spec: rules: - host: orders.example.com http: paths: - path: / pathType: Prefix backend: service: name: order-service port: number: 80LoadBalancer直接暴露TCP服务如gRPCNodePortEIP测试环境临时方案3. GitHub Actions流水线精要我们的CI/CD流水线经历了三次迭代最终定型为这个高效版本name: Production Deployment Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] env: REGISTRY: swr.cn-north-4.myhuaweicloud.com REPOSITORY: ${{ secrets.HW_NAMESPACE }}/order-service jobs: build-test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Cache Maven packages uses: actions/cachev3 with: path: ~/.m2 key: ${{ runner.os }}-m2-${{ hashFiles(**/pom.xml) }} - name: Build with Maven run: mvn -B package -DskipTests - name: Run Unit Tests run: mvn test deploy-staging: needs: build-test runs-on: ubuntu-latest environment: staging steps: - uses: actions/checkoutv3 - name: Configure Kubeconfig run: | mkdir -p ~/.kube echo ${{ secrets.HW_CCE_KUBECONFIG }} ~/.kube/config - name: Canary Deployment run: | kubectl set image deployment/order-service-canary \ order-service${{ env.REGISTRY }}/${{ env.REPOSITORY }}:${{ github.sha }} - name: Run Integration Tests run: | ./run-smoke-tests.sh staging-api.example.com deploy-prod: needs: deploy-staging runs-on: ubuntu-latest environment: production steps: - uses: actions/checkoutv3 - name: Configure Kubeconfig run: | mkdir -p ~/.kube echo ${{ secrets.HW_CCE_KUBECONFIG_PROD }} ~/.kube/config - name: Blue-Green Deployment run: | kubectl apply -f k8s/prod/order-service-blue.yaml kubectl rollout status deployment/order-service-blue # 流量切换逻辑 ./switch-traffic.sh blue green这个流水线的精妙之处在于分层验证单元测试→集成测试→生产部署渐进式发布Canary→Blue/Green密钥管理所有敏感信息通过GitHub Secrets管理4. 监控与自愈体系构建上云不是终点而是运维智能化的起点。我们配置的监控体系包括基础指标监控华为云AOM容器CPU/Memory阈值告警JVM堆内存监控线程池活跃度监控业务指标监控自定义Prometheus// Spring Boot中暴露自定义指标 Bean MeterRegistryCustomizerMeterRegistry orderMetrics() { return registry - { Gauge.builder(order.queue.size, orderQueue, Collection::size) .tag(region, cn-north-4) .register(registry); }; }日志分析黄金三法则必须结构化日志JSON格式必须包含追踪IDSpring Cloud Sleuth关键路径必须有耗时日志# 华为云LTS日志采集配置示例 kubectl logs -f order-service-7d5ffc5bc6-2zqkx \ | grep -E ERROR|WARN \ | jq . | {traceId: .traceId, spanId: .spanId, timestamp: .timestamp, message: .message}迁移半年后我们的系统可用性从99.2%提升到99.95%部署时间从原来的2小时缩短到7分钟。最惊喜的是某个周五晚上自动扩缩容机制在流量暴涨时自动增加了3个Pod实例而运维团队周一上班才从告警记录发现这次隐形救火。