中国移动 "磐舟" DevOps平台实践
本演讲分享了中国移动磐舟一体化开发交付平台在敏捷研发、统一制品、开源治理、安全扫描、开发环境、持续交付、GitOps 等方面的建设实施以及效果提升，并与大家一起探讨低代码与 Serverless 的未来演进。目前磐舟平台已服务 300 多开发项，近 200 个代码仓库，管理代码超 2 亿行，制品超 50 万，服务调用超 3 亿，月均部署近万次。在云原生开发方面起到了显著地引导作用，促进了中国移动数字资产沉淀，提升了整体研发效能，推动了应用从 on cloud 向 in cloud 的演进。
本文整理自中国移动信息技术中心 PaaS 架构师魏宝辉在 DIVE 全球基础软件创新大会 2022（基础设施及架构设计专场）的演讲分享，主题为“中国移动磐舟 DevOps 平台实践”。
分享主要分三个部分展开：第一部分是磐⾈DevOps 平台的建设背景及成效；第二部分是磐⾈DevOps 平台在 DevSecOps、Serverless 等方面的云原⽣实践；第三部分是磐⾈DevOps 平台的未来演进⽅向。
以下是分享实录：
最近几年，云原生已成为一个非常热门的话题。以容器、微服务、DevOps 为核心的云原生技术快速地席卷了整个互联网行业，此外，传统行业也已经加入到了云原生的行列之中。为什么要做云原生技术呢？首先，云原生技术能够帮助我们业务系统快速地进行迭代；其次，它能够有效地降低企业在 IT 开发和运维方面的成本；最后，它也能够提高我们企业业务的创新效率和产业的价值。
总体来说，我们经历了从传统服务器时代到云化时代、再到云原生时代三个大的阶段。我们从最开始的小型机、X86 服务器演进到后来的云化资源池，再到现在在云化资源池上发展出来的云原生技术底座。
通过这三个大的阶段，在完成云原生技术之后，我们发现：应用随着基础设施的下沉，业务能力的沉淀复用，成为了这种软件模块化的一些能够“化整为零”的“积木”。容器将这些“一块块的积木”和运行环境打包在一起，形成了一个个可以独立运行的“集装箱”，这使得运维更加容易了。此外，在微服务时代，由于要结合容器，对应用的编排需求就会更加迫切。通过组装“集装箱”的方式进行装配编排，也使得我们的调度更加轻松、交付更加迅速了。
云原⽣技术底座向上可为中台和平台能⼒的统⼀封装、灵活调⽤提供技术基础；向下可调度、兼容各类异构“算⼒”，促进资源、要素的⾼效汇聚、流动、共享，具备敏捷、海量和简单的特点。它以弹性可扩展、⾼可⽤、⾼灵活、强兼容性和低成本的⽅式将云的价值最⼤化，也能让云把它的价值输送到应用之中，应用通过云原生的一些开发基础也能够把云计算基础设施所带来的这种便利能力对外释放，形成我们业务上的一些应用价值。
在中国移动，云原生技术底座拓展了我们“连接 + 算⼒+ 能⼒”的这种新型信息服务体系，在我们集团内外部3的“上云⽤数赋智”，以及落实世界一流“⼒量⼤厦” 等方面的战略布局都成为了一个有力的帮手，所以说在我们中国移动内部，云原生技术底座是数字化转型的一个最佳实践。
磐基、磐舟是我们自主可控的云原生技术底座，是以自研为主，打造的共平台、共研发、共能力的云原生技术体系。
磐基、磐舟在我们内部是两个大的品牌，它们的云原生技术底座是统一的。磐基 PaaS 平台，磐舟 DevOps 开发平台，以统一的技术栈加快对技术组件的收敛、服务标准构建；基于盘舟一体化开发交付平台能够加强对开发过程的端到端管控，包括像需求任务管理、代码管理、自动化的一些编译扫描、灰度发布。在磐基上可以进行弹性计、微服务治理、多集群管理等等一系列的生产运行，两者融合为开发交付一体化的解决方案，推进了应用从开发阶段生于云上，实现应用的全生命周期的管理，充分释放云原生的价值。
通过我们引入云原生的核心技术，能够让开发更简单，让部署更容易，让生产运转地更加高效，也能够让系统的韧性更加强劲。而且通过这种模式也把我们的 IT 治理体系变得更为全面了。
磐基 PaaS，由统⼀PaaS⻔户、⽣产运⾏⽀撑、平台管控治理等组成，具备多租户管理、多集群管理、统一的镜像管理、应用的可视化管理以及微服务管理，而且包含了像开源软件管控、智能运维管理等一系列的管理方式。能够极大地减少应用开发运维的工作，为能力向共享、拉通奠定基础，提升了资源的利用率。
磐舟平台是一个与磐基平台共平台、共研发、共能力的平台，它主要侧重在端到端的自动化交付流水线，能够沉淀 IT 软件资产、核心的代码掌控，也能够让我们的开发过程更加可控，通过流水线使我们的开发交付效率再进一步提升。
磐舟平台是将我们中国移动在开发交付过程中沉淀的经验提炼为最佳平台实践的能力，为团队也提供云原生的 DevOps 研发环境和 DevOps 的一些落地手段。推进业务系统规范、标准、自动化地进行业务交付，通过统一的规划、建设、运营实现统一技术生态下的应用系统开发，快速提升研发效率，节约开发成本，支撑应用从开发阶段⽣于云上，融入云里，最终成长为云原生应用，充分释放云原生的价值。
磐基、磐舟的规模落地，推动了我们集团核心业务系统向云原生的转型。我们通过磐基、磐舟这两个有效的手段，推动业务系统向云原生方向进行演进，在大规模的落地过程中，不断地强化了全网 IT 系统自主开发的过程，也提高了我们业务系统向云原生转型的程度。
磐基 PaaS 平台方面，覆盖了大概 B/O/M 三个域的 160 多个核心业务系统，建成了大概 200 多个 K8S 集群，节点规模数现在已经达到 1.5 万，容器实例数已经达到 10 万 +。
磐舟方面，也已经覆盖了 150 多个核心系统，托管了 2300 多个代码仓库，管理了 5 亿多行代码，制品方面也已经提供了 6 亿多次的服务。
应用效果方面，像一些核心的计费系统：开发代码的工作量比以前有了显著的降低，整个开发过程也有了比较好的效率提升，系统中断时间也从分钟级缩短到了秒级，系统扩容响应的时间也有了较大的提升。在一些省份公司和专业机构中也有相关的一些案例。
接下来，我们看一下磐舟 DevOps 平台是如何进行云原生实践的。
磐基是生产运行的过程，磐舟为业务系统的开发提供了开发工具链，像需求设计、任务拆分、迭代、发版管理等等的一些敏捷开发过程，而且我们实现了一些 CI/CD 的流水线，在流水线的基础上也融入了 DevSecOps 的理念。不仅如此，我们也提供了开发环境，可以支撑应用在线拉起、开发测试、服务联调。覆盖了从代码到运行的全过程。
接下来也会随着 Serverless 的引进，进一步地抽象平台能力，将磐基磐舟向 Serverless 方向做进一步的演化。
敏捷研发
在 DevSecOps 工具链方面，首先不能不提的就是敏捷研发。但是在我们移动内部，有很多传统的瀑布式开发，也有敏捷的开发，还有很多特性的研发诉求，现有的工具不能很好地支撑。
磐舟是基于我们自主开发的，能根据内部的一些开发方式、开发需求、开发的个性化诉求进行定制化的开发，尤其是在开发过程方面，不仅仅是提供需求、任务、缺陷、迭代、发版等基础功能，还能够识别像研发的状态、研发的工作量、研发的任务与代码的关联，并能为后续的发版追溯。在关键流程体系方面，实现了对需求管理、敏捷开发、测试管理、发布管理，还有变更管理的一些流程支持。在日常协作方面，满足了各种开发团队对于电子台账、每日站会、重点关注、多人评论等等方面的一些诉求。在追溯性方面，也打通了需求、代码、部署，通过关联，实现从需求到代码到版本的统一管理。
任务分解之后，面临的第一件事情就是我们需要写代码，代码托管在哪里？我们在磐舟上提供了一个安全的代码托管工具。
磐舟是在生产环境上提供统一的代码仓库，用户可以根据自己的研发模式来创建、管理代码仓库，而且在安全权限方面，也支持设置团队的成员、密钥等等一些个性化的校验。目前来看，我们有很多应用都是微服务的，微服务一般会创建多个仓库，多人协同，共同开发。支持使用一些模板化的工具对仓库进行统一的初始化管理。在开发方面，也支持像 IDEA、Eclipse 等等的一些编辑器，从本地环境中进行直接的拉取、提交、推送代码。在平台页面上，也提供了一些管理的功能，如合并、操作、比较等等的一些管理功能。除此之外，我们还在界面上提供了云 IDE 的开发环境，因此一些简单的操作，一些简单的调试，用户也可以从在线的 IDE 中直接打开代码，进行开发调试。
在平台功能方面，我们也提供了像代码行数的统计、平均代码缺陷密度、代码质量扫描、安全扫描等等一系列的安全功能，不仅会给出一些风险提示，而且也会给出一些如何修改的建议。这种安全扫描在我们内部也会作为一个上线前的必要校验环节，只有提供了相应的安全扫描报告，比如漏洞都进行了修复，才能够进行下一个关节的上线。
一般在我们写代码的过程当中会用到各种各样的开发框架。这些框架一般都会依赖于各种各样的开源的组件，尤其是 Java、Node.js 、Golang 等等，这些语言都会大量地用到各种各样的依赖。我们在内网的开发过程中用到的依赖版本经常会与公网上管理的依赖版本不太一致，这时，就会遇到一些问题，我们的几个开发环境可能会出现功能不一致的问题，排查这种问题一般都是比较费时费力的。
为了解决这个问题，我们在生产环境里打通了访问的一些单向网络，在这个网络里，我们可以提供了统一的依赖仓库，以生产环境为标准进行同步依赖，从而一来可以直接使用，二来可以构建同源。通过统一的制品库，为研发、测试、生产几个不同的环境提供可信来源。一点管控，可行分发。
不只是提供了多种语言框架的依赖仓库，还提供了多种类型的私有库，用户也可以根据自己的使用方式对私有库进行管理。在依赖库的扫描方面，因为我们做了一点的可信管控，可以对使用到的依赖进行统一的扫描。当有风险发生的时候，可以进行统一的告知，不仅是可以进行一些提醒，而且还能给出一些可行的解决方法。
在代码开发的过程中，不同的业务系统往往使用不同的开发语言、框架，使用不同的打包工具，依赖不同的组件，存在如此多的变量，如何进行统一地持续构建，其实对我们的 DevOps 平台提出了非常高的考验。
在云原生的理念下，更多的是以容器的方式进行交付，我们以引导用户更多地使用 Dockerfile 进行构建，通过对标 Github，我们也提出了我们自己的一些构建方式，首先使用 Dockerfile 的多阶段构建技术，把构建的主动权还给用户，用户可以根据自己的开发语言、开发框架、使用习惯去构建自己的流水线，自己的业务系统将要如何编译打包、如何配置通过描述语言写入到这个流水线中，也将运行容器和构建容器进行分开管理，避免在代码的管理当中混入太多的环境管理、过程管理，而且一些配置类的信息代入生产环境中也是不安全的，有一定安全隐患。通过版本化的配置文件，我们可以将整个的配置文件放到代码仓库中，随着代码一起进行版本的管理。
再就是我们打通了 Docker build 出来的镜像如何在开发、测试、生产等不同环境中进行的统一同步。通过这种镜像的同步，可以有效地解决在这几个环境中不断进行推送同步的工作量，而且通过我们实现的这个统一分发推送渠道，用户只需要关心两个方面：第一是我的代码如何去构建成镜像；第二是我的镜像如何去使用。
在我们平台提供的功能里，首先是解决镜像的分发，可以从构建环境中单向地向不同的环境进行推送，而且在推送之前，添加了一些安全保障能力，为了保障生产安全，尤其是在向生产环境、准生产环境同步之前，会进行安全扫描，只有安全扫描通过，才能够同步通过。这一方面保证了便利性，另一方面也对安全性提供了一定的保障。
有一些镜像修复起来并不是那么容易，所以我们提供了一些基础镜像。我们会对常见的漏洞进行统一的加固修复，加固修复完成之后再提供给业务系统使用。业务系统使用我们提供的这种构建镜像，在一些漏洞的修复方面，只需我们统一修复构建完成即可，整体的开发效率也能得到进一步的提升。
在开发过程中，一般需要进行不断的开发调试，对于 CD 的过程，其实会要求更加的迅速。针对这种开发过程不断连续的调试部署，我们推出了一个 GitOps 的管理平台，GitOps 能够以版本化的方式将声明式的配置，将应用的编排、构建等等一系列的操作形成流水线，而且是在 Git 中进行版本化管理，不同的环境中都使用相同的声明式配置。它也是非常方便的一种部署方式，我们目前提供的这种 GitOps 管理主要有两种：一种是提供了界面的引导式，能够满足初学者对界面操作的使用诉求；另一种是提供纯粹的 YAML 提交方式，一些高级的研发运维更习惯于直接去操作 YAML 文件，以进行应用的编排管理。这两种方式，不管是针对初级的用户，还是高级的用户，在使用上都是非常方便的。
应用部署后，面临的第一个问题就是如何访问它，而现在随着 ServiceMesh 的流行，我们在平台中也增加了对 ServiceMesh 的完整支持，而且默认开启了 ServiceMesh 的能力，用户在提交了自己的应用程序之后，会被编译成云原生的镜像，通过 GitOps 也能够将 ServiceMesh 的控制 YAML，尤其是 Isito 的，一起进行提交。
首先，我们在能力上包含了完整的 Isito 管理功能，用户在使用的过程中，可以根据自己的开发需要编写 YAML。
第二，我们在平台里配置了通用的网关配置域名。有时需要访问一些临时域名，这时可以比较方便地打通从用户自己的开发环境到我们平台的访问。
第三，支持内部域名的自定义 CRD。这样用户在开发调试的过程中可以保持相同的配置，只是在不同的集群里配置一下域名的解析 CRD 即可。在整个过程中，环境的配置变量都无需调整，进一步缩小了研发环境和生产环境的差异性，生产环境、研发环境的差异越小，上线后的稳定性也一定会有所提升，从而降低问题的排查成本。
应用部署完成之后，往往需要进行⽇志的查看，检查应用是否运行正常，有没有报错，所以在平台上，我们对应用程序的文件日志、标准输出 Console⽇志，还有一些网关访问的日志，以及操作的日志都进行了统一的收集，并进行了一些关联，这样用户在出现程序问题时，可以比较方便地从这几个方面进行故障定位，从而提升开发效率。
在开发过程中，除了查看日志，还会经常查看应用的运行状况，甚至有可能需要进入到容器中一点点地执行调试命令。在没有我们平台界面之前，用户需要不断地在各个环境、各个系统中切换，会带来非常高的切换成本和操作的复杂度。我们提供了一体化的管理界面，既能看到集群的运行情况，也能看到应用的简单运行情况、资源的用量、应用资源的关联关系、应用的运行日志，还能进入到容器中执行一些 Shell 命令。通过这种方式，不管是运维人员还是开发人员，都能够对日后系统如何在容器的云环境中运行，有一个更加直观、更加贴切的感受，对于日后发布到生产环境，如何排错、如何保证业务的稳定运行都能打下比较好的基础。
在集群管理方面，我们主要提供了一站式的开发验证环境，前面提到的整个过程都是对如何开发软件做支撑的，开发软件运行所需要的环境，目前来说，一般是要提供一套 Kubernetes 环境的，而 Kubernetes 环境相对来说还是比较昂贵的，对配置的要求也比较高，并且我们也难以为每个同学都提供一套 Kubernetes 环境。
因此我们在磐舟平台上提供了 Kubernetes 开发环境，用户在使用时，可以通过界面来点选申请。申请到开发环境之后，他可以在环境内进行各种开发调试。一般来说，申请到的开发环境有一定的时间要求，时间到期或者用户使用完成之后，它可以被归还到大池子中，从而提高了整体的资源利用率。
在开发方面，其实还有一个比较大的问题，那就是数据从哪来。目前来说，我们还不能将数据从生产环境中直接拷贝到测试环境中，这些数据需要进行一定的脱敏验证。另外，在自动化测试方面往往需要进行自动化的接口测试、UI 测试、回归测试，如果没有自动化的工具，整个测试效率也会比较受影响。在我们的环境中会整合这几类自动化进行统一提供。
在安全门禁体系方面，磐基磐舟共用一套 DevSecOps 设计，涵盖了研发、构建、运行的各个方面。通过在研发流水线的整个过程中，设置不同的检查点形成安全门禁，有问题可以尽早发现、尽早修复，可以避免将这些问题代入到生产中。我们主要是从开发安全、构建交付安全、数据安全、以及应用运行安全等几方面进行安全防护的：
在开发安全方面，主要是进行代码的安全检查扫描、SQL 注入检测、以及代码质量的扫描门禁。
在构建过程中，主要进行依赖的漏洞扫描、开源协议的扫描、开源漏洞的扫描以及镜像漏洞的扫描。
在数据安全方面，主要是数据审计和数据库的高危操作，以及脱敏流程。
在应用运行方面，主要是容器的安全运行防护、应用的提前检测、容器命令的审计、以及 WiFi 隐私安全防护。
通过这几个方面的安全能力组合，可以有效地避免将安全问题带入到生产中，从而降低了整个生产安全的威胁。
开发安全主要是通过代码质量、代码审计、开源扫描、以及移动端的 APP 安全扫描形成一个综合分数，在项目纬度上进行统一的展示，用户可以比较直观地看到自己的项目风险等级。平台在提供扫描的同时，也会提供一些修复建议，因此我们的研发和安全人员可以参考这些信息来解决程序中的安全问题。
在构建交付安全方面，主要是在流水线中插入各种扫描环节。在镜像扫描部分，主要是对镜像中涉及到操作系统、中间件依赖、以及程序本身的文件系统等不同层面进行扫描，通过增量的、批量的、以及全量的安全扫描来给出一份安全报告。如果这份报告的得分较低会被门禁系统卡到流水线之外，只有通过安全扫描的镜像才能够同步到生产环境中去，这种方式能够有效地避免在生产运行中出现安全漏洞。
在数据安全方面，尤其是在数据审计方面，还是需要前置到开发环境中。在敏感 SQL 审核、数据的脱敏方面，一般会伴有程序的开发调试，如果是在生产环境中发现这种问题，然后再反馈到开发环境中，整个过程会比较长。而我们通过在开发环境中内置 SQL 扫描、脱敏数据扫描，有利于在开发环境中前置处理好这些问题。在自动化测试方面，需要解释一下测试数据，我们从开发环境中将相应的一些数据经过脱敏处理之后导入到测试环境中，对于提升测试的整体质量而言，效果还是比较明显的。
接下来，将会介绍我们在 Serverless 方面的一些云原生实践。
从我们自己的理解来看 Serverless 平台，首先它是一个平台，同时也是一种思想理念。Serverless 更多的是用户提交了一小段代码，通过这一小段代码，我们在平台上将它补充成为一个完整的容器，比如容器内的 Dockerfile、打包进来的整个运行环境，从而形成一个完整的镜像。这个完整镜像其实是独立运行的，但是我们给到用户的只是部分，可能只是将用户的业务代码进行上传，在这个过程中，我们可以在基础环境、标准化的配置、Dockerfile 等方面进行不同的能力切入，比如运行参数的优化、平台参数的配置、资源用量的管理，而且还能提供一些统一的升级管理手段。
不仅如此，由于这些配置都是在平台上统一配置的，对于 ARM、X86，业务是高 IO 的，还是高 CPU 的，对于这些不同的特殊情况，我们都可以在后台为用户的应用进行统一的调度管理，经过这个过程，用户提交的还只是他自己的业务函数，但是我们会在平台级帮它提供更多的功能。
在开发过程中，一般需要进行不断的开发调试，对于 CD 的过程，其实会要求更加的迅速。针对这种开发过程不断连续的调试部署，我们推出了一个 GitOps 的管理平台，GitOps 能够以版本化的方式将声明式的配置，将应用的编排、构建等等一系列的操作形成流水线，而且是在 Git 中进行版本化管理，不同的环境中都使用相同的声明式配置。它也是非常方便的一种部署方式，我们目前提供的这种 GitOps 管理主要有两种：一种是提供了界面的引导式，能够满足初学者对界面操作的使用诉求；另一种是提供纯粹的 YAML 提交方式，一些高级的研发运维更习惯于直接去操作 YAML 文件，以进行应用的编排管理。这两种方式，不管是针对初级的用户，还是高级的用户，在使用上都是非常方便的。
谈到弹性能力，Serverless 平台本身也有比较丰富的弹性参数，我们平台在这方面也进行了更多的一些拓展，比如基于业务指标的节点级弹性以及集群级的弹性。如果按照副本数，当到达一定的极限之后，是需要往资源池里加机器的。我们平台对这种弹性能力进行了拓展，如果是在加机器的情况下，或者是在某一区域负载不够用的情况下，我们也可以在其他区域进行整个集群级的弹性，所以我们现在能够实现 Pod 级、Pod 实例级、Node 节点级、以及 Cluster 集群级等三种级别的弹性能力。
在 Serverless 方面，大家比较困惑的一点就是如何进行云端的开发调试，我们平台现在不仅提供了云 IDE，也会将集群的一些管理权限、控制权限、以及网关调试权限等等一系列的相关调试都给到租户。
前面也提到过，Kubernetes 开发环境也是由我们统一管理的，在这种统一提供的开发环境中，我们有些集群是进行了安全隔离的，经过这种安全隔离的集群，我们是可以将一些相应的开发调试管理权限开放给租户的，这样用户在使用过程中，一方面有云 IDE，可以把云 IDE 装到它所在的集群中，也可以利用 Kubernetes 这种原生的管理能力进行本地的开发调试。并且我们对网关以及微服务都提供的一些支持，这几个不同的层面都能满足用户对于 Serverless 应用的开发调试需求。
得益于我们前面提到的统一代码托管流水线，并且为应用进行了 Dockerfile 的构建收敛，我们可以利用 ARM、X86 双平面的环境，为用户提供这两个平面下的镜像构建。用户提供一份代码，但我们会帮它编译成这两种运行环境的镜像，这样在国产化的进程中，用户的代码不需要太多的改造就能够适配这两种运行环境，也有利于我们加大对国产化的支持力度。
在国产化方面，主要是从我们平台级进行了一些兼容适配，比如硬件、操作系统、容器、以及中间件，我们平台级对这些方面都进行了兼容适配，通过这种兼容适配，业务系统只需像使用 X86 的场景一样去使用即可。所以在整个过程中，我们通过 Serverless 能够将更多的适配细节隐藏到平台之中，对于应用而言，它可以更多地关注于自己的业务逻辑，从而降低了对国产化适配的难度。
接下来，我们主要谈一下盘舟 DevOps 平台的未来演进方向。
通过我们自己在开发过程中引入低代码，能够切实地感受到在不少场景下开发交付效率都有了大幅的提升，保守估计，很多场景下的提升达到了 30%，甚至是 60%～70%。
低代码的开发模式，将传统的开发模式需配备产品经理、需求、UI、设计等等一系列专业人员，转变为了只需配备相应的业务分析人员即可。低代码开发模式极大地提高了软件的生产效率、质量和安全，也有助于打破 IT 人员的一些沟通壁垒，尤其是在跨厂商、跨部门、跨系统的协作方面，解决了这种“周期长、门槛高、适应性差”的传统开发模式。
通过我们一段时间的使用，总体的感受是在低代码的开发模式下，开发交付效率已经有了大幅面的提升，原来很多业务逻辑是需要写到代码中，使用了低代码之后，很多业务逻辑可以通过可视化编排的方式来实现。这个过程也极大地降低了对开发的要求，原来需要比较专业的人员进行开发、架构、设计、测试，现在就不需要这么专业的人员了，只要有一定基础的人员即可掌握如何通过可视化的方式、如何通过编排的方式来实现新的功能，并进行一体化的开发、交付、测试，从而降低了整体的从业门槛。
通过上图，大家可以感受一下，在我们的业务场景中，原来从用户认证，到过户校验，再到最后的生产上线，这个过程相对还是比较清晰地，但是在我们分析完成之后，就会编写具体的业务代码，在编写代码时，会按照图中中间部分的模式对更多的业务逻辑进行拆分以及组合，在这个过程中，从某一个层面来看，基本上已经很难体现原有的这种开发过程了。
但是在我们低代码的开发过程中，在每一个层中，具体的业务逻辑体现如右侧模式图所示，它是中间模式图中的一个个原子能力，对这些原子能力的编排又能还原成了最左边的业务逻辑图。通过这种可视化的编排方式，整体的业务逻辑还是能够体现出来。
结合 Serverless 来看，低代码编排的服务更多的就是微服务，甚至是更小颗粒度的原子级服务。而我们的 Serverless 平台主要就是把函数级的原子服务直接发布为运行态，提供调用接口。
这些函数级的能力是否可以使用 Serverless 来进行开发和发布呢？其实这两者是可以比较流畅地结合在一起的。Serverless 负责提供底层、函数级、原子级能力的运行、维护、以及弹性；低代码负责对这些接口进行编排，进行使用。在这种模式下，用户不用关心底层的资源，通过平台自动地发布上线、按量弹性扩缩容，降低了整个项目的开发以及运营成本，也减少了运维难度和工作量，整体迭代的上线周期也能得到提速。
通过磐基磐⾈低代码，为业务系统带来了快速上线、接口的可视化编排、新场景的场景化应用能力。而 Serverless 平台则解决了后端接口、微服务应用和原子级应用的按需弹性、稳定运行。它们两者结合形成了一个新的开发组合，能够使我们整个部门的开发更加简单，运行更加稳定，服务更加弹性。
以上是我今天的主要分享内容，感谢大家的观看收听，谢谢！
往期推荐
-
小孩也能学会的 Kubernetes 绘本教程
-
优秀的 Shell 运维脚本鉴赏 -
阿里 Nacos 高可用集群部署 -
神器 Nginx 的学习手册 ( 建议收藏 ) -
K8S 常用资源 YAML 详解 -
DevOps与CI/CD常见面试问题汇总
-
我会在Docker容器中抓包了！ -
19 个 K8S集群常见问题总结，建议收藏 -
9 个实用 Shell 脚本，建议收藏！ -
详解 K8S Helm CI/CD发布流程 -
一台服务器最大能支持多少条TCP连接？ -
K8S运维必知必会的 Kubectl 命令总结
-
16 张图硬核讲解 Kubernetes 网络
-
史上最全 Jenkins Pipeline流水线详解 -
主流监控系统 Prometheus 学习指南
点亮，服务器三年不宕机