作者：极氪汽车
前言
新能源汽车曾经成为我国汽车市场再次崛起的要害支柱，随着新能源汽车市场的疾速倒退，不同类型的品牌造车厂商呈现出百花齐放的态势。极氪汽车是吉利控股集团旗下高端纯电汽车新品牌，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 整体宕机的状况。而后对外围服务和接口做梳理，摸清上下游，对强依赖解耦和革新，并且依据监控、可观测数据，确认外围服务配置什么正当参数。在这之后，屡次对服务进行限流降级配置以及演练、优化，总结场景实际法则，制订失当的技术规范。
开发测试效率晋升：在线服务测试
极氪开始在云上进行部署、公布、测试之后，他们遇到了如下问题：
- 部署完利用之后，利用是否衰弱？当线上呈现了一个问题，怎么可能疾速发动一次申请，进行复现。
- 在服务上线之前，如何疾速地验证历史性能是否都失常？
- 大版本上线前，批改的内容对性能有什么影响，上量之后会不会服务压力过大？
- 为了做到平安隔离，研发环境、测试环境、预发环境、生产环境部署在不同的专有网络 VPC 内，如果自建测试工具，须要解决测试工具到不同环境的网络互通问题，企业 IT 人员明明只想要一个简略的测试工具，却因为上云之后，要解决简单的云上网络拓扑，远远没有完结，为了可能在办公网应用该测试工具，还须要保障该测试工具可能被办公网拜访，此时又面临着网络安全的考验。
- 云上的服务测试、压测就是为了解决这个问题 。 借助 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 端业务零碎的稳定性和敏捷性，为冲击更高的销量指标提供了松软的技术撑持。这仅仅是摸索的开始，随着云原生架构的深刻，业务的可用性将继续加强，从而为汽车终端用户带来更好的出行体验和乐趣。