现代化应用在不少场合与云原生应用的概念是等同的，因为它们的很多特征都是相似的，比如，都采用了容器技术打包和交付，都具备很强的弹性能力等。这两个概念的细微差别在于：现代化应用可以与云相关，也可以与云不相关；而云原生应用通常都与云相关。

      所以云原生（或者说云原生计算）应当包括云原生技术、云原生产品、云原生架构以及构建现代化应用的开发理念，如DevOps，具体说明如下。

1）云原生产品和云原生技术需要基于公有云、私有云或混合云的云基础设施（IaaS）。

2）云原生架构和云原生开发理念是基于云原生技术和产品构建或实现的。注意，对于不是基于云原生技术或者产品的架构和理念，如基于传统物理服务器发布、构建的DevOps，是不会被划分到云原生范畴的。

3）现代化应用和云原生应用是基于云原生的架构和开发理念构建或实现的。

1.1.2　云原生是云计算的趋势

• 从技术发展趋势看： 更多企业将会广泛应用云原生技术。在国家政策和企业需求的双重驱动下，更多企业会选择上云，中国云计算的强势增长是必然趋势，这也注定了更多企业将会关注、应用、采纳能够充分利用云计算能力的云原生技术和产品。
• 从软件开发角度看：云原生技术为企业带来了更快进行业务创新的价值。越来越多的企业逐渐意识到了云服务的专业性和高SLA，这些企业在数字化转型的过程中将IaaS和PaaS的通用技术复杂性委托给了云平台，从而能够更好地专注于自身业务逻辑的创新。利用云原生技术重塑企业的软件生产流水线，可以加大业务组件的复用程度，将软件交付周期从周、天降低到小时甚至分钟级别，从而提升业务的市场嗅觉灵敏度，增强市场反应能力。
• 从应用技术栈角度看：越来越多的企业发现传统的应用已经无法满足数字化业务的需要，所以会对应用进行彻底升级，会更多地采用云原生技术和云原生架构作为构建现代化应用的核心框架，从而帮助企业打造具备弹性、韧性、可观测性、API驱动、多语言支持、高度自动化、可持续交付等特性的现代化应用软件。

1.1.3  云原生成熟度模型

1.1.4 云原生架构成熟度模型

二.  拥抱云原生的点点滴滴

2.1　云原生是云计算的再升级

       从云原生的定位可以看到，云原生包含大量新的PaaS层技术和新的开发理念，是释放云计算价值的最短路径，也推动着云计算的再升级。

       整个云原生技术栈都是基于开源、开放的技术标准。CNCF也在致力于云原生技术的标准化，为云原生技术和产品的用户提供使用云服务的标准界面，同时避免了厂商锁定。

       进一步看基于云原生技术和云原生架构重构或重写的应用，比如，基于服务网格或无服务器技术（Serverless）的应用，它们天然具备水平扩展的能力，可随时应对互联网时代高速增长的业务规模，同时还内置了高可用能力，所以应用无须关注分布式环境下的高可用方案。

       对于云平台而言，云原生技术也催生了诸如腾讯云TKE、AWS Nitro系统之类的架构升级，使得新的计算基础设施能够为应用提供更高的性能、弹性和计算密度；云存储能够帮助企业实现存储计算分离，避免分布式环境下多副本存储，同时还具备自定义密钥加密落盘的高级安全特性；基于硬件offload（卸载，通过硬件提供加速功能）的网络在overlay（一种在现有网络架构上叠加的虚拟化技术）的场景下为应用提供千万级PPS（Packet Per Second，数据包/秒，宽带速率）的SDN（Software Defined Network，软件定义网络）能力。

       所以，云原生不仅是对使用云的应用架构的再升级，也是对云平台的技术和云服务的再升级。从构建现代化应用的角度，我们可以发现，云原生对应用的重构体现在应用开发的整个生命周期中。

2.1.1  服务上云

       从2021年1月开始到8月结束，按照BG要求，腾讯文档开始对所有服务按照云原生的规范进行重构，docker化，并逐步将部署在云下的服务迁移部署到STKE上，利用云原生基础设施为应用提供更高的性能、弹性和计算密度.

• 服务上云里程碑

• BG统计结果

        (注：由于比bg要求迁移的核心数多，所以百分比为147%)

• 腾讯文档微服务上云

• 多集群部署策略：同服务同区域多集群部署，异地集群部署

• 服务Docker化

• STKE

2.1.2  Workload配置优化以及容器的启动/更新/回滚优化

Workload配置优化参考我的KM：

• 内核参数优化： https://km.woa.com/articles/show/490258
• HPA的最佳实践： https://km.woa.com/articles/show/473944
• STKE中workload设置的场景实操：https://km.woa.com/articles/show/473576

启动/更新/回滚优化：

• 腾讯文档mini镜像使用测试( https://doc.weixin.qq.com/sheet/e3_ABYA0QbtACgXcNH1bu6TveUxDFN4Q?scode=AJEAIQdfAAoWKw9OZXABYA0QbtACg&tab=0jan3a )
• 腾讯文档容器preStop优化专项报告( https://doc.weixin.qq.com/doc/w3_ABYA0QbtACgN6no1L9DSF0bezhvp7?scode=AJEAIQdfAAo3BnNLr0ABYA0QbtACg )
• 腾讯文档容器启动延时优化报告( https://doc.weixin.qq.com/doc/w3_ABYA0QbtACgg5CHtXGlSSiFSUWU1Z?scode=AJEAIQdfAAoGcCXxWfABYA0QbtACg )
• 容器启动优化测试报告 ( https://doc.weixin.qq.com/doc/w3_ABYA0QbtACgrH90D4cRTNKciA2KBx?scode=AJEAIQdfAAoLMd5TeOABYA0QbtACg )

优化后的结果：

• 更新/回滚镜像：由原来的单pod 3分钟优化到如下结果

              STSP: eks 46-56s， tke: 56-70s ,

              Deployment: EKS/TKE 90s 左右

• pod重建: 由原来的单pod 5分钟优化到如下结果

              STSP（EKS/TKE）90s左右

              Deployment： 90s左右

2.1.3  使用云原生中间件

      从2021年3月开始，腾讯文档逐步将中间件替换成云原生或腾讯云推荐使用的云原生中间件，目前购买的是腾讯云TDSQL,Redis,ES,Mongodb,Kafka，下面以TDSQL为例：

2.1.4  环境治理和重塑研发流水线

具备持续发布的能力，是众多软件企业的目标之一，但持续发布需要面临诸多挑战，例如配置基线、版本管理和自动化等。特别是当应用具有多个不同的硬件环境、OS或者第三方软件/库依赖的多个组合时，如何进行有效的变更管理才能保证任何微小的变化都不会使这些组合出现错误呢？我们经常遇到的问题之一就是，开发人员在本地环境中运行和测试时都是正常的，但是一旦部署到测试或者生产环境中，就会因为依赖的第三方软件或库的配置问题，导致软件不能正常工作。

容器可用于对制品进行打包和分发，即结合GitOps和不可变基础设施，可以实现软件运行环境的整体化部署。换句话说，对运行环境的任何变更，都必须提交到Git中，经过版本管理后重新持续集成，形成新版本的制品并进行部署。这样做的好处是，关于软件运行环境的所有变更都有迹可循。任何时候我们都可以查找（checkout）需要的版本，通过脚本构建出对应的制品。如果代码和脚本本身没有错误，那么整个构建过程就会非常顺利，并且是可重复的。如果某次变更后软件运行出现异常，可直接根据Git上的记录回溯到上一次正常运行的版本，重新进行部署。

整个过程不仅高度自动化，而且具备版本跟踪和回溯机制，也解决了上文提到的持续发布的挑战问题，减少了CI/CD中的错误发生概率，从而提升了整体的质量和效率。这样的研发流水线，虽然不一定具备7×24的发布能力，但也可以在软件实现新的功能后马上基于某个基线连续自动发布或者回滚。

• GitOps的整体规划

• 腾讯文档环境治理

• 腾讯文档新CICD pipeline的流水线

1. 利用OCI完成CI pipeline

2. 利用TF完成CD pipeline

2.1.5　重新定义软件交付模式

云原生软件交付模式主要有如下几个变化。

1）利用容器做整体交付。整体交付减少了容器内部组件之间的安装配置工作，随着容器及编排的开源和普及，更多硬件得到支持，使得容器成为软件交付的标准“底座”。这种标准“底座”加整体交付的方式，极大地降低了安装配置的错误风险。此外，还可以通过工具（如Terraform）和脚本自动完成软件交付，提升交付的效率。这就像购买组装家具一样，顾客更期望得到的服务是厂家到家里将家具组装好，以免自己在组装时出现错误。

2）将Git作为“Single Version of Truth”（唯一真实版本）。Git作为交付和运维的仓库，记录了所有软件变更的版本、配置参数、脚本、用户名和密码等信息，同时所有脚本、工具和Kubernetes的Operator，都读取Git中的信息作为事实的唯一来源，即使是做版本升级或回滚，以及变更评审，都以Git中的信息为准。

3）声明式API。很多软件交付都是“告诉”系统需要做什么，特别是脚本中往往会写明如何进行部署；而声明式API首先是“告诉”系统期望的目标状态是什么，比如，在这种环境下部署需要用到两个实例，其次才是脚本或工具需要做什么才能交付这个目标状态（即如何做）。声明式API本身并不复杂，实际上它是一种开发理念的彻底升级，因为系统更多的是关注需要什么（达到什么状态），所有的“如何做”都是围绕这个目标状态来服务的。

4）尽量采用OpenAPI作为系统间的集成方式。标准化的OpenAPI更有利于系统间的集成，因为OpenAPI有明确的契约描述或接口规格描述，且提供了各种开放的工具，可以用来做IoT（连通性测试）SIT（集成测试）等。同时，由于其开放接口（比如，基于RESTful）的特性，可以实现快速集成，从而提升集成的效率。

• 新CI后台流程图

• 新CD后台流程图：

• 整个CICD的方案流程图

• 新CICD的效果

2.1.6    工具链和平台的建设

• 中间件云监控

• 资源配额机器人

• Workload和POD实时监控大盘

• 配套的dashboard，发布工程师和oncall工程师通过发布视图进行服务版本，发布行为的追踪.

2.1.7　运维模式的升级

       配置变更是运维场景下的高频操作。针对配置变更，云原生的理念是提倡采用不可变的基础设施，即任何变化都是基于容器重新生成一个镜像来进行部署，而不是在原有环境下直接变更配置，也就是说，基础设施是只读的。这样做的好处是任何变更都是可版本化的，因此也就更容易维持变更的质量，从而避免各种未记录的变更给系统带来不可知的影响。当然，对于大型系统而言，变更的相互影响也是非常大的，因此建议一个环境不要只用一个大的镜像，而是将大环境分成若干个小环境，从而避免出现每个小环境发生变化时需要将整个大环境全部重新做镜像和部署升级的问题。

       从2021年1月开始，腾讯文档根据是否为开关配置逐步将开关配置迁移到七彩石，非开关配置收归于代码仓库(CAC)中，

       1. 七彩石开关配置：

                  保证配置文件的修改必须进行code review，审核人审核

                  保证发布走单实例到全量的灰度发布

       2. 非开关配置：Configuration as Code

                  保证配置文件的修改必须进行code review

                  保证从低环境到高环境的灰度发布       

2.1.8　组织结构的升级

       云原生的升级还会涉及IT文化的升级以及IT组织结构的升级。一个企业中的IT文化，实际上是开发、运维等IT人共同认可和遵守的工作流程、知识体系、工具集的总和。云原生作为一种全新的计算模式，带来了工具集的升级、知识体系的更新和工作流程的改变，也变更了企业的IT文化，从瀑布模型到DevOps不适应，产生新的技术债务，甚至部分岗位会被淘汰（如大机运维人员）和产生新的岗位（如SRE，Site Reliability Engineer，网站可靠性工程师），等等。这些变化都可能会对企业的IT部门产生巨大的影响

       腾讯文档从2021年成立架构和工具链组，其工作职责不仅包含了SRE的方方面面,  还肩负着腾讯文档服务云原生建设，Devops建设(CICDCOCTCE)，高可用建设，基本架构建设以及效能方面的协助工作的重任,  2022年的目标：文档C端SLA 99.95%,B端99.99%， MTTR 2小时内

三. 云原生架构的价值

3.1 云原生架构的定义

       云原生架构的目标更简单，主要是帮助企业改善软件的架构，使其能够快速、有效地享用云计算提供的各种服务，提升软件的交付效率，降低软件的整体成本，提高软件的交付质量。在这个框架下，很多基础的软硬件环境等都由云厂商提供，且它们提供的云服务往往都包含业界最佳实践的产品及解决方案。云厂商所具备的大量行业属性的文档也可以作为模板供企业参考，以便企业能够更好地梳理相关流程，实施这些云服务。

       云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在帮助企业和开发人员充分利用云平台所提供的平台化能力和弹性资源能力.

对比传统架构与云原生架构，可以清楚地看到两者的区别。

       1. 云原生架构可以最大化地剥离云应用中的非业务代码部分，从而让云设施接管应用中原有的大量非功能特性（例如，弹性、韧性、安全、可观测性、灰度等），使业务能够摆脱被非功能性业务中断的困扰，同时具备轻量、敏捷、高度自动化等特点。

       2. 云原生架构可以通过与基础设施深度整合与优化，将计算、存储、网络资源管理以及相应的自动化部署和运维能力，交由云基础设施执行，应用自身会因此变得更为灵活，且具有弹性和韧性，从而大大降低管理成本。

3.2 云原生架构能为企业带来什么价值

3.2.1 降低研发成本和项目维护复杂度

       相较于传统架构，云原生架构强调业务研发应充分利用云平台所提供的IaaS和PaaS的通用能力。虽然云计算不能解决所有的非功能性问题，但是云平台确实能够处理大量的非功能性问题，特别是分布式环境下的复杂非功能性问题。以最具挑战性的高可用性为例，云平台在多个层面为应用提供了解决方案

（1）虚拟机层面

       当虚拟机检测到底层硬件异常时，可以自动将应用热迁移，且迁移后的应用无须重新启动就具备对外服务的能力，应用对整个迁移过程甚至都不会有任何感知。

（2）容器层面

       有时，虽然应用所在的物理机运行正常，但应用由于自身的问题（比如，出现Bug、资源耗尽等）而无法正常对外提供服务。对于这种情况，如果采用容器，就能够通过监控探测到进程的异常状态，从而实施异常节点下线、新节点上线和生产流量切换等操作。整个过程自动完成，无须运维人员人工干预。

  腾讯文档所有服务都配置云原生标准的检查机制，并完成参数优化

•        POD自动重建

•        POD配置自动迁移，当母机出现瓶颈，POD将完全自动化的迁移到其他低负载的母机上

•        Workload和POD的监控告警，可以7*24小时对服务的健康度进行监控，告警，并在达到一定阀值时上升到oncall

（3）云服务层面

       云服务具备极强的高可用特性和7×24小时服务能力，如果应用把“有状态”部分（如缓存、数据库、对象存储等）全部交给云服务，加上进程内存中全局对象的持有小型化和应用快速重构能力（比如基于快照快速恢复到最新状态），那么应用本身就会变成更轻量的“无状态”应用，从而使可用性故障造成的业务中断时间降至分钟级；如果应用采用的是N-M对等架构模式，那么结合负载均衡产品则可获得几乎无损的高可用能力。

       借助云原生架构，业务研发可以降低原本大量耦合的非业务逻辑占比，缩减业务代码开发人员的技术关注范围，并通过云平台提供的服务提升应用的稳定性和可持续发展性。

腾讯文档所有的中间件都配置云原生的监控告警能力，可以7*24小时对中间件进行监控，告警，并在达到一定阀值时上升到oncall

3.3.2 加快软件迭代速度，降低管理和运行成本

（1）面向单机资源变为面向云服务与云API研发

       云原生架构对开发人员的最大影响就是，它使编程模型发生了巨大变化。如今，大部分编程语言都包含文件、网络、线程等元素，这些元素虽然为充分利用单机资源带来了好处，但也增加了分布式编程的复杂性，因此市场上不断涌现出大量的框架和产品，意在解决分布式环境中的网络调用、高可用性、CPU争用、分布式存储等问题。而在云平台中，“获取存储”变成了若干个服务，比如，对象存储服务、块存储服务和文件存储服务的访问和使用等。

       云原生不仅为开发人员提供了解决上述问题的技术支持，而且通过OpenAPI及开源SDK，提供了解决分布式场景中的高可用性、自动扩缩容、安全、运维升级等诸多挑战的界面。开发人员不用再关心诸如节点宕机后如何在代码中将本地保存的内容同步到远端，或者当业务峰值到来时如何对存储节点进行扩容等问题；运维人员也不用再考虑诸如在发现零安全天问题时如何紧急升级第三方存储软件等问题

（2）高度自动化的软件交付能力

• 腾讯文档B端CD交付能力流程图

•  腾讯文档C端CD发布交付能力流程图

• 腾讯文档C端发布流程

• 自动化CD发布能力说明

四. 云原生的发展趋势(内*外*技术)

4.1 云原生的发展趋势

4.1.1 无处不在的计算需求催生新一代容器运行时

       随着5G、AIoT等新技术的普及，随处可见的计算需求不断涌现。不同的计算场景对容器运行时有不同的需求。Kata Container、Firecracker、gVisor、Unikernel等新的容器运行时技术层出不穷，分别解决了安全隔离性、执行效率和通用性三个不同维度的需求。OCI（Open Container Initiative，开放容器计划）标准的出现，使得不同的技术可以采用一致的方式管理容器生命周期，从而进一步促进容器引擎技术的持续创新

4.1.2 云原生操作系统的发展

       随着Kubernetes逐渐成为容器领域的事实标准以及其在不同场景的不断发展，Kubernetes已经成为云原生时代的操作系统。Kubernetes的发展历程和特性与Linux有着诸多相似之处。如图8-2所示，对比Linux与Kubernetes的概念模型可以发现，它们都是定义了开放的、标准化的访问接口，向下封装资源，向上支持应用。

       Linux与Kubernetes都提供了对底层计算、存储、网络、异构计算设备的资源抽象和安全访问模型，可以根据应用需求调度和编排资源。Linux的计算调度单元是进程，调度范围限制在一台计算节点上；而Kubernetes的调度单位是Pod，调度范围是在分布式集群中，甚至可以跨越不同的云环境。

       过往在Kubernetes上运行的主要是无状态的Web应用。随着技术的演进和社区发展，越来越多的有状态应用、大数据和人工智能应用负载正逐渐迁移到Kubernetes上。Flink、Spark等开源社区以及Cloudera、Databricks等商业公司都开始加大对Kubernetes 的支持力度。Kubernetes的技术价值也会在以下四个方面集中展现

                                    Kubernetes逐渐成为云原生操作系统

   （1）统一技术栈，提升资源利用率

            多种计算负载在Kubernetes集群上统一调度，可以有效提升资源的利用率。Gartner预测“未来3年，70%的AI任务会运行在容器和Serverless上”。AI模型训练和大数据计算类工作负载需要Kubernetes提供更低的调度延迟、更大的并发调度吞吐率和更高的异构资源利用率

            腾讯文档一直在努力通过自动化工具来完成资源阀值的计算，以提高资源利用率和增强系统的稳定性. Eg： 

•             Pre-stop采用脚本动态设置容器可以关闭的时间

•             STKE集群剩余配额自动统计，以便后续的自动扩缩

   （2）统一技能栈，降低人力成本

            Kubernetes可以在IDC、云端、边缘等不同场景中进行统一部署和交付。云原生提倡的DevOps文化和工具集可以有效提升技术的迭代速度并降低人力成本。

            1. 腾讯文档所有服务已经完全上云，完成云原生化建设

            2. CD采用TF直接调用STKE提供的API自动化完成服务的部署

            3. Workload统一采用K8s原生的类型：STSP(Statefulplus,对原生Stateful类型做了封装)和Deployment

            4. 所有灰度发布按照云原生标准的灰度发布方式

                STSP: 自动分批+批之间设置间隔时长

                Deployment: 自动分批滚动升级，先创建新版本的Pod,然后再删除旧版本Pod

  Devops文化可以参考我的KM文章：

• SRE: DevOps 到底能为我们解决什么问题? :https://km.woa.com/group/46654/articles/show/483687
• SRE：DevOps⼯程师的九阳神功和九阴真经：https://km.woa.com/group/35679/articles/show/487934?kmref=kb_categories
• SRE: DevOps⼯程实践基础-配置管理(宏观篇) ：https://km.woa.com/group/38989/articles/show/485087?kmref=kb_categories
• SRE: 腾讯文档在DevOps中的内建质量: https://km.woa.com/group/35679/articles/show/486038?kmref=kb_categories

   （3）加速数据服务云原生化

            由于计算存储分离具备巨大的灵活性和成本优势，数据服务的云原生化也逐渐成为发展趋势。容器和Serverless的弹性可以简化对计算任务的容量规划，结合分布式缓存加速和调度优化，可让数据计算类任务和AI任务的计算效率得到很大提升。

   （4）容器Serverless化降低运维和资源成本

            Serverless和容器技术也开始融合并快速发展。Serverless化容器，一方面可以从根本上解决Kubernetes自身的复杂性问题，让用户不再受困于Kubernetes集群容量规划、安全维护、故障诊断等运维工作；另一方面还可以进一步释放云计算能力，将安全、可用性、可伸缩性等需求下沉到基础设施中实现。

           1. 从离线业务到在线业务

               按请求次数计费和按启动到结束的响应时间计费之间存在天然的矛盾，这也导致了以FaaS为代表的Serverless技术最初都是从对响应时间不敏感的事件驱动类离线业务入手。

           2. 加速推动基础设施和服务Serverless化

               业务代码托管给Serverless平台后，即可享受自动弹性、按请求计费等功能。

           3. 实现最佳性能功耗比和性价比

              虚拟机和容器是取向不同的两种虚拟化技术，前者安全性强、开销大，后者则正好相反。Serverless计算平台一方面要求最高的安全性和最小的资源开销两者兼得，另一方面还要保持对原有程序执行方式的兼容，例如，支持任意的二进制文件。

           4. 更小的镜像实现更快的分发速度

               Serverless平台要求应用的镜像足够小，以实现快速分发，同时要求应用的启动时间极短。

           5. 解决FaaS状态传递的中间层研究

               由于函数之间串联需要状态传递，函数处理需要与外部存储进行频繁交互，因此未来Serverless在函数场景下的最大挑战是由上述因素带来的时延放大问题。

           6. Serverless和Fass在腾讯文档的使用也是相当广泛

云函数应用

     fiber-test

      6.1 在fiber workflow中无法直接触发 OrangeCI 中的自定义事件，因此使用云函数，将触发时需要的 token 存储在云函数中，根据需要触发对应的 OCI 事件；              

6.2 该函数实现了自动发布和部署，同事总结一篇KM文章 https://km.woa.com/group/46654/articles/show/476979

五. 云原生之路有感

1. 最开始接到上云任务时是什么情景？接到任务后自己心中是什么感受，身边的开发同事是什么感受，这样的感受是否有在后续发生变化？现在对于上云的认知是什么？

       腾讯文档在2021年1月开始进行服务上云计划，其中涉及到传统服务到符合云原生架构服务的重构，服务docker化，线网老服务从云下迁移到云上，CICD pipeline流水线创建等任务，最开始部分同学不理解为什么要花力气走云原生，认为直接部署到织云，物理机上挺好的，本地测试+打包后直接部署，但随着服务云原生的落地，CICD自动化pipeline的成功上线使用，同学们认识到云原生的优势价值，尤其对：无状态服务的自动弹性能力，生产环境中灰度部署能力赞不绝口.

2. 在上云过程中遇到过什么具体困难，怎么解决的？其中最艰难的是在什么时候？业务强需求的产品服务能力有哪些方面，是如何在云上实现的？

      服务上云后需要做很多的参数配置工作，哪些配置应该修改，应该设置什么值一度困扰着我们，比如存活/就绪检查参数，pre-stop参数，内核参数等，于是我们参数分类，然后指定专人对这些参数进行解释，使用场景说明，官方推荐参数值，如果参数与服务或运行时挂钩，就通过多次压测服务来进行综合分析获取符合该服务的最佳值域

3. 通过怎样的手段确保和提升了文档的发版和用户体验？

     1): 保障的核心就是流程+自动化工具，为了提升文档发版稳定性和健壮性，我们制定了详细的BC发布流程

•    腾讯文档C端CD发布交付能力流程图

• 腾讯文档C端发布流程

   2): 为了增加不同维度用户的体验，我们在灰度发布过程中，增加SIT, UAT, Staging和Canary环境

总结：

       云原生拥有传统IT无法比拟的优势，它能从技术理念、核心架构、最佳实践等方面，帮助腾讯文档平滑、快速、渐进式地落地上云之路。可以预测，在未来，腾讯文档将更加倚重云原生的能力，在聚焦于自身业务发展的同时，让更多的开发者基于云原生的技术和产品，提升开发效率，并将精力更多地聚焦于业务逻辑实现。云原生正在成为新基建落地的重要技术抓手，只有提前拥抱新基础设施，才不会被时代淘汰。