平台工程实践，让应用开发如搭积木一般简单

Rainbond云原生

于 2023-09-14 16:50:49 发布

阅读量212

点赞数

文章标签：平台工程 kubernetes devops

本文链接：https://blog.csdn.net/mrex326428/article/details/132884200

版权

在过去，传统的应用程序部署和管理通常是一个复杂且耗时的过程。这包括硬件和服务器的采购、配置、维护以及应用程序的手动部署和扩展。随着云原生概念的普及，虽然带来了扩展性、可用性等方面的改进，但也意味着运行单个脚本部署一个完整应用程序的日子一去不复返了。

“开发者应该能够端到端的部署和运行他们的应用程序和服务，你构建它，你运行它”，这样的话看起来没有问题，但对于大多数公司来说，这并不现实，复制完整的 DevOps 流程并非易事。当开发人员负责构建和运行时，环境和基础设施的管理也移到了开发人员的头上。这是一个全盘皆输的局面，开发者无法将更多的时间投入到编码和产品开发，而负责运维的同事则需要解决来自于开发者的问题。

那么，如何确保开发人员可以独立运行自己的应用和服务，且不需要依赖其他同事的帮助？这正是平台工程需要解决的核心问题，本文将分享我们通过开源产品 Rainbond 构建自己的开发者平台，实现平台化开发体验的实践。

什么是平台工程？

平台工程是一门设计和构建自助服务功能的学科，旨在最大限度地减少开发人员的认知负担并实现标准化流程的软件交付。

在企业内部，底层设施种类繁多，即使使用云厂商提供的服务，也会面临不同云厂商的API、SDK等差异。有时，工程师根据实际需求采购各种资源和服务，并创建工具以整合它们，以便供业务开发使用。然而，即使这个流程已经建立，但在更换云厂商时，仍需要重新调整。且这类整合方案对开发者而言依然需要较高的学习成本。

而平台工程的目标是解决这类问题，专业的工程师负责购买、整合各类服务，并构建内部开发平台，以构建自助服务解决方案。这使得开发人员能够在该平台上自助搭建和管理运行环境，自主运行代码，实现快速交付，而无需关注底层设施。

平台工程的关键要素

不被供应商锁定：平台工程需要支持对接各种公有云、私有云等，以降低迁移成本，使组织不会受制于特定云厂商。
自助解决方案：平台工程师需要整合各类基础设施，并在其之上构建供开发者使用的平台，为开发者提供自服务的能力，使其能够快速创建和管理运行环境，自主运行代码，实现快速交付。
应用全生命周期管理：开发者应能够在平台上轻松部署应用程序并管理其整个生命周期，而无需了解复杂的基础设施和运维概念。
模块化能力：平台工程鼓励开发者开发模块化的应用，使各个业务模块能够以标准化的形式互相连接，实现复杂的应用系统。

如何开始?

当前，在一些企业内部，可能已经有运维人员构建好的 CI/CD 流程，开发者提交代码，CI 构建出镜像，并更新线上服务的镜像。这涵盖了大多数部署用例。然而每当我们需要做一些超出这个工作流程之外的事，就会变得更加复杂和耗时。例如：快速部署新环境、添加新的业务模块和依赖、添加各种配置、回滚和调试、应用升级等。

而平台工程就是将这些工作流程及额外的事绑定在一起，不需要让每个人都了解这些工具链，就能拥有快速启动应用、将应用模块化且不依赖其他工程师的能力。衡量该平台的关键原则之一是应该很容易做正确的事情，而很难做错误的事情。

对于广大中小型企业或者传统行业来说，通常没有足够的人力来自建这类平台，而一些公有云厂商也提供了一些相关服务，看似很好，但却很容易导致供应商绑定。因此找到一款不被供应商绑定、成熟且开源的平台是一个好的选择。

实践：构建云原生平台工程

根据平台工程的关键要素，我们最终选择了开源产品 Rainbond 作为内部开发者平台，它是一个不用懂 Kubernetes 的云原生应用管理平台，可以对接各类公有云、私有云、物理机。关键特点如下：

零学习成本，图形界面，鼠标点击就能完成所有操作。
自动识别多种开发语言，如 Java、Python、Golang、NodeJS、Dockerfile、Php、.NetCore 等，通过向导式流程完成构建和部署，不用写 Dockerfile 和 Yaml 文件。
业务模块化拼装，可复用的业务组件一键发布，统一的组件库存储，通过业务组件积木式拼装，实现业务组件的积累和复用。
丰富的可观测能力，提供全面的可观测性，涵盖集群监控、节点监控、应用监控、组件监控。
应用全生命周期管理，Serverless体验，应用管理和运维，组件管理和运维，无侵入微服务架构。
全面支持国产化信创，传统应用自动识别和部署到信创环境（自动编译兼容国产CPU，自动部署到兼容的服务器），并可以管理信创应用的全生命周期，如启动、构建、更新、关闭、回滚等。

平台工程将角色主要分为两类，平台工程师和开发人员。两者关注的点不同，平台工程师关注底层工具的整合和平台本身，而开发者则更关注应用，平台的最终用户实际上是企业内部的开发者，因此接下来我将站在开发者的角度分享我们是如何利用 Rainbond 实现了平台化的体验。

应用部署

在平台工程中，应用的部署是一个关键步骤，它使开发人员能够将其应用程序快速部署到平台上。与传统的部署流程不同，使用平台工程，这一步变得非常简单和高效。

在之前的部署模式中，我们需要先编写 Dockerfile 将代码容器化，并通过一些脚本进行拼接，编写 Kubernetes 的 Yaml 文件或 Helm Chart 之类的模版才能完成部署。当遇到一些复杂的依赖关系需要编排时，这个流程会更加复杂。

而在 Rainbond 平台上，部署应用几乎是一种无需编写繁琐配置的自助服务。开发者只需将其填写好业务代码的仓库地址，点击构建，然后点击几下鼠标即可完成部署。 Rainbond 会自动识别代码语言，将业务代码容器化，并将业务运行起来，使开发者专注于应用本身的开发而不必担心底层基础设施。

当业务运行起来后， Rainbond 还支持页面直接配置网关策略，如域名、证书、tcp 策略等等，开发者不需要了解复杂的概念即可快速上手。

应用全生命周期管理

平台工程的核心目标之一是实现应用的全生命周期管理。这意味着开发者不仅可以轻松部署应用，还可以在整个应用生命周期中进行监控、扩展、升级和维护。

使用 Kubernetes Yaml 或者 Helm 等方式，会遇到这样的问题，在 Kubernetes 底层并没有应用的概念，都是以一个个工作负载、Service、Ingress 等资源组成的。且各个工作负载之间的关系并不明确。对应用开发者而言，在观测性和管理上都是一种负担，更不用说按需启动或关闭应用节省资源了。

而 Rainbond 平台提供了丰富的应用管理工具，开发者站在应用的角度观测整个应用的拓扑、运行状态，如下图所示，每一个六边形都是一个微服务，所有的微服务之间互相依赖，构成了完整的应用对外提供服务。如果某个微服务模块出现问题或处于关闭状态，均可以一目了然。且在应用角度和微服务模块上，都支持启动、关闭、更新、构建等全生命周期操作。

点击某个微服务模块，还可以进一步监控和配置该业务模块。可以查看运行状态、资源使用情况、日志等，出现问题也可以利用平台提供的 Web 终端直接访问到业务容器进行排查。开发者可以真正做到”谁构建、谁运行“，而且不会增加额外负担。

积木式拼装

模块化能力也是平台工程至关重要的一环，开发者开发好的应用只有能以一种标准化的形式交付、且每个应用都能形成可复用的模块，才能最大限度的减少开销和浪费。平台应该能提供默认操作，让开发团队能不需要额外努力，就能以正确的方式做事。

而这也正是 Rainbond 的独特之处，其支持应用级别的抽象，我们可以将每个应用沉淀为不同的应用模版，以便团队内部或跨团队共享，实现积木式拼装。这意味着开发者可以将不同的业务模块和组件像搭积木一样组装在一起，创建复杂的应用系统。

如下图所示，开发者可以将已发布的应用模版一键安装下来，并通过连线的方式编排其依赖关系。

同时，开发者创建自己的应用模版也应该是极其简单的，Rainbond 基于应用级的抽象，提供了应用模版交付的能力。简单来说就是当你的应用在平台上正确的运行起来后，那么你通过界面将其发布成自己的模版后，该模版应该也能在另一个环境一键安装下来。这既简化了开发者制作自己可复用模版的步骤，还提供了与底层无关的交付体验。

即使不懂技术，也能通过该应用模版将完整的微服务应用一键交付到客户环境。

通过将应用模版化和积木式拼装，平台工程将复杂性隐藏在背后，开发者只需选择所需的模块并将它们连接在一起即可，这使得构建高度定制化的应用系统变得非常容易。