拥抱云原生：江苏移动订单中心实践

最新推荐文章于 2024-05-29 09:25:06 发布

鲸品堂

最新推荐文章于 2024-05-29 09:25:06 发布

阅读量2.3k

点赞数

文章标签：云原生

本文链接：https://blog.csdn.net/whalecloud/article/details/125487915

版权

近日，浩鲸科技江苏移动订单中心产品顺利通过信通院 “云原生业务应用成熟度”优秀级（L4）的认证评估，成为国内首个通过该认证的业务应用

以下摘自《云原生能力成熟度模型第2部分：业务应用》：

--云原生：云原生是面向云应用设计的一种思想理念，充分发挥云效能的最佳实践路径，帮助企业构建弹性可靠、松耦合、易管理、可观测的应用系统，提升交付效率，降低运维复杂度。

--云原生业务应用成熟度模型：从企业业务应用基础设施域、应用研发域以及服务治理域等三个能力域、二十个过程域综合评估企业业务应用在弹性、高可用、自愈性、可观测性以及自动化等五个维度的云原生能力成熟度水平。

这也标志着该产品的云原生业务应用架构已达到国内领先水平，今天我们与大家一起分享浩鲸科技基于云原生研发的订单中心产品，了解在当前形势下，订单中心如何解决高可用和业务发展变化快的矛盾。

建设背景：业务发展变化快

随着移动互联网进入5G时代，O2O、秒杀、团购、直播带货、新零售等新商业模式不断涌现，运营商市场也从传统的个人家庭用户拓展到政企用户多样性的业务中，传统业务和新型业务间的融合将更加紧密，订单模式提出新的支撑要求。

这种创新融合发展的趋势，对运营商的订单服务带来了新的挑战：

随着政企等新兴业务的拓展，订单量增长迅速，原有应用+数据库的架构面临着很大的压力，一方面，烟囱式的应用难以快速横向扩展，另外一方面，需要引入新的数据组件缓冲数据库压力。
秒杀、直播带货等新兴业务带来订单量在短时间内的突增，如何应对短时间内的高峰对主机资源的要求又能尽量降低扩容成本？需要考虑在系统过载的情况下能对自身的服务和外部的请求都进行取舍，保障核心服务的稳定性，实现系统的韧性。
为了抢占新市场，需求交付周期越来越短，版本上线愈发频繁，传统的手工作坊式的研发交付模式已经不能满足业务交付要求了，需要在DevOps理念下引入研发效能工具体系。

订单中心系统日益庞大，涉及到复杂的技术组件和架构，特别在面向政企业务支撑过程中，非标准、长流程及多系统协同的场景非常普遍，一旦订单中心自身或周边系统异常，出现各种组件的连锁反应，产生大量的告警，如何快速定位问题根因，如何实现系统自愈、实现业务层面无感知，如何以可视化的方式立体化呈现整个系统、实现数字孪生。

问题解决之道：拥抱云原生

为了解决以上难题，浩鲸科技订单中心产品围绕全面云化、微服务、DevOps、智能运维，通过技术发展驱动IT支撑系统为业务提供创新价值，从四个方面全面实现云原生架构：

全面云化：

应用完成容器化改造，基于云原生PaaS平台，适配磐基底座，使用云原生的技术组件。

微服务：

领域驱动设计指导微服务改造，订单中心拆分成若干个微服务线，构建“管、诊、治”微服务治理体系，提供可视化服务编排能力。

DevOps：

构建研运一体化的工具体系，实现订单中心的敏捷研发、快速交付、缩短迭代周期，快速响应客户需求。

智能运维：

实现多维监控与告警，业务与系统的监控联动和统一展示，支撑故障的快速定位与恢复，实现常态化故障攻防演练。

云原生总体架构

构建研运一体化的工具实现敏捷研发、快速迭代。通过订单中心的微服务拆分和云原生架构及灰度发布机制，实现升级或故障不影响业务，通过多维监控快速发现问题，通过调用链快速定位问题，通过统一的服务治理和自动化的容器调度实现系统的弹性伸缩，确保订单中心7*24小时高可用。

订单中心自底向上可分为基础设施层、数据层、应用服务端、应用客户端，还有统一监控运维中心：

基础设施层：订单中心运行于虚拟化的基础设施上，平台PaaS组件运行在虚拟机上，业务应用运行在容器上。
数据层：订单中心大量采用云原生PaaS组件，包括redis、MQ、ElasticSearch等，降低数据库压力的同时保证数据层的高可用。
应用服务端：基于微服务化构建了多条微服务线，通过构建订单中心的微服务网关实现多条微服务线的统一服务治理，确保订单中心的高可用。
应用客户端：多渠道多类型的客户端访问请求，先通过Nginx再进入订单中心。订单中心内部部署了生产中心、灰度中心和灾备中心，Nginx主要用于多中心之间的切换。
统一监控运维：构建研运一体化工具实现敏捷研发、快速迭代，通过统一日志和运维监控实现业务和系统的多维统一监控和展示，通过调用链实现问题的快速定位。

云原生应用实践

云原生实践 1：云原生PAAS平台

底层PaaS平台都使用云原生组件，如Redis、MQ、ES等，确保底层PaaS组件的高可用。

使用Redis缓存配置数据和热点实例数据。订单首次查询时将物理库查询结果加载到缓存中，在途订单存入热点缓存集群，竣工存入普通缓存集群，后续订单查询先从缓存查询，通过这种方式可以大大减少数据库的访问压力。

将订单及其扩展信息中强搜索需求的索引字段同步到ElasticSearch后，就可以将查询服务单独剥离出来，从而在不影响订单流程运转的同时，提升订单查询效率，订单查询性能从600笔/s提升到3000笔/s。

使用MQ做订单收单，通过消息服务实现削峰填谷，提升订单收单效率；利用MQ实现异步接口日志消费；通过消息服务实现订单多中心之间的缓存同步。

云原生实践 2：微服务化

按照领域驱动设计（DDD）方法论，订单中心按照业务领域拆分成松耦合的若干微服务线，各司其职，减少关联影响，缩短迭代周期。数据库也做相应拆分，减少故障的影响面。如下图所示，订单中心拆分成集团号卡、省内号卡、宽带、集客、电子协议、调度等微服务线，每条微服务线都有自己的数据库，从而实现了微服务线之间的应用隔离和数据隔离，可按需灵活扩展。

云原生实践 3：微服务治理

订单中心使用微服务网关实现服务治理，使用Spring Cloud Gateway框架，再加上认证服务和微服务管控平台SCP(Sentinel)的配套，实现订单中心多条微服务线统一的安全鉴权、业务分流、服务跟踪、监控诊断、限流、熔断、降级等服务治理能力，使用策略配置实现自动化的流量管理，实现服务的可管理、可观测和自动化运维。

微服务治理关键能力：

服务熔断：订单中心的服务可以配置，当其下游服务单位时间内调用失败次数达到阀值时，防止整个系统出现连锁反应甚至雪崩，暂时停止对该服务的调用。
服务限流：当入口请求 QPS 超过服务配置的阀值时，如瞬时出现高并发订单查询请求时，订单查询服务可以配置对某些渠道的查询请求进行限制，以保证本服务不被压垮。
服务降级：如上图所示，当订单中心的服务压力达到一定程度时，订单中心配置了服务降级策略，对容忍度高的服务进行降级，如对查询服务降级，以保证订单创建服务等核心服务的稳定性。

云原生实践 4：研运一体化

引入DevOps研运一体化工具，实现需求管理、迭代计划、源代码管控、源代码编译打包、静态检测、生成镜像、自动化测试、持续发布部署、全栈监控、自动化运维的研发运维全流水线的工具支撑，实现业务系统的敏捷研发、快速发布上线、缩短迭代周期，快速响应客户需求。

云原生实践 5：多活/灰度切换

订单中心版本上生产前首先要在灰度中心完成验证。版本在灰度中心发布后，调整路由策略，切换一部分业务流量到灰度中心上，运行2天验证没问题后再正式发布到生产中心。

多活/灰度切换关键能力：

灰度路由切换：新版本在灰度中心发布后，调整路由策略，切换一部分业务流量到灰度中心上，运行2天验证没问题后才正式发布到南京中心。
多中心缓存同步：灰度发布期间，两个中心间的缓存数据需要同步，通过MQ相互通知机制把变动数据加载到各中心缓存，并通过数据库日志、消息监控等额外手段保证多中心缓存同步的正确性和一致性，实现了生产中心和灰度中心的无缝切换。
数据层版本控制：数据库表中都有版本号字段，可以识别新旧版本涉及的数据，可用于问题定位和版本回退，实现了数据层的灰度发布。