关于前端:打车业务下单高并发解决方案

简介： 打车业务下单高并发解决方案

前言

在技术畛域有一条准则，即不存在银弹技术。在理论工作中，通常无奈通过几项简略的技术组合就解决理论业务中各种场景下的简单问题。尽管谋求架构的简略简洁也是架构师的指标之一。但必须意识到架构的简略简洁和没有银弹技术是一对矛盾体。正是整个矛盾体在推动着技术的不断进步。

本计划的目标在于抛砖引玉，介绍了 GTS TAM 团队通过对理论技术服务工作中遇到的问题的思考，造成的一种解决方案。心愿这个解决方案可能对大家工作中的理论问题的解决起到启发作用。如有趣味理解具体细节，欢送分割阿里云 GTS TAM 团队。

1. 行业背景

打车业务是出行行业的一个细分畛域。这些年打车业务始终处于疾速倒退阶段，除了一直加大一二线城市倒退，还一直开辟三四线城市市场。8 月 25 日滴滴出行的寰球日订单量首次冲破了 5000 万单。

打车行业的根本需要是撮合司机和乘客，达到满足乘客出行需要的目标。打车系统核心是以定位、地图等地理信息服务和订单服务。除此以外，打车零碎还蕴含领取、会员、计价等业务服务，容器、数据库、缓存、音讯队列等云服务，以及人工智能、大数据、视频监控等综合性技术服务。

1.1 业务特点

打车行业的一个特点是其乘客端业务流量出现显著的潮汐稳定。此外，还会因为节假日和顽劣天气等起因导致业务流量稳定，并且这种稳定存在肯定的不确定性。

1.2 技术挑战

打车行业不易预测的业务峰值稳定对包含订单零碎在内的打车业务外围零碎的伸缩性，以及高并发能力、稳定性提出了比拟高的要求。高并发能力和稳定性肯定水平与伸缩性相干，业务零碎的架构设计如何提供可伸缩的设计，天然也会晋升零碎的并发能力和稳定性。

利用从分层的角度来说通常分为接入层、应用层和数据层。其中，数据层的伸缩是重点和难点。目前阿里云 PolarDB 是数据库畛域最出色的弹性解决方案。但目前数据库弹性伸缩还是只应用业务顶峰工夫和流量绝对确定的场景。

2. 计划指标

本计划是聚焦打车业务的订单场景的弹性伸缩解决方案。目标在于订单这一打车业务外围零碎可能在无需人工操作的状况下，满足不确定的业务顶峰对打车订单零碎的冲击，为客户提供能满足高并发且老本可控的订单零碎架构设计。

3. 具体设计

为达到上述指标，本计划提供了如下架构设计。下图是整体架构设计，左图是传统的订单零碎架构，分接入、利用和数据三层。右图是弹性下单架构方案设计。在原有根底上减少了两层：前向订单服务和订单队列。在这两层之后，是订单外围服务和订单数据库。

前向订单服务将下单申请解决后，将数据写入订单队列中即可返回。订单队列提供了高并发吞吐和较低的响应工夫。订单队列由缓存和音讯队列组成，缓存以用户维度放弃最近的叫车状态信息，而队列则提供了高并发下单申请的长久化能力。

打车业务的下单场景能采纳这种设计的起因是打车业务的订单是以乘客 ID 为维度，单个乘客在同一时间段只有一个进行中订单。整个流程的程序是先下单，再履约，最初领取。因为领取是在最初一步，而下单和履约的主体不同（下单的主体是乘客，履约的主体是司机），因而下单可异步化。

接下来将介绍新架构所引入的两层新设计。

3.1 前端订单应用层

前端订单应用层的性能次要包含以下几点：

1. 根本校验、风控及安全检查
2. 异步下单
3. 限流降级

• 性能一：根本校验、风控及安全检查

  这一步是业务参数的校验，以及风控平安方面的查看。这一类操作的特点是可通过缓存等伎俩优化性能，并在不影响次要业务的状况下进行降级。将这些可缓存、可降级的操作前置到可弹性伸缩的应用层，有利于承载高并发的业务流量。

• 性能二：异步下单

  因为新计划减少了订单队列层，因而须要前端订单应用层实现异步下单的性能。这里波及的操作次要是生成下单申请，将申请保留到缓存和队列中，以及一些业务解决，比方依据加价金额及其它参数，管制下单队列优先级。
  这里须要留神的是这一步性能须要保障下单功能的幂等性、保证数据一致性和思考申请乱序的问题。 这些问题都是分布式系统研发过程中常见的问题，此处不再赘述。

• 性能三：限流降级

  因为下单链路上减少了缓存和音讯队列，如果必须强依赖于这些服务，相较于原来的架构设计，可用性是降落的。因为新的订单队列层是为了实现晋升零碎在高并发场景下的弹性能力，因而不是必须的依赖。在 Redis 或音讯队列出现异常时，前端订单服务须要可能将申请绕过订单队列层，间接调用订单外围服务，实现叫车下单功能。

3.2 订单队列层

如前所述，订单队列由缓存和音讯队列组成。缓存以乘客维度记录最新的叫车状态，音讯队列则长久化叫车申请。

• 接口幂等性

  在具体实现中，计划倡议先将叫车申请写入音讯队列，再写入缓存。起因是缓存中的数据表示叫车状态，如果先写入缓存，则无奈通过其中的数据判断是否写入音讯队列胜利。

• 申请程序性

  申请异步化之后，申请的程序和理论解决的程序将无奈保持一致。此时须要由业务零碎实现上的设计保障新申请的处理结果不会被旧申请笼罩。

• 数据一致性

  缓存中的数据表示乘客的出行状态，而乘客的出行状态不只是来自于乘客的被动申请，而也会依据订单状态的一直变动而变动。因而，缓存中的乘客出行状态数据须要和后端订单解决反映的理论状态保持一致。

4. 技术架构

4.1 计划 PK

弹性应用层 + PolarDB 弹性数据库 vs 本计划（订单队列异步下单）

利用架构的弹性伸缩计划的重点是数据层。数据库采纳 PolarDB，能够实现数据库层的弹性伸缩。这个计划的长处是架构简略，防止异步下单所带来的研发复杂性和难度。毛病是须要人工执行伸缩，及时性有余。同时导致十几秒（最多 30 秒以内）的业务中断。因而较为适宜业务顶峰工夫明确的场景。

订单队列异步下单计划的长处是弹性伸缩能力强，适应范围广。毛病是架构较为简单，减少研发老本。

4.2 技术选型

4.2.1 弹性应用层：ACK + ECI

在上述的解决方案中，前端的应用层须要可弹性伸缩的计算服务给予反对。本计划倡议采纳 ACK + ECI 的组合。ACK 是阿里云 Kubernetes 服务（Alibaba Cloud Kubernetes）的缩写，ECI 是弹性计算实例（Elastic Compute Instance）的缩写，是一种 Serverless 技术，为包含容器服务在内下层计算资源提供无服务器的计算实例。

应用 ACK + ECI 能够构建弹性的应用层。ACK 自身也能够提供肯定范畴的弹性伸缩能力，但 ACK 弹性伸缩分为 Pod 和 Node 弹性伸缩两局部。Pod 运行在 Node 之上，但 Node 资源短缺时，只需对 Pod 进行伸缩。当 Node 资源有余时，须要先扩容 Node，而后再创立新的 Pod。因而，单纯应用 ACK 的伸缩个性的毛病就是时效性有余。同时还存在资源利用率有余的问题。

为解决 ACK 伸缩性的有余，本计划倡议采纳 ACK + ECI 的架构。ACK 通过 Virtual Node 与 ECI 连贯。扩容时当 Node 资源有余时，会将扩容的 Pod 调度到 Virtual Node 上。Virtual Node 通过 virtual-kubelet-autoscaler 将 Pod 扩容申请调度到 ECI 上。

4.2.2 订单队列：RocketMQ + Redis

本计划举荐采纳 RocketMQ + Redis 实现订单队列。
RocketMQ 是阿里开源的音讯队列产品，与 Kafka 相比，尽管吞吐量不如 Kafka，但具备杰出的稳定性和泛滥适宜在线业务的个性。因而，常选用 RocketMQ 作用在线业务的音讯队列，而 Kafka 通常适宜大数据处理。

阿里云提供的 RocketMQ 分标准版和铂金版两种。尽管铂金版价格较高，但处于稳定性的思考，因而此计划举荐采纳铂金版作为线上订单队列中的音讯队列的实现技术。

阿里云提供了多种版本的 KV 存储服务，兼容 Redis 协定。订单队列所需的 KV 存储服务倡议依据理论业务量评估规格，通常采纳主从版即可。

4.3 部署架构

接入层和应用层容器服务双可用区部署。MySQL 和 Redis 的主节点部署在其中一个可用区。

咱们是阿里云智能寰球技术服务 -SRE 团队，咱们致力成为一个以技术为根底、面向服务、保障业务零碎高可用的工程师团队；提供业余、体系化的 SRE 服务，帮忙广大客户更好地应用云、基于云构建更加稳固牢靠的业务零碎，晋升业务稳定性。
原文链接：https://developer.aliyun.com/article/782755?utm_content=g_1000253354
本文为阿里云原创内容，未经容许不得转载。