云原生微服务应用的平台工程实践

作者：纳海

01 微服务应用云原生化

微服务是一个广泛使用的应用架构，而如何使得微服务应用云原生化却是近些年一直在演进的课题。国内外云厂商对云原生概念的诠释大同小异，基本都会遵循 CNCF 基金会的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

弹性可扩展，是企业选择上云的一个重要原因。它可以为企业节省大量成本，同时保障服务稳定性。我们有个电商客户，平时只有 200 多个服务节点，但在大促时轻松扩容到上千个节点。这个扩容动作通过平台一键完成，只需要秒级的时间。操作之简单、时间之短是在上云之前是不可想象的，那些复杂漫长的硬件采购、环境搭建和服务部署流程被自动化完成。

在云原生领域，有一个广泛知晓的 Pets vs Cattle 比喻：在传统运维上，我们习惯把服务器当做“宠物”，这些服务器一旦出现问题我们会非常紧张；而在云原生阶段，服务器更应该被当做“牛群”，它不再具有特殊性，出现问题后可以通过自动化机制进行替换修复。在 Kubernetes 上，这一点尤其体现的淋漓尽致。如果某个 Pod 容器出现问题，那么我们应该能通过 Liveness 探针检测到容器异常，然后完成容器退出，并自动重启容器。

02 云原生浪潮的新问题

云原生浪潮释放了巨大的技术能量，但同时也带来了许多新的问题，这些问题广泛存在于企业的开发、测试、CICD 和运维场景。首当其冲的是 DevOps 实践。

图片来源于：https://www.atlassian.com/devops

DevOps 理念倡导的是，通过加强研发和运维团队在应用研发声明周期内的沟通合作，和配合自动化工具的使用，提高软件交付的速度和质量。 甚至研发和运维这两个角色往往是由同一个团队承担，达到 “Who Builds，Who Runs” 的境界。

但理想很美好，现实很骨感，DevOps 在很多企业中落地实践逐渐变了样，甚至出现了一些反模式。研发团队承担运维角色之后，需要学习 Kubernetes 编排、容器化、基础设施即代码、GitOps 等云原生运维知识，并负责各个环境的运维。这占用了本来用来实现业务需求的时间，反而降低研发团队的生产力。另外由于生产环境的特殊性，往往会由团队内较为资深的研发人员来承担运维责任，这导致了一个很奇怪的局面：生产力低的员工在写代码，并交给生产力高的员工来运维。

很多人没有意识到这些问题，以为通过 DevOps 减少了运维成本，但实际上付出的隐形成本并不小。这不是危言耸听，有许多研究已经证明了这个问题的存在。例如 Humanitec 曾对使用 DevOps 的组织进行了调查，发现有 44% 的组织存在这种反模式，即开发人员不仅需要完成自己的 DevOps 任务，还需要花费大量的时间承担帮助团队的职责。

图片来源于：https://humanitec.com/whitepapers/2021-devops-setups-benchmarking-report

问题不在于 DevOps 本身，而是我们是否提供了一个好用的平台和工具链来支持研发团队进行自服务(Self-Service)。这个平台屏蔽了下层复杂的基础设施、各种各样的云原生定义和yaml规范，向研发、测试和安全团队提供简单而清晰的平台交互，以加快上层业务迭代速度和提升产品质量。

如何构建这样的平台和工具链，称为平台工程(Platform Engineering) 。如果说云原生和 DevOps 带来了各种各样的定义，对研发人员是一个熵增的过程，那么平台工程就是屏蔽复杂定义、提供简单清晰交互的熵减工程。

03 平台工程

平台工程概念并非最近才诞生，这个词早在 2011 年已经有人开始使用(见 what-is-platform-engineering [ 1] )，并在 2017 年见之于技术雷达(见 platform-engineering-product-teams [ 2] )。而在云原生技术日益繁杂的今天，容器、编排、服务网格、可观测等各种产品及工具涌现，CNCF 云原生版图已经有超过 1000 个产品，在这种背景下平台工程的诉求愈加强烈。

Gartner 之前发布了 2023 年 10 大技术趋势，其中平台工程占有一席之地：

图片来自：https://www.gartner.com/en/articles/gartner-top-10-strategic-technology-trends-for-2023

如何实施平台工程呢？这个问题也同样充满了争议。引用一段来自于平台工程社区 [ 3] 的描述：

Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.

翻译过来也就是，平台工程是设计和构建工具链和工作流的学科，使软件研发组织能够在云原生时代具备自服务能力。平台工程师提供一个称为“内部开发者平台”（IDP，Interal Developer Platform）的集成产品，涵盖整个应用生命周期的运维需求。

您可能会发现，这个定义和 PaaS（Platform-as-a-Service）的定义相差无几。按照一般的区分，PaaS 是由供应商提供，而 IDP 则是面向内部的平台。但是 IDP 是否等同于自建 PaaS？这个问题并没有标准答案，每个人都可能有自己的看法。

但有一个很明确的点是，企业的确需要这样的平台来解放研发和运维团队的生产力，无论它是 IDP 还是 PaaS。 对于像谷歌、亚马逊和 Netflix 这样的公司来说，他们有足够的规模、资本和人才储备来构建自己的 IDP 平台。而在社区，也存在如 Backstage、KubeVela 等产品来帮助构建内部平台。

问题是，大部分企业是否有足够的人力、时间和成本来完全从 0 构建这样的内部平台？ 在如今越来越卷的竞争环境下，快是制胜之道。更快的迭代可以更快地验证产品功能、市场和进行安全问题修复，如何提高研发团队的生产力一直都是每个企业的核心考虑点。

在平台工程上，谷歌、亚马逊或 Netflix 等公司或许获益颇丰，但同时也有很多公司陷入泥潭。前不久一篇《通用电气在平台工程上浪费 70 亿美元的教训》 [ 4] 的文章介绍了通用电气的平台工程实践，每个人可能从中学到的教训不同，但至少证明了一点：平台工程需要因地制宜的制定策略。

如果你问我广大中小型企业或者传统行业应该如何走向云原生之路、如何利用 DevOps 提升迭代效率，我会谨慎地建议：如果时间对你很重要，那么在找到更好的方案之前，不妨基于主流云厂商的 IaaS 或者 PaaS 来构建自己的产品迭代流程。

在这个领域，主流云厂商基本都有较为成熟的沉淀，大多数能力都是开箱即用。EDAS 很早就进入了微服务和云原生领域，经过了八年左右的迭代，目前具备了如下大体能力：

由于篇幅所限，上图未完全体现所有平台能力。对于很多企业来说，这些平台特性不是一朝一夕就能实现的。从底层基础设施的统一管理，到核心的应用管控，再到上层的工具链交互入口，每一个层次都需要投入大量的人力和时间进行打磨。

在这几个层次中，研发人员交互最多、却又最容易忽视的莫过于工具链。无论是云产商提供的 PaaS，还是企业自建的 IDP，如果忽略了研发、测试和运维团队最常用的工具，那么这样的平台使用起来是难以得心应手的。我们坚定的认为，只有结合工具链，云的能力才能最大化的交付到一线研发手里。 工具链是连接开发者和 IDP/PaaS 平台的重要粘合剂。

到目前为止，我们构建了如下三大场景的工具链：

开发场景；
测试场景
CI/CD 场景；

这里并不是否定基础设施管理和应用管控的重要性，恰恰相反它们是工具链的基石，缺乏它们一切无从谈起。下文旨在分享开发、测试和 CI/CD 等场景工具链，希望对广大希望采用 PaaS 或者 IDP 的企业有所帮助。

04 开发场景工具链

在开发场景上，我们认为工具链的核心是程序员的 IDE。 在方向上，Cloud IDE 当然是酷炫的，它是一种在线集成开发环境，允许开发人员通过浏览器即可完成开发、测试和应用部署。但实际上国内采用 Cloud IDE 进行开发的企业并不多见，根本原因在于 Cloud IDE 的体验还比不上本地 IDE 的体验。当然在某些场景下 Cloud IDE 可能是唯一方案，例如要求代码不落盘的高密项目。但在综合考虑下，我们还是暂不提供 Cloud IDE 的解决方案。

经过慎重考虑，我们选择通过 IDE 插件来提供平台能力。这种方式可能不那么高大上，但一定是最接地气的，实际上也是研发人员最容易接受的。整体上我们通过 IDE 插件提供了三大能力：开发联调、应用部署和 API 调试。 在使用上，研发人员基本都会优先在本地完成开发联调，联调通过后再进行应用部署和验证，这个效率是最高的。

开发联调

这个能力是我们首先关注的，传统应用进行云原生化改造，如何进行高效开发调试一定是首先需要面对的问题。对此我们提供了本地调试和端云互联两种模式。

本地调试：通过 IDE 一键启动本地 Nacos 注册中心 [ 5] ，完成本地开发调试。对于简单的应用，开发人员在本地就可以通过这个注册中心完成调试，无其他外部依赖，简单且高效。
端云互联：通过 IDE 在本地启动应用，底层通过插件代理自动跟云上网络打通，本地节点跟云上其他微服务节点具备同样的能力，可相互调用。这种方式对于复杂微服务开发调试非常有用，研发人员的调试效率大大提高。

根据实际使用情况来看，这两个能力都备受客户青睐，而端云互联能力更是命中微服务开发调试的痛点。端云互联不仅可以使得应用跟云上互联互通，还把云的能力下沉到研发人员的开发端，比如分布式链路跟踪和全链路流量控制等等。

此外，我们还支持容器级和进程级流量转发、ECS 和 Kubernetes 多种代理、适配 Windows 和 MacOS 系统等等，感兴趣可查阅 EDAS 端云互联文档 [ 6] ，此处不再展开。

应用部署

我们早在 2018 年就支持通过 IDE 部署应用 [ 7] ，对于开发测试环境来说，通过 IDE 完成构建、上传和部署是很爽的事情。当然我们也支持多种 CI/CD 工具集成（下面会进行展开），CI/CD 流程可以使得代码集成和应用发布更安全，尤其适用于集测和生产等稳态环境中。而在开发测试环境中，首要目的是快速验证代码是否符合预期，如果所有变动都需要先提交，再通过 CI/CD 流程部署，那么这个效率肯定是非常低下的。

通过 IDE 部署后，如何确认部署是否成功？最常用的手段就是终端和日志。这两个操作我们也可以通过 IDE 来一键完成。如果应用日志打到标准输出，那么直接通过 IDE 在目标节点上选择查看日志即可：

如果日志打到文件、或者需要通过终端登录目标节点，那么只需通过 IDE 双击目标节点，即可完成终端打开：

更多能力可参考 EDAS 微服务开发侧边栏 [ 8] ，不再展开。

API 调试

我们在 IDE 中集成了云端 API 调试能力，你可以通过 IDE 来快速调试云端应用的接口。这个能力解决了从本地到环境间快速访问通路的问题，这个通路为开发人员节省了宝贵的时间。当出现上下游接口联调问题时，直接通过 IDE 打开 API 调试，现场发起请求测试便一目了然。

API 调试也集成了分布式链路追踪能力，如果中间链路调用出错，点击界面上的调用链即可一键打开调用链页面，异常信息一清二楚。

05 测试场景工具链

在测试场景，我们优先关注接口级别测试和集成测试。而集成测试本身也是依赖对每一个系统接口的测试，并且对接口响应结果进行断言，最终生成整个系统的质量报告。

因此，接口级别测试是上层业务测试的基础。对此我们开放了接口调试能力，你可以通过我们提供的多种工具插件来完成对云上应用接口的测试，整体链路如下所示：

例如，安装完 Jmeter 插件 [ 9] 后，你即可通过界面配置接口测试用例，并完成整个系统或模块的集成用例编写：

EDAS 平台引擎已经处理底层网络的复杂性，你只需要关注上层的业务测试结果即可。在每个工具运行过程中，我们都会打印请求参数、响应日志和链路追踪链接，这样在测试异常时能快速定位问题并改进。

06 CI/CD 场景工具链

CI/CD 即持续集成(Continuous Integration)和持续交付(Continuous Delivery)，《The Product Managers’ Guide to Continuous Delivery and DevOps》 [ 10] 对持续集成、持续交付和持续部署三个概念定义如下：

持续集成： 强调开发人员提交了新代码之后，立刻进行构建和单元测试。根据测试结果来确定新代码和原有代码能否正确地集成在一起。
持续交付： 在持续集成的基础上，将集成后的代码部署到类生产环境，并完成自动化测试，确保可以以可持续的方式快速向客户发布新的更改。如果在类生产环境验证通过后，证明该制品已达到可交付状态，可手工部署至生产环境。
持续部署： 在持续交付的基础上，把部署到生产环境的过程自动化。

CI/CD 领域的产品有 ArgoCD、Jenkins 和云效等开源和商业化产品，这些产品都具备了很高的成熟度。开发者只需要在这些产品的流水线上设置构建、单元测试、集成测试和环境部署等多个流程即可。而在这些流程中，最容易出错、损失最大的莫过于生产环境部署。

根据经验统计，在所有的线上问题中，由于部署变更导致的故障比例相当高。我们非常重视客户应用变更的稳定性，目前支持如下几种发布动作：

单批部署： 一次性把应用中所有节点都更新到新版本。此部署动作常用于开发测试环境，生产环境不建议使用。
分批部署： 按照所设定的批次和间隔来逐步更新应用节点，可以在完成上一批次后，选择手动或自动进行下一批次发布。
金丝雀部署： 在分批部署基础上，将第一批节点设置为金丝雀节点，支持设置金丝雀节点的流量比例、接口参数或者泳道策略，在满足条件的情况下生产流量才会转发到金丝雀节点。比如，如果我们希望只有广东地域的客户端请求才转发到金丝雀节点，那么就可以针对流量中的特征（例如参数中带有 Guangdong 字符）来制定金丝雀流量策略。

目前我们支持 Intellij IDEA、Maven、Jenkins 和云效等多种工具来部署至环境中：

Intellij IDEA

https://help.aliyun.com/document_detail/2362337.html

Maven

https://help.aliyun.com/document_detail/186680.html

Jenkins
https://help.aliyun.com/document_detail/171313.html

云效
https://help.aliyun.com/document_detail/199501.html

例如使用云效实现应用的持续集成和部署，我们只需要将开发好的新版本应用代码提交到代码库，云效流水线 Flow 会监听代码事件，当满足触发事件时会触发流水线运行，部署新版本应用到 EDAS K8s 环境。

07 总结

事情从来都不是一蹴而就的，搭建平台需要相关领域的专业知识和持续的人力投入才有可能做好。当我们选择构建一个平台时，我们构建的是一个有生命的东西，组织架构变迁和技术的更新换代都会对 IDP 产生影响。构建 IDP 不是一锤子买卖，这些变量在最初就要有充分考虑，否则 IDP 最终会演变成一个烂摊子。在云原生化改造过程中，我们可能会遇到很多新的概念，诸如 Helm、IaC、Terraform、Kubernetes 等等。如果时间和成本对你比较重要，而且团队不是这方面的专家，那么选择一个成熟的 PaaS 平台可能是一个更好的选择。

而如果出于其他原因，希望构建自己的内部平台，那么可以遵循平台工程的五大准则，这样可能会让你更容易朝着正确的方向前进：

明确使命和角色。
像对待产品一样对待你的平台。
关注共同问题。
粘合剂是有价值的。
不要重复造轮子。

除此之外，我们提出一点建议：云原生已经非常复杂，平台工程应当在保留灵活性的同时尽量暴露简单清晰的交互，而非一味增加新的逻辑定义以增加研发团队负担。 EDAS 产品一直遵循着这个设计理念。一方面我们支持松管控，支持你可以用最云原生的方式来灵活运维；另一方面，我们暴露最简单的上层应用模型，屏蔽底层的复杂定义，并将云的能力集成到研发团队最熟悉的工具里，做到润物细无声。

相关链接：

[1] what-is-platform-engineering

https://diff.wikimedia.org/2011/08/17/what-is-platform-engineering/

[2] platform-engineering-product-teams

https://www.thoughtworks.com/radar/techniques/platform-engineering-product-teams

[3] 平台工程社区

https://platformengineering.org/blog/what-is-platform-engineering

[4] 《通用电气在平台工程上浪费 70 亿美元的教训》

https://www.infoq.cn/article/qepvmrlawsw735wwunmb

[5] Nacos 注册中心

https://github.com/alibaba/nacos

[6] EDAS 端云互联文档