龚磊 沈源淳

摘 要：随着电子商务市场的蓬勃发展带动了传统快递业务量的急速上涨，由此剧增的业务数据传输、处理、查询成为了快递业提升服务品质的新瓶颈。本文为解决大型信息处理系统中高性能、大吞吐量和高并发数据的优化问题，从软件架构、数据架构、高可用三个方面阐述如何提高系统的整体性能，以保证大用户量高并发访问系统时仍然具有良好的用户体验，以及高可用和高可靠性。

关键词：高并发；优化设计；大用户量

引言

我国于2006发布的《物流术语》中给快递定义是：承运人将文件或货物从发件人所在地通过承运人自身或代理的网络送达收件人手中的一种快速的运输服务方式[1]。快递是突出物流服务中运输功能的一个特别版本，是针对物流中零散、快速、精确派送部分的一个具体体现。

快递行业是一个既传统又新兴的行业，说起传统其是典型的劳动密集型行业，跟大型工厂仓库有不少类似，说起新兴是因其随着互联网购物等新兴需求使得市场不断扩大而蓬勃上升。其市场规模2008年仅0.13万亿，据国家邮政局6月24日发布的《2016年度快递市场监管报告》显示，2016年中国快递业务量达到了312.8亿，同比增长51.4%[2]。电子商务市场的高速增长产生了大量的快递需求，尤其是C2C电商，对第三方快递的依赖几乎是 100%。快递业务量的急剧增长使得业务员要计划和管理越来越多的数据[3-4]。业务快速增长，如果无法在短时间内处理完成必然引起公司的运营效率降低，导致无法及时完成快递业务，又必然引起客户的不满，继而影响自身信誉及后续业务[5]。

1业务场景分析

与电商围绕用户行为和商户或商品维护不同，物流快递系统里围绕的基本就只有运单。但是物流快递有其特殊性，以及传统行业难以避免的历史遗留问题，所以在一个运单的生命周期内有好几个变体，简单说来业务上是1收件（包括电商来的订单可以看作是预备的运单）、2发件（门店主要靠定期来回于门店与转运中心之间的班车来将收件以后的快遞件传递给上级门店、本区域的中心门店或最终达到本区域转运中心）、3到件（发件方区域转运中心发往收件人一方所在区域的转运中心乃至具体门店）、4派件（具体门店分配具体人员进行快递件的最终派送）、签收（收件人签收快递件，最终完成整个生命周期）。其中每一处人员接手都有相关操作记录，每一次涉及车辆的运输操作都会有每件快递件的扫描记录操作乃至将多个小件打包后的包裹记录的扫描记录操作。车辆相关操作可能大都集中在前后半夜的几个小时内，而且是一边一些地方有发车装货扫描、一边一些地方有到车卸货扫描，而人员操作主要集中在每天早上上班的1、2小时内的早高峰阶段、以及晚上下班发件方门店收到件以后，集中进行快递件收件确认的操作，这几个时间点，在数千家网店的物流快递公司内，都会短时间产生大量的并发压力，这就是本文所要分析并优化的问题。

2高并发设计

当前大多数业务系统都基于B/S架构或者基于前端APP或本地gui+后端接口的架构，其本质都是以HTTP通信协议为基础，可以将架构简化为前端+http接口+后端业务逻辑+后端其它组件。

2.1前端架构

前端的关键是清晰的功能和贴心的用户体验，其次才是绚丽的界面。业务逻辑设计上前端主要处理view层从后端接口下载的数据，然后承载、小部分情况下缓存在本地，最终显示。在需要的时候编辑相关数据，然后作为接口参数回发给后端接口以便后端处理复杂的业务逻辑，而前端在这个过程中主要是初期验证回传数据（确保调用后端接口前数据尽量是有效的，以免太多无意义的后端处理）和在大并发业务场景下某些场景的操作频率限制，比如运单录入时候（收件），调用后端报价与折扣接口，按照某物流公司门店4千左右，单门店同时调取报价接口的设备以5个计算，设极端情况下50%客户端同时访问后端为例，该场景点的性能极端情况瞬间就达：4000*5*0.5=1w的访问次数，假设后端的处理能力是1k每秒，这样集中的请求需要10秒以上的时间来处理，那么可选的限制操作首先就是不允许重复使用这个功能，每5-10秒才允许使用一次，这样确保尽量在短时间内不会对后端产生太大的压力，其次可以在请求后端接口前随机增加若干秒的延迟，这样也能大大降低极端情况下的压力。

2.2后端架构

后端的软件架构其设计上要遵循的原则颇多。

（1）容器无状态：最基础的业务容器的无状态，常见的实际场景就是作为后端入口的http接口，这里所说的业务容器主要是指asp.net的iis这类，当然能够独立不需要外部webserver就能直接提供http服务的比如.net的owin规范的hostself的独立exe方案来处理高并发短连接的http请求。之所以要保证无状态是为了业务容器这一层可以配合负载均衡手段达到理论上无限扩展实例，以期横向扩展性能。

（2）服务拆分：如果说容器无状态属于微观视角，那么大型系统应做的纵向以及横向拆分就是属于准宏观视角，其中包括不同方面，拆分在软件架构层面主要就是1，按照层次拆分：接口层、业务逻辑层、底层基础服务层等。2按照系统和模块拆分：上层系统、下层系统自然不用说，业务上不同系统也一样应该拆分，在物流系统里比如对接电商的订单管理系统和下一层的处理订单转成运单后的运单管理系统之间的关系就是电信的上下层级、同时又是不同业务系统的拆分，同层按照不同模块应该再行拆分，比如订单处理系统里对电商的对接接口，处理订单的处理容器等。3按照读写拆分：在业务系统里最主要的行为就是读与写，而读与写的侧重是不同的，如果能在架构设计上很好的针对性设计，就能起到事半功倍的作用，很多时候这也是对系统吞吐量提高以及长期迭代发展的重中之重，比如订单业务处理主流程的各个不同业务模块和电商调取物流系统里的物流轨迹系统，就是典型的写跟读的区别。

（3）异步处理：异步处理有不同层级，软件架构中不同模块或者业务处理行为之间数据流的异步，常见的异步处理可能利用的具体技术有：消息队列比如rabbitmq或kafka、中间表、缓存比如：redis的list类型。异步处理的意义：1、很多业务场景并发很大，如果想要全都实时同步处理，几乎是不可能完成的任务，那么在业务上稍微改变一下，使其可以异步处理或者延后执行，这就解决了问题。电商环境下秒杀类的操作常用这种方式来应对大并发，每个并发第一时间最初的业务处理系统做的事可能仅仅是验证基本数据可用性，找一个地方存储，通常这个地方是队列性质的，然后由队列的消费者程序（群）来进行消费处理，当然这个过程必然会加大单个请求的处理反应时间，但是一般是可以接受的，在业务上会需要为延长处理时间做一定的处理，比如加等待提示信息、加一定时间内不可重复操作的限制等，而在物流里队列异步场景很多，比如跨系统、跨模块间的数据传输，通常都并不需要即时，几分钟到一小时都在接收范围内。特别要注意异步处理应有两份数据可备查以作校验，用高可用、同步复制的技术就可以做到，各种主流mq基本都支持或者使用主备复制的db方案，重要的异步数据有必要作定时验证。