海南省建设注册中心网站,长春网络推广长春seo公司,百度推广运营公司,可以做卷子的网站云原生架构落地实践的背景
随着极氪数字业务的飞速发展#xff0c;背后的 IT 技术也在不断更新迭代。极氪极为重视客户对服务的体验#xff0c;并将系统稳定性、业务功能的迭代效率、问题的快速定位和解决视为构建核心竞争力的基石。
为快速响应用户的需求#xff0c;例如…云原生架构落地实践的背景
随着极氪数字业务的飞速发展背后的 IT 技术也在不断更新迭代。极氪极为重视客户对服务的体验并将系统稳定性、业务功能的迭代效率、问题的快速定位和解决视为构建核心竞争力的基石。
为快速响应用户的需求例如缩短一辆车的制造周期、便捷平滑地升级汽车操作系统等企业从产品到用户体验到商业模式都需要创新。然而消费互联网和传统产业发展的经验不足以完全满足产业互联网对成本、效率、质量等方面的高要求。云原生是一个确定性的技术发展趋势能有效推动产业发展驱动企业积极革新。极氪正持续投入将云原生能力赋能到企业内的研、产、供、销、三电等更广泛的业务领域。
这些业务现状和云原生架构带来的核心能力不谋而合。 在极氪系统改造上云的过程中围绕着云原生技术体系推动极氪的各条业务线进行技术升级改造加快数智化发展进程。在技术选型上极氪始终遵循着 2 条原则
一是全面拥抱开源开放的主流技术标准 使用开源开放的主流技术标准可以确保技术方案的成熟度更便捷地从开发者社区获取技术资源和最佳实践也能够帮助企业更好的招募技术人才。此外这样的策略也避免了被封闭技术体系和特定云厂商所捆绑。软件技术的国产化以及自主可控也是需要考虑的点。
二是尽可能利用云的价值 将稳定性保障、底层技术实现、技术组件维护、弹性伸缩等非功能性需求尽可能交给云厂商解决让技术团队将更多的精力投入到业务创新上。
这 2 个原则并不矛盾相反它们之间可以非常好的融合这也是所有使用云计算的企业用户都值得借鉴的架构选型标准。接下来我们将围绕微服务架构统一、应用运行高可用、应用发布治理进行展开并以可视化数据分析系统、车联网数据采集、智能研发范式这三类业务场景分享我们的云原生架构落地实践。
实践一统一微服务架构
在统一微服务架构之前极氪的各个业务单元多种技术栈并存彼此之间相互通讯复杂度高项目成员的交接往往要耗费巨大的精力极大程度上阻碍了数字化转型的进展因此微服务架构统一势在必行。
极氪经历了 2 年多时间完成了这一项艰巨的工作虽然投入精力巨大但收益是立竿见影的而且可以持续发挥作用不论是内部团队还是三方 ISV在技术框架上都有统一的标准可以遵循各团队共享技术栈后研发效率成倍提升。
关系到未来多年的 IT 战略在微服务架构的选型上高开放性、高成熟度、高普及度这三条标准缺一不可考虑到极氪以 Java 为主要开发语言Spring Cloud Alibaba 就成为了微服务框架的最佳选择。 Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案包含开发分布式应用微服务的必需组件方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。这些组件一部分以 SDK 的形式集成到代码中一部分以中间件的形式独立运行后者往往可以选择托管版云产品以降低开发者的工作量。比如阿里云微服务引擎 MSE 就提升了开箱即用的注册配置中心 Nacos以及云原生网关。
实践二微服务架构高可用实践
极氪 APP 是我们和车主的沟通纽带采用的是微服务架构。但是随着注册车主数量呈现出了爆发式的增长用户的使用场景也不断扩大。在这个过程中APP 的用户使用体验变得愈发重要如何在用户规模高速增长的同时可以保证 APP 的稳定性、敏捷性 APP 的微服务开发效率如何保证这些都给研发团队带来了一定的挑战。
1、高可用挑战
业务连续性差缺少容量规划
远程控车、在线地图、3C 商城等 APP 核心服务对业务连续性要求非常苛刻均需保证 7*24 小时持续在线。特别是面临旺季销售活动、新车型发布、突发热点事件等情况 APP 面临着高并发大流量压力经常会发生功能失效、页面打不开、延迟过高甚至 APP 完全无法访问的异常对用户体验造成严重影响。
功能版本发布迭代速度慢
随着用户场景需求的增加越来越多的功能等待发布上线对迭代频率的要求越来越高但由于 APP 服务端缺少全链路灰度发布能力为了保障业务稳定性每次发布客户只能选择在凌晨的业务低峰期进行开发、运维、测试同学苦不堪言急需实现随时发版无损发布能力。
技术架构缺少整体设计
公司成立之初为了实现 APP 快速上线对于技术架构整体设计考虑不足体现在业务间高度耦合、系统链路过长、技术实现标准不一、云产品选型不合理等诸多问题例如通过调研发现某核心接口请求链路过长导致延迟抖动率很高影响用户使用体验。
研发团队意识到随着业务发展的向好这些挑战也会也越来越大。在业务快速发展中既要保证好已有业务的稳定性又要快速地迭代新功能并且需要保证开发的效率并不会随着业务增长而大幅降低毕竟存在团队招聘节奏跟不上业务发展的问题。总结来说团队解决 APP 应用快速迭代演进的关键就是解决稳定性与效率的问题。
稳定性 用户数多起来之后系统的稳定性就显得比较重要无论是用户在某段时间遇到异常报错增多还是某一个功能点持续性地报错再大到系统有一段时间完全不可用这些都会影响产品在用户中的口碑最后这种完全不可用的场景甚至还可能成为微博等社交网络上的舆论热点。效率 随着用户的增多相应的需求也越来越多业务场景也越来越复杂在这个时候测试可不是内部测试就能覆盖所有的场景需要加大在测试上的投入。虽然功能需求越来越多但是迭代的速度却要求越来越快因为市场中已经有不少竞争者大家竞争的一个关键就是速度业务更需要跑得更快开发节奏要快测试节奏要快发版节奏也要快。
针对以上问题研发团队根据业务架构从流量入口到微服务再从全局视角进行微服务的系统优化与调优围绕着成本、稳定性以及效率进行深入的微服务化探索。 2、业务链路入口升级
极氪架构中的网关架构并不一致各种网关都起了一定的作用。我们可以从上图中看到流量网关、API 网关、微服务网关等众多网关存在他们具备了安全WAF、API 管理、流量分发等作用思考一下如果一个请求链路经过多个网关那么这个事情对成本与稳定性都有一定的挑战。
在这个时候 MSE 云原生网关出现在研发团队的视野中云原生网关将流量网关Kubernetes Ingress、Nginx和微服务网关Spring Cloud Gateway、Zuul 网关等二合一降低 50% 资源成本同时缩短了请求时间降低运维复杂度。
作为面向南北向的公网网关使用 Waf 防护异常流量是很常规的需求而且随着互联网环境变得越来越复杂用户对防护的诉求是持续增强的常规做法是将流量先接入 Waf 安全网关过滤后再将流量转发给流量网关最后到达微服务网关那么升级云原生网关后进一步需要思考的事情是入口流量的安全能力是否还可以具备
云原生网关通过内置 Waf 模块直接对接阿里云的 Waf 云产品使得用户的请求链接只经过云原生网关就可以同时完成 Waf 防护能力大大降低了网关的运维复杂度图示如下 网关作为链路流量的入口除了安全能力之外还承接着入口流量/容量的管理、高可用等职责。
3、运行时高可用
无损上下线提升微服务稳定性
当对极氪 APP 应用进行业务发版、弹性扩缩容等场景时会遇到请求失败率升高POD 不断重启等问题。针对此问题结合 MSE 产品能力通过应用下线过程中自适应等待和主动通知、应用上线过程中就绪检查、服务预热等手段实现微服务无损上下线发布有效规避了发布过程中的流量损失降低业务访问失败风险。同时通过引入 MSE 流量防控能力针对核心业务场景落地相应技术手段如接口限流降级、MQ 削峰填谷、数据库慢 SQL 限流治理等提高服务整体稳定性。
水平拆分提升业务弹性伸缩能力
随着业务的快速发展极氪 APP 原架构下容量不足问题愈发突出在面对新车发布、销售活动、突发热点情况时无法快速进行水平扩展并且大量核心业务库都放在同个数据库实例上容易出现“一损俱损”。阿里云服务团队推荐使用 Polardb-X 产品将业务库逐个剥离出来并通过对业务大表水平拆分解决单表过大问题提高数据库层面水平弹性扩容能力。另外针对微服务弹性能力不足的痛点输出多可用区节点弹性伸缩、HPA、CronHPA 等容器弹性方案提高核心服务在流量突发情况的应对能力。
流量防护与容错
想象一下在业务高峰期当某些下游的服务提供者遇到性能瓶颈甚至影响业务。极氪 APP 团队正是遇到了这样的问题在某次架构迁移的过程中遇到预料之外的慢调用拖慢了系统导致整体稳定性的抖动。如何避免这类问题需要对部分非关键服务消费者配置一个熔断规则当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断后续一段时间服务调用直接返回 Mock 的结果这样既可以保障调用端不被不稳定服务拖垮又可以给不稳定下游服务一些“喘息”的时间同时可以保障整个业务链路的正常运转。
突发的事情是非常多的那么如何可以做好系统的高可用让系统在不确定的情况下工作在最优解上极氪 APP 团队先尝试对 APP 大的层面做微服务稳定性治理避免出现 APP 整体宕机的情况。然后对核心服务和接口做梳理摸清上下游对强依赖解耦和改造并且根据监控、可观测数据确认核心服务配置什么合理参数。在这之后多次对服务进行限流降级配置以及演练、优化总结场景实践规律制定恰当的技术规范。
开发测试效率提升在线服务测试
极氪开始在云上进行部署、发布、测试之后他们遇到了如下问题
部署完应用之后应用是否健康当线上出现了一个问题怎么能够快速发起一次请求进行复现。在服务上线之前如何快速地验证历史功能是否都正常大版本上线前修改的内容对性能有什么影响上量之后会不会服务压力过大
为了做到安全隔离研发环境、测试环境、预发环境、生产环境部署在不同的专有网络 VPC 内如果自建测试工具需要解决测试工具到不同环境的网络互通问题企业 IT 人员明明只想要一个简单的测试工具却因为上云之后要解决复杂的云上网络拓扑远远没有结束为了能够在办公网使用该测试工具还需要保证该测试工具能够被办公网访问此时又面临着网络安全的考验。
云上的服务测试、压测就是为了解决这个问题 。 借助 FC 的弹性计算能力一方面打通了云上网络打通的问题另一方面随用随弹最大程度解决资源利用率的问题 借助服务契约提供的内容服务测试功能可以自动填充测试参数测试时只需要进行值的修改就可以发起测试。还可以根据提示将服务测试进行串联从而达到自动化回归、压测的目的。
4、发布态高可用
全链路灰度发布实现白天随时发版
随着极氪汽车销售越发火爆其注册用户和每日活跃用户快速增长需要支持的业务场景和新功能也越来越多平均两三天一个小版本、半个月一个大版本的升级频率。为了不影响白天业务高峰每次发版只能选择在凌晨业务低峰期进行想象一下如果研发/运维人员每次都集中在晚上发布那么这些参与发布的同学第二天的工作效率将会受到影响如果晚上选择较少的人参与发布那么当出问题的时候止血措施很可能会来不及实施故障责任也不好划分。
阿里云服务团队帮助极氪团队一起制定和落地全链路灰度发布方案通过部署灰度版本并按照流量比例或客户特征进行灰度验证验证完毕后进行生产发布并切流满足了客户小版本白天随时发布的诉求。针对客户核心业务链路上多个微服务同时需要发版的场景基于 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 内社区定时推荐、在线订单定时确认、 用户定时通知等场景客户利用 MSE 任务调度 SchedulerX 统一管理和调度定时任务。该方案具备以下优势。
异步任务统一管理支持将不同来源和类型的异步任务统一管理任务类型覆 crontab 定时任务、K8s Job兼容开源框架 XXL-JOB、ElasticJob、Spring Schedule并支持 Java SDK/Agent 实现自研 SchedulerX 任务任务运行来源覆盖云上异步任务和云下 IDC。
高可靠的秒级调度能力任务调度 server 端免运维无需担心机器宕机等高可用风险影响重点任务调度失败大幅降低运维成本实时性要求高场景支持高精准调度最小支持 1 秒级调度能力。
低成本海量数据处理海量任务分布式并行执行全面加快任务执行速度相比消息队列避免调用高峰拖垮在线业务大幅降低使用成本。
实践四可视化数据分析系统简化运维管理聚焦业务开发
随着业务加速发展公司迫切需要一个完善的 BI 数据平台来辅助各业务负责人做决策支撑。众所周知数据对于一个公司具有非常重要的价值好的数据承载工具显得尤为重要。极数 BI 应运而生目的是让企业资产数据快速流动起来帮助企业构建自上而下的决策分析体系实现业务流程和数据分析直接协同提升企业内各种人员的数据分析效率形成数据消费和价值洞察的企业文化。极数 BI 定位是一款面向极氪经营管理全体系的可视化数据分析系统已覆盖订单、车辆、交付、线索、用户、市场营销、市场分析、威睿工厂等场景。随着业务的快速发展BI 平台开始接入越来越多的业务需求在和各业务团队落地过程中也面临很多使用问题比如如何简化维护管理、如何实现多版本并行运行、如何保障业务 SLA 等。
基于 Serverless 技术的发展趋势判断极氪选择使用 SAE 承载这部分业务。SAE 是面向业务侧提供的一站式全托管 K8s 平台集成了云原生微服务治理和应用可观测能力使用和维护体验更加简单能让开发侧更加聚焦业务价值。尤其是对 BI PAAS 平台来讲多租隔离、权限管理、应用管理、简化业务使用等关键需求实现起来更加友好。 SAE 的使用主要在 3 个方面产生了不错的收益
第一聚焦业务应用提升开发效率。极数 BI 做为公司业务团队的“决策参谋”面临复杂多变的需求还需要能快速开发上线采用 SAE 可以省去环境搭建的过程代码写好后 1 分钟左右就能部署上线进行测试验证SAE 还集成好了日志监控能力排查问题很方便。其他业务方接入使用的时候也不用关心资源的创建和扩容环境也都是一致的大家都聚焦在业务开发和维护上极大提升了研发效率。
第二简化维护管理。SAE 提供了整套的应用管理能力和弹性伸缩能力结合云效流水线实现了自动化的创建、更新流程资源也是随开随用业务方接入部署的时候通过流水线自动就把资源和环境创建出来并完成应用部署也就是应用即资源Node 节点的高可用、扩缩容都不需要操心。
第三多租户隔离。SAE 的命名空间提供了完美的资源隔离能力可以非常方便的用来做环境和权限划分极大程度上简化了我们多租隔离的实现成本。
实践五车联网数据采集分析免运维、弹性可扩展
为了提升智能化水平新能源汽车对车联网的投入也是非常巨大的。其中如何实时的把海量车端数据采集到云上进行数据分析并能支持日益增长的在线车辆数量具备自动弹性扩容的能力至为关键。借助 OSS FC 的组合以完全 Serverless 化的模式接入端侧数据上报整体具备免运维、弹性可扩展的能力。 从车端上报的数据以加密的形式上传到 OSS上传成功后会自动触发函数计算对数据做校验、解密和分析然后把清洗后的数据写入到Kafka供后续的业务流程分析使用。整体方案不仅解决了弹性扩展问题还极大的优化了资源利用率。此外FC 天然可以应对大流量冲击保障系统稳定性和容灾能力。 实践六通义灵码助力极氪汽车智能研发范式
现大模型如火如荼发展极氪基于 AI 的创新也是基于阿里云的百炼等相关大模型的平台验证大模型对于业务的价值。对比测试了很多对应的产品最终极氪选择了通义灵码。
第一在个代码生成的相关的领域通义灵码确实比较好。
第二通义灵码给极氪开放了一些功能例如自定义指令等能够基于自己的需求做一定的定制开发。
第三在安全合规方面通义灵码基于 VPC 的部署的方式以及通义灵码和极氪一起共创的安全合规审计的功能帮助极氪能够快速的在内部落地通义灵码提升整体的研发效率。
未来展望
极氪 APP 进行云原生架构升级探索提高了 C 端业务系统的稳定性和敏捷性为冲击更高的销量目标提供了坚实的技术支撑。这仅仅是探索的开始随着云原生架构的深入业务的可用性将持续增强从而为汽车终端用户带来更好的出行体验和乐趣。
