极氪汽车 APP 系统云原生架构转型实践

Posted 2023-05-31 阿里系统软件技术

极氪 APP 既是用户智能控车随时随地掌握车况的车主服务好帮手，又能提供购买用车好物、共享社区活动的极致出行用车体验，便于用户获取触手可得的用车信息，让出行变得更加便捷有趣。

作者：极氪汽车

前言

新能源汽车已经成为我国汽车市场再次崛起的关键支柱，随着新能源汽车市场的快速发展，不同类型的品牌造车厂商呈现出百花齐放的态势。极氪汽车是吉利控股集团旗下高端纯电汽车新品牌，2021 年 4 月极氪发布首款高端智能电动车型--极氪 001，大获市场好评，截至 2022 年 12 月，001 车型累计交付量突破 7 万台。连续 3 个月问鼎自主品牌 30 万以上豪华纯电车型销量冠军。

极氪坚持不止于车的服务体验，除了为客户提供卓越产品的同时，还通过极氪 APP 与用户建立连接。极氪 APP 推出线上社区、订阅出行、好物商城、极氪生活等多元创新举措，实现了极氪产品的全生命周期管理以及用户旅程的全场景覆盖。从用户想要了解相关车型，到有意向进行购买、提车使用、分享感受以及售后问题迅捷解决方案等各种环节的使用场景，都被集成到了这款 APP 之上。

“我之前对极氪汽车并不是很了解，极氪这款软件对我的帮助非常大，我觉得这是很好的，同时也在极氪软件里面看到了自己想要买的车，关注极氪已经一年了，不仅可以了解极氪汽车知识_{还能得极分}换商品_{希望极氪多多上新实用商品}” 这是摘自 Apple App Store 的用户评价。极氪 APP 既是用户智能控车随时随地掌握车况的车主服务好帮手，又能提供购买用车好物、共享社区活动的极致出行用车体验，便于用户获取触手可得的用车信息，让出行变得更加便捷有趣。

云原生架构探索的实践历程

云原生技术发展

随着极氪数字业务的飞速发展，背后的 IT 技术也在不断更新迭代。极氪极为重视客户对服务的体验，并将系统稳定性、业务功能的迭代效率、问题的快速定位和解决视为构建核心竞争力的基石。 公司副总裁刘昊表示，为快速响应用户的需求，例如缩短一辆车的制造周期、便捷平滑地升级汽车操作系统等，企业从产品到用户体验到商业模式都需要创新。然而消费互联网和传统产业发展的经验不足以完全满足产业互联网对成本、效率、质量等方面的高要求。云原生是一个确定性的技术发展趋势，能有效推动产业发展，驱动企业积极革新。极氪将持续投入，将云原生能力赋能到企业内的研、产、供、销、三电等更广泛的业务领域。

这些业务现状和云原生架构带来的核心能力不谋而合。

在极氪系统改造上云的过程中，围绕着云原生技术体系，推动极氪的各条业务线进行技术升级改造，加快数智化发展进程。在技术选型上，极氪始终遵循着2条原则：

一是全面拥抱开源开放的主流技术标准：

使用开源开放的主流技术标准，可以确保技术方案的成熟度，更便捷地从开发者社区获取技术资源和最佳实践，也能够帮助企业更好的招募技术人才。此外，这样的策略也避免了被封闭技术体系和特定云厂商所捆绑。软件技术的国产化以及自主可控，也是需要考虑的点。

二是尽可能利用云的价值：

将稳定性保障、底层技术实现、技术组件维护、弹性伸缩等非功能性需求尽可能交给云厂商解决，让技术团队将更多的精力投入到业务创新上。

这 2 个原则并不矛盾，相反，它们之间可以非常好的融合，这也是所有使用云计算的企业用户都值得借鉴的架构选型标准。比如 Kubernetes 是典型的满足开源开放标准的技术标准，阿里云提供的 Kubernetes 产品可以简化用户的搭建成本，更好地与云计算资源进行集成。同时用户依然可以基于开源 Kubernetes 的标准协议与 API 使用云产品，这就是 2 条选型原则相互融合的最好体现。

业务容器化

云原生趋势下，Kubernetes 毫无疑问已经成为了企业新一代云 IT 架构的基础设施。从 2021 年开始，极氪就开启了微服务和容器化改造计划，将 IT 系统的底座逐步从虚拟机迁移到 Kubernetes。

在 Kubernetes 平台的选择上，基于技术选型的 2 条原则，极氪选择了阿里云容器服务 ACK 。ACK 以阿里云可靠稳定的 IaaS 平台为底座，向下封装了 30+ 款云产品，形成了自动化运维和云平台交互的新界面，从而提升企业业务系统的弹性和自动化运维能力。

基于容器服务 ACK 的易用性以及集成能力，极氪 IT 系统容器化改造工作比预想中的要顺利得多。对于每一个业务系统而言，从虚拟机迁移到 Kubernetes ，仅仅是底层的承载发生了变化，不会涉及到太多的改造成本。在容器化改造的过程中，当极氪技术团队遇到疑难问题的时候，可以第一时间从阿里云获得最佳实践指导，包括集群规划、平台运维、应用适配、安全防护、可观测等多个方面，这也更进一步的提升了容器化改造的速度。

目前，极氪 APP 以及 SCRM 等系统，已经 100% 基于 Kubernetes。相比传统的基于虚拟机部署方式，容器化帮助极氪在资源利用率上提升了 20%，在运维效率上提升了 50%。 在 2022 年 9 月通过了中国信通院云原生技术架构成熟度评估， 同时极氪的技术团队也在容器化改造的过程中，掌握了管理超大规模 Kubernetes 集群的能力，并促成了更多云原生新技术的运用。

统一微服务架构

与容器化改造几乎同步进行的是对微服务架构的统一。在此之前，极氪的各个业务单元多种技术栈并存，彼此之间相互通讯复杂度高，项目成员的交接往往要耗费巨大的精力，极大程度上阻碍了数字化转型的进展，因此微服务架构统一势在必行。

极氪经历了 2 年多时间完成了这一项艰巨的工作，虽然投入精力巨大，但收益是立竿见影的，而且可以持续发挥作用：不论是内部团队还是三方 ISV ，在技术框架上都有统一的标准可以遵循，各团队共享技术栈后，研发效率成倍提升。

关系到未来多年的 IT 战略，在微服务架构的选型上，高开放性、高成熟度、高普及度这三条标准缺一不可，考虑到极氪以 Java 为主要开发语言，Spring Cloud Alibaba 就成为了微服务框架的最佳选择。

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。这些组件一部分以 SDK 的形式集成到代码中，一部分以中间件的形式独立运行，后者往往可以选择托管版云产品，以降低开发者的工作量。比如阿里云微服务引擎 MSE 就提升了开箱即用的注册配置中心 Nacos，以及云原生网关。

稳定性和效率问题愈发凸显

可以预想的，随着极氪 APP 的上线，注册车主数量呈现出了爆发式的增长，用户的使用场景也不断扩大。在这个过程中，APP 的用户使用体验变得愈发重要，如何在用户规模高速增长的同时可以保证 APP 的稳定性、敏捷性， APP 的微服务开发效率如何保证，这些都给研发团队带来了一定的挑战。

业务连续性差缺少容量规划

远程控车、在线地图、3C 商城等 APP 核心服务对业务连续性要求非常苛刻，均需保证 7*24 小时持续在线。特别是面临旺季销售活动、新车型发布、突发热点事件等情况，APP 面临着高并发大流量压力，经常会发生功能失效、页面打不开、延迟过高，甚至 APP 完全无法访问的异常，对用户体验造成严重影响。

功能版本发布迭代速度慢

随着用户场景需求的增加，越来越多的功能等待发布上线，对迭代频率的要求越来越高，但由于 APP 服务端缺少全链路灰度发布能力，为了保障业务稳定性，每次发布客户只能选择在凌晨的业务低峰期进行，开发、运维、测试同学苦不堪言，急需实现随时发版无损发布能力。

技术架构缺少整体设计

公司成立之初，为了实现 APP 快速上线，对于技术架构整体设计考虑不足，体现在业务间高度耦合、系统链路过长、技术实现标准不一、云产品选型不合理等诸多问题，例如通过调研发现某核心接口请求链路过长，导致延迟抖动率很高，影响用户使用体验。

研发团队意识到，随着业务发展的向好，这些挑战也会也越来越大。在业务快速发展中，既要保证好已有业务的稳定性，又要快速地迭代新功能，并且需要保证开发的效率并不会随着业务增长而大幅降低，毕竟存在团队招聘节奏跟不上业务发展的问题。总结来说，团队解决 APP 应用快速迭代演进的关键就是解决稳定性与效率的问题。

• 稳定性： 用户数多起来之后，系统的稳定性就显得比较重要，无论是用户在某段时间遇到异常报错增多，还是某一个功能点持续性地报错，再大到系统有一段时间完全不可用，这些都会影响产品在用户中的口碑，最后这种完全不可用的场景，甚至还可能成为微博等社交网络上的舆论热点。
• 效率： 随着用户的增多，相应的需求也越来越多，业务场景也越来越复杂，在这个时候测试可不是内部测试就能覆盖所有的场景，需要加大在测试上的投入。虽然功能需求越来越多，但是迭代的速度却要求越来越快，因为市场中已经有不少竞争者，大家竞争的一个关键就是速度，业务更需要跑得更快，开发节奏要快，测试节奏要快，发版节奏也要快。

针对以上问题，研发团队根据业务架构从流量入口到微服务再从全局视角进行微服务的系统优化与调优，围绕着成本、稳定性以及效率进行深入的微服务化探索。

业务链路入口升级

极氪架构中的网关架构并不一致，各种网关都起了一定的作用。我们可以从上图中看到流量网关、API 网关、微服务网关等众多网关存在，他们具备了安全（WAF）、API 管理、流量分发等作用，思考一下，如果一个请求链路经过多个网关，那么这个事情对成本与稳定性都有一定的挑战。

在这个时候 MSE 云原生网关出现在研发团队的视野中，云原生网关将流量网关（Kubernetes Ingress、Nginx）和微服务网关（Spring Cloud Gateway、Zuul 网关等）二合一，降低 50% 资源成本，同时缩短了请求时间，降低运维复杂度。

作为面向南北向的公网网关，使用 Waf 防护异常流量是很常规的需求，而且随着互联网环境变得越来越复杂，用户对防护的诉求是持续增强的，常规做法是将流量先接入Waf安全网关，过滤后再将流量转发给流量网关，最后到达微服务网关；那么升级云原生网关后，进一步需要思考的事情是，入口流量的安全能力是否还可以具备？

云原生网关通过内置 Waf 模块直接对接阿里云的 Waf 云产品，使得用户的请求链接只经过云原生网关就可以同时完成 Waf 防护能力，大大降低了网关的运维复杂度，图示如下：

网关作为链路流量的入口，除了安全能力之外，还承接着入口流量/容量的管理、高可用等职责。

微服务高可用探索

无损上下线，提升微服务稳定性

客户 APP 应用使用的是微服务架构，当进行业务发版、弹性扩缩容等场景时，会遇到请求失败率升高，POD 不断重启等问题。针对此问题，结合 MSE 产品能力，通过应用下线过程中自适应等待和主动通知、应用上线过程中就绪检查、服务预热等手段，实现微服务无损上下线发布，有效规避了发布过程中的流量损失，降低业务访问失败风险。同时通过引入MSE流量防控能力，针对核心业务场景落地相应技术手段，如接口限流降级、MQ 削峰填谷、数据库慢 SQL 限流治理等，提高服务整体稳定性。

水平拆分，提升业务弹性伸缩能力

随着业务的快速发展，极氪 APP 原架构下容量不足问题愈发突出，在面对新车发布、销售活动、突发热点情况时，无法快速进行水平扩展，并且大量核心业务库都放在同个数据库实例上，容易出现“一损俱损”。阿里云服务团队推荐使用 Polardb-X 产品，将业务库逐个剥离出来，并通过对业务大表水平拆分解决单表过大问题，提高数据库层面水平弹性扩容能力。另外针对微服务弹性能力不足的痛点，输出多可用区节点弹性伸缩、HPA、CronHPA 等容器弹性方案，提高核心服务在流量突发情况的应对能力。

流量防护与容错

想象一下，在业务高峰期，当某些下游的服务提供者遇到性能瓶颈，甚至影响业务。极氪 APP 团队正是遇到了这样的问题，在某次架构迁移的过程中，遇到预料之外的慢调用，拖慢了系统，导致整体稳定性的抖动。如何避免这类问题？需要对部分非关键服务消费者配置一个熔断规则，当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，后续一段时间服务调用直接返回 Mock 的结果，这样既可以保障调用端不被不稳定服务拖垮，又可以给不稳定下游服务一些“喘息”的时间，同时可以保障整个业务链路的正常运转。

突发的事情是非常多的，那么如何可以做好系统的高可用，让系统在不确定的情况下工作在最优解上？极氪 APP 团队先尝试对 APP 大的层面做微服务稳定性治理，避免出现 APP 整体宕机的情况。然后对核心服务和接口做梳理，摸清上下游，对强依赖解耦和改造，并且根据监控、可观测数据，确认核心服务配置什么合理参数。在这之后，多次对服务进行限流降级配置以及演练、优化，总结场景实践规律，制定恰当的技术规范。

开发测试效率提升：在线服务测试

极氪开始在云上进行部署、发布、测试之后，他们遇到了如下问题：

1. 部署完应用之后，应用是否健康？当线上出现了一个问题，怎么能够快速发起一次请求，进行复现。

2. 在服务上线之前，如何快速地验证历史功能是否都正常？

3. 大版本上线前，修改的内容对性能有什么影响，上量之后会不会服务压力过大？

4. 为了做到安全隔离，研发环境、测试环境、预发环境、生产环境部署在不同的专有网络 VPC 内，如果自建测试工具，需要解决测试工具到不同环境的网络互通问题，企业 IT 人员明明只想要一个简单的测试工具，却因为上云之后，要解决复杂的云上网络拓扑，远远没有结束，为了能够在办公网使用该测试工具，还需要保证该测试工具能够被办公网访问，此时又面临着网络安全的考验。

5. 云上的服务测试、压测就是为了解决这个问题 。 借助 FC 的弹性计算能力，一方面打通了云上网络打通的问题，另一方面随用随弹，最大程度解决资源利用率的问题；借助服务契约提供的内容，服务测试功能可以自动填充测试参数，测试时只需要进行值的修改，就可以发起测试。还可以根据提示将服务测试进行串联，从而达到自动化回归、压测的目的。

全链路治理

全链路灰度发布，实现白天随时发版

随着极氪汽车销售越发火爆，其注册用户和每日活跃用户快速增长，需要支持的业务场景和新功能也越来越多，平均两三天一个小版本、半个月一个大版本的升级频率。为了不影响白天业务高峰，每次发版只能选择在凌晨业务低峰期进行，想象一下如果研发/运维人员每次都集中在晚上发布，那么这些参与发布的同学第二天的工作效率将会受到影响；如果晚上选择较少的人参与发布，那么当出问题的时候止血措施很可能会来不及实施，故障责任也不好划分。

阿里云服务团队帮助极氪团队一起制定和落地全链路灰度发布方案，通过部署灰度版本，并按照流量比例或客户特征进行灰度验证，验证完毕后进行生产发布并切流，满足了客户小版本白天随时发布的诉求。针对客户核心业务链路上多个微服务同时需要发版的场景，基于 MSE 云原生网关和流量灰度打标来实现多业务的全链路灰度，覆 CDN、网关、MQ、配置、数据库等灰度场景，通过这种方式让客户在不需要更改任何业务代码的情况下实现多业务白天发版，同时通过逐步流量放大进行验证，如出现问题可及时回切流量，降低了白天发布可能导致的稳定性风险。同时通过改造云效流水线，帮助客户实现核心业务自动化发布，更好地提升部署效率。

开发环境隔离

微服务的迭代存在非常多的依赖，业务的开发人员无法在本地完成开发，必须使用一整套完整的环境，才能正常的进行开发和联调。极氪 APP 系统中的应用数目有数十个，如果每一个开发环境都维护一整套 APP 系统所具备的微服务环境，需要消耗大量的人力以及资源的成本。

理想中的开发环境逻辑隔离应该是这样的，基于 git-branch 的设计理念，保留一套稳定的基线环境，各个分支的开发同学通过逻辑环境隔离的方式快速拉起需要开发的 feature 环境。我们只需要维护一套完整的基线环境，在增加 feature 开发环境时，只需要单独部署这个 feature 所涉及到改动的应用即可，而不需要在每个 feature 环境都部署整套的微服务应用及其配套设施。其中，基线环境包含了所有微服务应用，也包含了服务注册中心、域名、SLB、网关 等其他设施，而 feature 环境中只包含了这个 feature 中需要修改的应用。这样维护 n 套 feature 环境的成本，就变成了加法，而不是原来的乘法，由 n × m 变成了 n ＋ m。这样算下来相当于零成本增加 feature 环境，这样我们就可以放心地扩容出多套 feature 环境。极氪团队使用微服务治理中的全链路灰度方案实现“流量泳道”，做到快速拉起隔离的开发环境，在提升研发效率的同时节省了一笔不菲的成本开销。

全链路压测与调优

为了摸清楚 APP 能够真实承载的并发容量，需要对核心业务接口进行多轮全链路压测和调优。对于系统容量评估、优化与防护主要概括为四点：压测、观测、限流、扩容。系统高可用体系建设必须从实践中出真知，极氪团队通过压测对 APP 服务能力进行性能摸底，评估性能是否能接受。如果性能不能接受的话那么需要对性能进行扩容和优化；性能符合预期，那么要配置对应的限流规则，以防超出预期的流量将服务打垮。

整个压测演练的过程中需要做到边压、边看、边限、边扩，不断对对数据进行反馈调整，最终建立保证业务系统高可用的体系。通过全链路压测，不仅让大家对 APP 系统的性能、容量做到心中有数，更增强了整套生产系统升级至云原生架构的信心。

未来展望

极氪 APP 进行云原生架构升级探索，提高了 C 端业务系统的稳定性和敏捷性，为冲击更高的销量目标提供了坚实的技术支撑。这仅仅是探索的开始，随着云原生架构的深入，业务的可用性将持续增强，从而为汽车终端用户带来更好的出行体验和乐趣。

新书《OpenShift云原生架构：原理与实践》第一章第二节：PaaS赋能企业数字化转型

 

 

 

随着云计算的深入发展和IT技术架构的大变革，企业数字化转型已经步入深水区。初期，伴随数字化转型的是云计算三大模式中的IaaS和SaaS，然而随着转型的深入和云原生时代的到来，PaaS的价值和重要性日益显现。当前，许多技术名词和架构概念时刻都在渗透、冲击着每个人的知识体系，包括虚拟化、容器、编排引擎、DevOps、微服务架构、无服务器计算、物联网、云计算、大数据、区块链、人工智能和企业中台等。如何对技术正本清源，透视技术变革背后的规律和本质，并以敏捷变化应对外部环境的不确定性，考验着每个企业的技术能力、生存能力和创新能力。身处这样的时代，唯有通过PaaS平台赋能，方可应对万变！

 

1.2.1 数字化转型的本质

 

当前阶段，人类社会正在经历一个万物互联、智能互联及从消费互联向产业互联过渡的时代，新技术群不断井喷，与之对应的企业系统架构正在由传统单体系统向分布式微服务系统、大系统、巨系统和“系统之系统”演化。

 

企业所要应对的内外部环境变得越来越复杂，而这种复杂性不仅体现在企业之间产销关系、供应链等横向互联的复杂性上，还体现在企业内部纵向生产环节的复杂性上，如用户需求的多样复杂性、排产计划的复杂性、产品设计研发的复杂性、全工艺生产流程的复杂性、库存周转及产品全生命周期服务的复杂性等。在面对如此众多的复杂性时，企业的决策具有极大的不确定性，而如何化解复杂系统和环境给企业带来的不确定性，克服企业在决策过程中对不确定性的恐惧，才是企业数字化转型的根本逻辑。

 

企业数字化转型的目的是在由数据、算力和算法定义的智能经济时代，以云计算、大数据、人工智能、物联网、5G通信技术和边缘计算等新兴产业技术群为基础，利用数字化支撑技术体系，实现产业技术群的“核聚变”，通过数据的自动流动完成企业在生产经营中的问题描述（发生了什么）、诊断分析（为什么会发生）、未来预测（接下来将会发生什么）、科学决策（应对将来可能发生的变化）和精准执行（对决策作出的响应）5个闭环赋能环节，最终提升企业适应竞争环境快速变化的能力、业务快速创新的能力和应对复杂系统及不确定性的能力。

 

智能经济时代技术群的“核聚变”

 

1.2.2 PaaS赋能企业中台

 

“中台”的概念源自阿里巴巴提出的业务中台，随后不断拓展，目前已发展为以业务中台、数据中台和技术中台为主的企业数字化转型中台战略。中台的故事始于2015年年中马云带领阿里巴巴高管团队拜访位于芬兰赫尔辛基的移动游戏公司Supercell。Supercell以“部落”形式组成独立部门，专门负责为各个前端开发小团队提供游戏开发中所需的基础设施、游戏引擎、内部开发工具和平台等共性能力，而每个前端游戏开发团队都配有开发一款游戏所需的全部角色，因而每个团队都可以快速决策、快速开发、快速试错和迭代。在Supercell的游戏开发架构中，“部落”不负责游戏开发，只负责为前端开发团队提供游戏开发所需的能力，而前端开发团队负责利用“部落”提供的能力快速开发、试错迭代，Supercell的“部落”便是我们现在通常所讲的中台。

 

在马云带队访问Supercell后，阿里巴巴于2015年年底启动了2018中台战略（计划在3年内达成战略调整目标），其目的在于构建更具创新性和灵活性的“大中台、小前台”组织架构，即将前端各大事业部的技术能力和数据运营能力从前台剥离，沉淀形成独立的中台，从而形成“厚平台、薄应用”的架构形态，进而保证前台的精简性和充分的敏捷度，以便更好地满足多元业务的发展和创新需求。阿里巴巴“大中台、小前台”架构形态如图1-9所示。

 

阿里巴巴“大中台、小前台”架构形态

 

事实上，关于中台的定义，目前业内并没有权威的标准，在阿里巴巴的中台战略成功之后，越来越多的企业和从业者才开始研究中台的内涵。通常认为，中台就是通过对业务、数据和技术的抽象，对共性服务能力进行沉淀复用，构建起企业级的通用服务能力，以消除企业内部各业务部门、各分子公司间的壁垒，适应企业，特别是大型企业集团业务多元化的发展战略。基于中台，企业可快速构建满足最终消费者和客户需求的前台应用，从而满足各种具有个性化特征的前台需求，为企业的数字化转型提供明确的道路。因此，从技术层面来看，中台是企业级的共享服务平台，是企业能力的枢纽和对能力的共享，是企业数字化转型的整体参考架构和最佳实践。

 

目前越来越多的企业正在基于中台战略进行数字化转型，正朝着“大中台、小前台”的业务进行组织架构调整。中台沉淀了共性业务服务和技术、集合了技术和产品能力、连接了前台需求和后台资源、提升了用户响应能力，现已成为企业战略转型的重要主题，而中台能力的建设是多数企业的当务之急。

 

1.2.3 PaaS与中台

在中台能力的建设过程中，企业首先想到的必然是云计算三大模式中的PaaS平台，甚至有观点认为，PaaS即中台。虽然我们不完全认同这种观点，但是不可否认，比中台出现更早、更成熟的PaaS平台与中台确实有诸多共性，如PaaS中抽象并沉淀上层SaaS和下层IaaS共性能力的初衷，实现技术能力的复用、将应用与基础设施进行解耦、为企业应用和开发者创新赋能等，其实也是中台建设的必然要求。

 

对比当前PaaS与中台，二者的区别应该在于，中台更倾向于业务复用，并通常涉及组织架构的调整，而现阶段的PaaS更倾向于技术复用，更多地表现为构建企业统一的技术中台。但是，随着PaaS的发展进入深水区，当前的PaaS在向下渗透并统管IaaS的同时，也在越来越向上层前端应用靠近，越来越具备业务中台和数据中台的特性，呈现出PaaS平台支撑业务中台、数据中台和技术中台之势。换句话说，中台建设离不开PaaS平台，PaaS平台正在赋能企业中台建设。

 

PaaS赋能企业中台建设

 

1.2.4 PaaS助力数字化转型

 

正如安筱鹏博士在《重构：数字化转型的逻辑》一书中所言，企业数字化转型的本质，就是在由数据与算法定义的世界中，以数据的自动流动化解复杂系统的不确定性，优化资源配置效率，构建企业新型竞争优势。而在具体的实现上，就是利用云计算、大数据、人工智能、区块链和物联网等新兴技术群构建企业闭环赋能平台，通过数据的闭环流动实现企业的科学决策和精准执行。

 

在企业数字化转型，尤其是传统企业的数字化转型过程中，业务系统的云化或上云已成为企业的必然选择，从传统IT架构系统迁移至基于云计算的微服务架构和云原生应用架构体系，实现企业业务能力、数据能力和技术能力的平台赋能和能力复用，满足企业业务需求的快速响应和敏捷交付，实现新型业务或功能的快速创新、快速试错与高频迭代，提升企业在复杂多变和不确定性环境下的核心竞争力，是企业数字化转型的必由之路和最终目标。

 

然而，企业上云并不能一蹴而就，尤其是传统企业在长期发展过程中遗留下了诸多历史包袱，而企业为了平滑过渡和新旧兼顾，必然在数字化转型的初期选择“双态”模式，即基于传统IT架构的稳态模式和基于云计算架构的敏态模式。虽然“双态”模式可以帮助企业赢得数字化转型的过渡时间，但是如何将传统业务系统逐步云化迁移，并最终实现完全云化的业务架构，仍然是企业在进行数字化转型时面临的首要问题和难题。而在企业业务系统朝着云原生和微服务架构云化迁移的过程中，如何让传统应用摆脱对基础设施的依赖，如何将传统应用中非业务逻辑的部分解耦下沉，如何全栈治理复杂基础架构设施及其之上的微服务，如何推行基于DevOps的敏捷文化，如何将最新的技术集成并应用到业务系统中，如何通过技术的快速创新驱动业务的高速增长，这些都是企业必须思考和首先要解决的问题。在云计算的发展历程中，PaaS服务模式的存在正是为了帮助企业解决数字化转型过程中所面临的上述难题，而如何以简单高效、弹性可扩展，以及高可用、高灵活性、强兼容和低成本的方式来解决这些问题，也正是PaaS这些年来一直在努力的方向。

 

PaaS作为云计算三大模式的中间层，在企业数字化转型的初期并未受到普遍重视，而随着企业数字化转型进入纵深领域，PaaS平台建设的需求开始不断增强。从市场层面来看，根据Gartner的调查数据，伴随2017年以来的数字化转型浪潮，截至2019年，整个PaaS市场有360多家厂商，在21个品类下提供550多种云平台服务，而到2022年，市场规模还将增加一倍，这也说明PaaS正在成为企业数字化转型的主流解决方案。从技术层面来看，通过对服务器、存储、网络、操作系统、运行时、中间件等基础设施进行抽象，PaaS使得业务逻辑不再依赖于基础设施，省去了高度复杂的IT架构给企业开发人员带来的不必要付出，使开发人员能够专注于功能创新和业务逻辑实现。通过对DevOps理念文化的集成和工具链的实现，开发人员可以在PaaS平台上以自助服务的方式大规模、可持续地部署和运行应用程序，并实现业务功能的敏捷开发和快速交付。通过高度模块化、灵活性、通用性和弹性的架构设计，PaaS可作为企业数字化转型的创新引擎平台，为企业提供新技术不断集成、不断试错和快速迭代的能力，帮助企业在快速变化的竞争环境中保持以技术驱动创新所带来的核心竞争力。

 

随着Docker、Kubernetes、Service Mesh、Serverless和DevOps等云原生技术、理念和文化的普及，PaaS正在朝着自动化、简单化、标准化和通用性的方向发展，PaaS平台的构建、使用、治理及其应用的生命周期管理等任务正在变得越来越智能，而PaaS平台在技术实现上的简洁化和低成本，也正在助力各行业数字化转型的快速推进。我们有理由相信，随着企业数字化转型的不断深入，PaaS平台的价值将会越发凸显，而PaaS平台的建设也将成为企业数字化转型的必由之路！

 

购买链接：https://item.jd.com/12640959.html

 

 

感谢您的阅读，欢迎关注我的微信公众号：