微服务架构下CI/CD落地实践与实施方案

时间：2026-08-21 16:00

本文整理自云原生应用最佳实践杭州站活动演讲内容。杭州站特别邀请了 Apache APISIX 项目 VP 温铭、又拍云平台开发部高级工程师莫红波、蚂蚁金服技术专家王发康、有赞中间件开发工程师张超，共同分享云原生技术落地与应用实践经验。以下内容为莫红波带来的《微服务架构下 CI CD 如何落地》主题分

本文整理自云原生应用最佳实践杭州站活动演讲内容。杭州站特别邀请了 Apache APISIX 项目 VP 温铭、又拍云平台开发部高级工程师莫红波、蚂蚁金服技术专家王发康、有赞中间件开发工程师张超，共同分享云原生技术落地与应用实践经验。以下内容为莫红波带来的《微服务架构下 CI/CD 如何落地》主题分享。

莫红波，又拍云平台开发部高级工程师，目前主要专注于容器技术与虚拟化技术在又拍云私有云场景中的实践，负责又拍云容器云平台的设计与研发工作。

大家好，今天分享的主题是《微服务架构下 CI/CD 如何落地》。本次内容主要围绕以下两个部分展开：

理论篇：分析系统从单体架构演进到微服务架构时会遇到哪些挑战，以及微服务测试模型应该如何设计
实践篇：重点讲解集成测试环境中的服务发现如何实现，以及持续集成、持续交付、持续部署如何真正落地

背景

很多人对互联网公司的印象可能首先是 996，但对我个人来说，互联网公司还有一个非常突出的特点，就是必须持续适应变化。新产品上线、旧功能下线、业务需求调整，都是互联网业务中非常常见的事情。在这种背景下，一套具备良好松耦合能力的系统架构就显得尤为关键。

我最近正好也遇到了类似问题。我参与的项目中，账号体系原本是参考 GitHub 的注册制账号模式设计的。最初需求是：用户注册平台后，可以创建自己的团队，并邀请其他成员加入团队。但当这部分功能开发完成后，我们发现客户更偏向“主账号+子账号”的模式，也就是企业拥有一个总账号，员工通过独立子账号进行关联和使用。这样一来，已经完成的设计就会变得比较被动，项目必须快速响应新的业务需求并完成调整。这时我就更加深刻地意识到，拥有一套松耦合、可扩展的架构有多么重要。比如账号能力，如果能够被单独抽离，做好清晰的抽象，并提供标准化的对外接口，那么后续无论是扩展还是改造，都会更加灵活。

**那怎样才能拥有一套松耦合的架构呢？有哪些成熟方案？其实主要有两个方向：一个是几年前就已经比较成熟的 SOA，它通过将服务拆分独立化来实现解耦；另一个则是近几年非常热门的微服务架构。**从本质上看，微服务与 SOA 的核心理念是一致的，都是通过服务拆分提升系统灵活性，只不过微服务的拆分粒度更细，单个服务职责更聚焦。

在调研微服务架构的过程中，很多人都会提出一个问题：“我们团队规模很小，小团队到底适不适合做微服务？”因为一旦采用微服务，一个原本单体应用可能会被拆分成 10 个、20 个甚至更多服务，这就意味着测试、部署、发布、维护等成本有可能成倍增加。

那么，我对“小团队是否适合上微服务”这个问题的答案是什么呢？我认为完全可以，只是有一个前提：一定要把自动化能力建设好。凡是可以交给自动化完成的工作，就尽量不要依赖人工操作。

在正式讲如何做好自动化持续集成（CI）之前，我想先和大家聊一聊，系统是如何从单体架构演进到微服务架构的，服务该怎么拆分，以及微服务测试通常应该怎么做。

从单体到微服务

如上图所示，左边是一个典型的单体应用，右边则是拆分之后的微服务架构。通过对比可以看到，微服务通常具备以下 4 个典型特征：

按照不同业务领域进行拆分
服务之间通过网络协议进行通信
每个服务拥有相对独立的数据库
对外提供明确且固定的服务接口

大家都知道，要想让一个服务稳定运行，测试是不可或缺的一环。就像微服务架构本身有一整套方法论一样，微服务测试也有自己的测试金字塔模型：最底层是单元测试，成本最低、执行效率最高。例如我们在 API 认证模块中做的签名校验功能，通常不依赖其他外部组件，因此非常适合做单元测试。第二层是集成测试，这一层需要依赖第三方服务或基础组件，比如数据库相关测试，就属于典型的集成测试。第三层是 e2e 测试，也就是端到端测试，它会模拟真实客户端行为来验证整个系统流程。很多人应该都接触过这类测试，例如 Kubernetes 就有官方的 e2e 测试，如果你要申请 CNCF 一致性认证，就需要通过这套测试。最上层是 UI 测试，比如页面点击、交互跳转是否符合预期。这部分我们目前做得还相对较弱，仍然有一些人工测试环节，但也在逐步向自动化测试演进。

从微服务测试金字塔可以看出，越接近底层，测试成本越低，实现方式也越简单，可能只需要少量代码就可以完成，而且执行效率也非常高。同时，越底层对外部三方服务和组件的依赖越少，自动化实现难度自然也越低。讲到这里，可能就有人会问：“既然单元测试成本最低，那我们是不是只做单元测试就够了？”在回答这个问题之前，大家先看下面这张图。

图中的两扇窗户，单独存在时看起来都没有问题，开合也都正常；但是当它们同时安装到同一面墙上之后，却无法正常开合。这正是为什么我们不能只做单元测试的原因。只做单元测试，很多服务之间协作产生的问题是无法被发现的；同样，如果不做单元测试，也会遗漏掉某些底层逻辑错误。所以在微服务测试实践中，单元测试和集成测试都非常重要，缺一不可。

那么在实际落地时应该怎么做？我建议大家分两步推进：

第一步，先把基础打牢：为你的微服务补齐单元测试，编写完善的测试用例，再进一步强化集成测试。没有扎实测试基础的微服务体系并不可靠，任何环节都有可能在未来暴露问题，而且一旦出问题，排查成本往往很高。
第二步，建设自动化持续集成环境：把所有可以自动化处理的流程尽量自动化，从而减少人工介入，提高交付效率和稳定性。

GitLab/CI

在自动化持续集成这部分，目前已经有很多成熟的开源解决方案，比如常见的 Jenkins，以及 GitLab。我们的选择是 GitLab，更准确地说是 GitLab/CI。选择它的原因主要有以下几点：

提供统一的 Web 管理界面
可以直接在 MR 中跳转查看相关流程
Pipeline 编排展示清晰直观
所有操作都可以在项目内部完成
具备 GitLab 官方支持，生态更完整

GitLab WorkFlow

既然我们选择了 GitLab，那么团队内部也会严格遵循 GitLab 的 WorkFlow。整个 WorkFlow 主要可以分为两个部分。

第一部分是代码仓库管理。通常情况下，我们会维护几类分支。第一类是 master 分支，一般只有一个，用来承载线上正式发布版本。第二类是 develop 分支，通常也是唯一的，它从 master 分支派生出来，功能上会比 master 更领先，主要包含已经开发完成但尚未正式发布的功能。第三类是 feature 分支，也就是特性分支，数量通常较多，新功能开发一般都在 feature 分支上进行，通常一个功能对应一个 feature 分支。最后一类是 hotfix 分支，这类分支也很常见。当线上版本发布后，如果发现了需要紧急修复的 bug，就可以从 master 分支切出一个 hotfix 分支进行修复。但这里需要特别注意，修复完成后的 commit 不仅要合并回 master，也必须同步合并到 develop，否则这个 bug 修复流程不能算真正完成。

第二部分与 CI/CD 流程直接相关。以我们的研发流程为例，开发同学将代码提交到 GitLab 仓库后，GitLab 会自动触发预先定义好的 CI Pipeline，执行测试与构建任务。待测试和构建全部成功后，再进入 code review 环节；确认没有问题后，代码会被合并到 develop 分支，并最终合并到 master 分支进行版本发布。这就是 GitLab CI 的整体配置思路，总结起来可以划分为下图中的四个阶段。

下图展示的是配置文件对应的 Pipeline 效果，大家可以参考理解整个持续集成流程。

微服务下的场景变形

其实到目前为止，这套方案已经算是微服务尚未全面流行之前比较完整的 CI/CD 实践方案了。但如果你希望把它真正应用到微服务架构下的集成测试场景中，还需要根据实际情况做一些“变形”。下面这张图展示的，就是又拍云当前使用的一整套微服务 CI/CD 流程。

从图中可以看到，我们目前采用的这套流程，与标准方案相比做了一些针对性的调整。变化主要集中在中间的集成测试环境部分：我们把各个服务都部署到了集成环境中，使整个集成环境更接近一个“准发布环境”。具体流程是这样的：当我们创建 projectA 后，由项目 push 代码，提交完成后触发 CI，也就是在 GitLab Runner 上执行测试流程。

在测试运行过程中，由于 A 服务需要依赖 B 服务和 C 服务，因此它会通过 API 去请求集成测试环境中的对应服务实例。如果测试全部通过，就会把代码合并到主线。之后再通过在 master 分支打 tag 的方式，触发容器镜像构建，并将镜像推送到 Harbor 镜像仓库。最后，再执行线上 release。这就是我们当前大致的微服务持续集成与持续交付流程。

接下来，我们重点看一下这些“场景变形”在实践中会遇到的具体问题。

服务发现

在微服务场景下做 CI/CD 改造时，我们遇到了不少挑战，其中我认为最值得重点关注的，就是“服务发现”。比如有这样一个典型场景：A 服务在执行测试时，需要依赖 B 服务和 C 服务。在没有引入 Kubernetes 之前，我们的做法可能是准备一台公共机器，把相关服务都部署到这台机器上，并在测试代码里把 IP 地址写死，让所有测试都在这个固定环境中执行。但这种做法会带来以下四个非常明显的问题：

服务更新存在延迟
测试环境权限容易混乱
人工操作步骤多，出错概率高
整体维护成本过高

因此，我们最终引入了 Kubernetes Service 方案来解决这个问题。

Kubernetes Service 的流程大家可以大致了解一下。我们首先定义一个 Service，这里创建的是 ClusterIP 类型，暴露端口为 8000，目标端口也是 8000，协议为 TCP，标签选择器设置为 app=holdon。通过这样的方式，就可以把一组具备相同功能的服务实例统一绑定到同一个 Service 下面。在 Kubernetes 集群内部，只要定义好了 Service，系统就会自动提供内部 DNS 解析能力，开发和测试人员可以通过一个固定域名访问指定 Service。这样一来，在执行自动化测试时，就可以直接通过域名加端口访问对应服务，而不需要再手动维护 IP 地址，这对微服务测试环境的稳定性和可维护性提升非常明显。

持续交付

持续交付（英语：Continuous Delivery，缩写为 CD）。对于每一个项目，我们都会要求提供一个 Dockerfile，用来定义服务运行所需的基础环境以及对应的软件包。当需要发版时，我们会在主线上打一个 tag，以此触发镜像构建流程，然后将构建好的镜像推送到 Harbor 镜像仓库。同时，这个 tag 也会与镜像版本号建立对应关系，方便后续追踪和回滚。

上图展示的是我们的持续交付流程，大家可以参考一下。这里特别补充一点，我们之所以引入 Harbor，而不是直接使用官方 Registry，主要是因为 Harbor 在企业内部使用场景下更加安全。很多人都知道，官方 Registry 本身默认并不具备完善的权限校验能力，如果公司内部直接共用，可能会出现镜像被其他团队或其他部门误覆盖的风险。所以我们引入了 Harbor 来做权限隔离。当然，这里仍然存在一个问题：如果使用相同 tag 反复推送，镜像还是有可能被覆盖。但至少在团队与团队、部门与部门之间，实现了更好的隔离和管理。

持续部署

持续部署（英语：Continuous deployment，缩写为 CD）。目前在这部分实践中，我们主要先落地在集成测试环境，线上环境的更新仍然按照常规发布流程进行。具体做法是，在项目中增加一个 k8s-deploy.yaml 文件，文件中包含服务部署所需的配置、发布方式、访问方式等信息。待镜像构建完成后，直接 apply 这个文件即可完成部署。

回顾

现在我们再回到前面的服务场景变形流程图来看：当系统中存在 A、B、C 三个服务，并且 A 服务在测试过程中需要调用集成环境中的 B 服务和 C 服务时，就可以借助 Kubernetes 提供的内部域名来完成访问。等整套测试流程执行完成后，我们在主线上打 tag，让 CI 自动完成 image build、镜像构建以及 Harbor 仓库推送等操作。

至于其中提到的准发布环境，则可以通过 kubectl apply 的方式完成部署。由于线上生产环境往往更加复杂，我更推荐大家通过自研容器云平台来承载发布操作。我们目前也是采用这种方式，通过云平台进行发布，不仅功能更完整、更安全，也更符合真实线上部署和变更管理流程。

成果展示

最后，再和大家分享一下我们最近正在推进的项目情况。从 2019 年 12 月开始到现在，团队每天基本都保持着较高频率的 commit 提交，而在这期间，整个系统累计执行了大约 4500 次自动化测试。大家可以设想一下，如果没有这套自动化持续集成与持续部署体系，这么多测试工作需要投入多少人工成本，又会消耗多少研发与测试资源。