从供应商深度绑定，到走向真正的云原生，他们是这样做的

供应商深度绑定带来的问题

茶百道，这家以创新精神打造新零售模式的企业，在奶茶市场中展现出了卓越的成长势头。面对激烈的市场竞争，公司认识到其成功的关键在于快速响应市场变化，及时迭代产品与服务，因此对研发的敏捷性和效率抱有极高的期待。

在早期阶段，受制于研发团队的有限规模，茶百道采纳了一家外部供应商提出的全包式研发运维解决方案。这个全面的解决方案不仅包含了完整的应用生命周期管理——从开发到部署再到后续的运维，还提供了必要的基础架构支持和一系列工具链资源。这样的设计让开发人员可以远离复杂的基础设施和配置管理，专注于业务逻辑的实现，极大地提升了开发效率。

但随着品牌的日益壮大，茶百道的业务量和研发需求大幅上涨。例如，在微服务架构日渐庞大的情况下，茶百道急需引入一个全链路监控系统，以增强对应用性能和健康状况的洞察。但这个需求在现有供应商提供的定制化 K8s 集群环境下，似乎难以实现，供应商无法在预期时间内提供解决方案，且没有给予茶百道足够的自主扩展能力。因此，公司开始认识到，与供应商深度捆绑的方案，在某种程度上限制了技术适应性和业务的灵活性，是时候摆脱依赖，向云原生应用研发前进。

对此，茶百道组建了由资深技术专家和运维人员组成的研究小组，他们对市场上的各种解决方案进行了全面的调研和比较，希望找到一套能够实现如下目标的方案：

1. 无缝地迁移现有的基础架构到完全符合云原生标准的 K8s 集群，同时确保业务过渡时的无损。

2. 将基础设施、中间件和 DevOps 平台解耦但又能彼此连接。

3. 平滑地将研发工作迁移到新 DevOps 平台。

4. 在云原生框架内，将复杂的配置和管理任务留给少数运维专家处理，让开发人员无需了解诸如 Dockerfile 和 K8s 配置的细节。

5. 最小权限原则下，允许开发人员在不拥有额外 K8s 集群权限的前提下，高效地进行问题诊断和定位。

6. 灵活性至上，企业可以根据自身的具体情况和标准，自主定制和调整研发流程，不受平台的限制。

阿里云云原生解决方案

最终，茶百道在阿里云的专家团队的帮助下，找到了一条相对可行的解决路径。阿里云提出的的云原生解决方案，集成了云效、阿里云容器服务 ACK、阿里云应用实时监控服务 ARMS 等一系列独立又能彼此协同的标准化工具，不仅满足了茶百道提出的所有研发和运维要求，还为企业未来的技术发展提供了强大的支持和灵活的扩展性。

茶百道的解决方案结合了阿里云的云效、ACK、MSE、ARMS 等产品，通过灵活组装，形成了一套完整的微服务研发运维解决方案，具体来说：

• 云效： 作为开发者日常工作的主入口，提供研发和运维的协同机制，由运维定义企业的研发规范并按应用管理研发资产，开发者专注于应用的开发和交付。
• ACK： 作为云原生的基础设施，替代自建的 K8s，提供更好的自运维、更好的性能以及更佳的弹性。
• MSE： 作为微服务治理的主要入口，解决应用的服务发现、限流、熔断，并结合云效，实现应用的全链路灰度发布，提升线上服务的可靠性。
• ARMS： 作为应用可观测性的主入口，无侵入地提供从基础设施到业务应用的全链路观测能力，及时发现并快速定位问题。

针对茶百道的业务特点和团队情况，该解决方案遵循 DevOps 的理念，让运维专注于研发规范的制定和资源权限的管理，开发者负责从编码到发布的完整流程。因此该方案可以分为运维人员和开发者两个视角，如下图：

可以看到，运维人员和开发者的诉求和关注点是截然不同的。

• 运维人员： 能批量管理数百个应用，能将制定好的研发规范批量配置到应用上，开发者只需有对应应用的权限，通过简单的白屏操作就可以完成日常的研发交付。
• 开发者： 能一站式地完成从业务需求到编码、测试、部署和发布的所有工作，能够方便地进行问题的定位和排查，无需跳转到其它平台，也无需申请额外的权限。

云效通过应用模板、细粒度的权限管控、灵活的流水线编排以及内置的环境观测，很好地满足了两种角色的不同诉求。

场景 1：两个运维管理数百个应用

茶百道 DevOps 流程的落地和维护由 2 名运维同学兼职负责。因此，对运维同学来说，如何快速管理和维护数百个应用，保证研发规范的正确落地，同时又避免出现因为权限管理太松导致的安全风险，就成为了必须解决的核心问题。

茶百道是这么解决这个问题的。

1、维护应用模板，通过模板批量创建和更新应用

茶百道在云效应用交付 AppStack 上定义了几套企业级的应用模板，所有的应用都是基于这几套模板创建或者关联过来的。应用模板由运维负责维护。比如，下面是他们维护的一套 Java 后端应用的模板，这个模板里面定义了应用的部署编排、应用的四套环境、以及应用的研发流程。

1）应用模板——编排配置

在应用的编排配置中，避免任何跟应用相关的硬编码配置，将这一部分配置都抽取到变量组中，由各个应用自行定义，这样，所有应用的部署编排就可以统一维护了。

2）应用模板——环境配置

运维同学为开发团队定义了四套环境，分别为：开发环境、测试环境、UAT 环境和生产环境。由于这些环境背后的集群管理权限都在运维手里，在模板里，运维为各个环境确定了所属的集群和部署策略。

3）应用模板——研发流程配置

以往维护应用最麻烦的就是流水线配置，因为各个应用的流水线都有一些细微的差别，比如镜像地址不同、审批人不同等，导致即便做了一套流水线模板，在具体应用中仍然可能会做微调，而一旦出现了微调，后续要做流水线的批量更新就很麻烦了。

茶百道当前的做法是将应用间存在差异的部分都用环境变量来替换。

应用模板/研发流程配置

比如，应用构建出来的镜像地址，统一规范为其最后一级的名称，与应用名保持一致，于是在流水线的构建步骤中就可以按如下方式来定义：

当一个新的应用基于这套模板创建出来之后，应用的负责人只需要把代码库关联上去，运行研发流程就可以进行开发和部署了。

应用模板支持批量同步，这一特性大大地减轻了茶百道的维护成本。比如，应用编排都是类似的，当需要加一个配置（比如增加一个监控探针），只需要更新应用模板中的编排配置，再同步到所有应用就可以了。

2、统一定义角色权限，并由应用的负责人来维护应用成员角色

如果所有的应用配置都要由运维来处理，这种做法显然是不高效的。在茶百道，应用的很多配置工作是交给团队的应用负责人处理，同时又在权限上保证不会破坏企业的研发规范。为此，他们做了如下设定。

1）收口应用的创建权限，把应用的所有者收口到运维

企业中除运维和少数研发管理者外，大部分人的企业角色为成员。茶百道将企业角色权限中的“新建应用”权限收回，这样应用的拥有者就被收口到了少数的运维手里，同时，对于存量应用，通过拥有者转交，将拥有者权限也都收口了。

通过这个权限设定，避免了有应用权限不受控的情况。

2）为每个应用指定对应的研发团队 leader 为负责人，由负责人管理应用的成员角色

将应用的拥有者收口并不等于收口所有的应用维护工作，相反，茶百道希望将应用的维护都交由对其最熟悉的研发团队负责。为此，在创建好应用之后，运维会为每个应用指定一个负责人，由该负责人配置应用的成员角色、代码库、修改变量等必要信息。应用负责人一般为该应用所属研发团队的 leader。

3）为开发、测试定义最小权限，避免误操作

为了避免误操作，运维收回了开发、测试角色的应用管理权限，仅保留必备的研发流程运行和环境操作权限，以开发角色为例。

当这些配置完成之后，日常的维护工作就比较简单了，而且，随着研发团队对工具的逐步熟悉，整个的协作过程也变得越来越流畅。

场景 2：开发负责发版，测试保证发版质量

茶百道的发布频率非常高，活跃的应用每天都有多次发版。为了适应这种快速的业务交付节奏，由开发负责发版的执行，由测试保证发版质量。在实际执行中，他们是这么做的。

1、在应用模板中约束生产部署前必须通过测试审批

在前面的权限管理中，运维收回了包括应用负责人在内的所有角色直接操作生产环境的权限，生产部署只能通过研发流程完成。另一方面，通过应用模板约束了生产部署的流水线卡点，在部署到生产环境前，必须通过测试角色的审批。

同时，每次审批通过或失败，都会通过飞书机器人发送到飞书群里，这样团队成员第一时间就可以收到即将发版或准入失败的消息。

2、在构建前加入代码检测和安全检查，做最基础的兜底

受限于研发团队规模，茶百道缺少专门的安全团队来进行安全和代码质量的把控。对此，团队将这一部分兜底的工作交给了外部工具（如源伞），通过在生产阶段配置检测任务和卡点，避免严重的代码和安全问题带入到生产环境。

得益于研发模板的批量更新能力，运维可以持续地优化和调整代码检测和安全检查的工具和卡点逻辑，逐步提升代码的质量和安全水位。

场景 3：没有 K8s 的运维权限开发者也能排查和定位问题

之前，茶百道一直存在一个两难的问题：一方面，他们希望开发者能独立完成应用的开发交付工作，包括出现问题之后的定位和排查；另一方面，又希望把集群权限限制在少数基础设施运维的手里，避免权限滥用带来安全风险。

经过一段时间的尝试和摸索，茶百道逐渐意识到，要解决这个问题，必须自己建设一套面向开发者的问题定位和排查工具，把集群权限藏在后面，只把基本的观测能力暴露给开发者。但是受限于团队情况，茶百道自己很难有时间和精力建设这一套工具。

接入云效后，他们发现云效 Appstack 恰好解决了他们的这个问题。

1、运维负责导入和管理集群

将集群的管理权限收口到运维，运维将集群导入到 AppStack 的资源池。茶百道的生产集群都在阿里云 ACK 上，相对于其它的 K8s 集群，ACK 集群无需开启 API Server 的 EIP 访问就可以被云效 AppStack 导入和管理。

集群被导入之后，就可以被应用环境关联并使用了，而使用者不需要集群的访问权限。

2、开发者负责环境的观测和问题定位

无论是在部署过程中，还是部署完成后，开发者都可以进入到对应的应用环境。

如果需要排查应用的问题，可以直接查看 Pod 的容器日志。茶百道要求所有应用的日志都打印到标准输出，这样大部分的测试问题排查场景，开发者都可以通过查看容器日志来定位。

而对于线上环境出现的问题，茶百道接入了 ARMS 和 SLS，开发者可以直接在对应工具上查询分析，更适用于需要全链路分析的场景。

场景 4：业务正常运行的同时进行全链路灰度的验证

之前很多困扰茶百道许久的问题，在现在很容易通过接入商业或开源的标准化工具解决，这可能就是接入真正的云原生生态的最大收益。全链路灰度场景是其中一个非常典型的案例。

茶百道采用阿里云 MSE 来实现全链路灰度发布。整个过程中，研发团队所要做的都是配置类的工作，包括 MSE 上灰度策略的配置、云效上灰度环境和灰度发布流程的配置，而无需等待工具链的定制开发。

这一方面大大缩短了验证和上线的时间，另一方面也不会与工具链产生强的绑定。

“未来即使我们打算切换灰度发布工具或者 DevOps 平台，都不会再像之前那样，成本高昂且战战兢兢。”茶百道技术总监马晓超说道。

🔔 注： 如何进行全链路灰度发布，可以参看阿里云上的这一篇文章：https://help.aliyun.com/document_detail/2706081.html?spm=a2c4g.423891.0.0.528d428bDRSoQ8

总结与展望

经过这一年的探索和实践，茶百道完成了云原生应用研发交付体系的建设，并形成了适合业务发展的持续交付和 DevOps 能力体系。

接下来的演进，我们会从三个方面着手：

从 DevOps 到 BizDevOps，把业务交付与软件研发更好地连接起来，从持续交付一个研发任务，上升到持续交付业务需求。

建立业务的观测与反馈能力，从而更准确及时地识别发布风险，优化业务决策。

利用云原生的弹性能力，降低成本的同时，进一步提升系统的韧性。

茶百道技术总监马晓超说。