正文
早期，外卖整体架构简单、灵活，公共业务逻辑通过jar包实现后集成到各端应用，应用开发部署相对简单。比较适合业务早期逻辑简单、业务量较小、需要快速迭代的情况。但是，随着业务逻辑的复杂、业务量的增长，单应用架构的弊端逐步暴露出来。系统复杂后，大家共用一个大项目进行开发部署，协调的成本变高；业务之间相互影响的问题也逐渐增多。
早期业务处于不断试错、快速变化、快速迭代阶段，通过上述架构，我们能紧跟业务，快速满足业务需求。随着业务的发展以及业务的逐步成熟，我们对系统进行逐步升级，从而更好地支持业务。
2014年4月，外卖订单量达到了10万单/日，而且订单量还在持续增长。这时候，业务大框架基本成型，业务在大框架基础上快速迭代。大家共用一个大项目进行开发部署，相互影响，协调成本变高；多个业务部署于同一VM，相互影响的情况也在增多。
为解决开发、部署、运行时相互影响的问题。我们将订单系统进行独立拆分，从而独立开发、部署、运行，避免受其它业务影响。
系统拆分主要有如下几个原则：
-
相关业务拆分独立系统；
-
优先级一致的业务拆分独立系统；
-
拆分系统包括业务服务和数据。
基于以上原则，我们将订单系统进行独立拆分，所有订单服务通过RPC接口提供给外部使用。订单系统内部，我们将功能按优先级拆分为不同子系统，避免相互影响。订单系统通过MQ（队列）消息，通知外部订单状态变更。
独立拆分后的订单系统架构如下所示：
![]()
其中，最底层是数据存储层，订单相关数据独立存储。订单服务层，我们按照优先级将订单服务划分为三个系统，分别为交易系统、查询系统、异步处理系统。
独立拆分后，可以避免业务间的相互影响。快速支持业务迭代需求的同时，保障系统稳定性。
订单系统经过上述独立拆分后，有效地避免了业务间的相互干扰，保障迭代速度的同时，保证了系统稳定性。这时，我们的订单量突破百万，而且还在持续增长。之前的一些小问题，在订单量增加后，被放大，进而影响用户体验。
比如，用户支付成功后，极端情况下（比如网络、数据库问题）会导致支付成功消息处理失败，用户支付成功后依然显示未支付。订单量变大后，问题订单相应增多。我们需要提高系统的可靠性，保证订单功能稳定可用。
另外，随着订单量的增长、订单业务的复杂，对订单系统的性能、稳定性、可用性等提出了更高的要求。
为了提供更加稳定、可靠的订单服务，我们对拆分后的订单系统进行进一步升级。下面将分别介绍升级涉及的主要内容。
性能优化
![]()
系统独立拆分后，可以方便地对订单系统进行优化升级。我们对独立拆分后的订单系统进行了很多的性能优化工作，提升服务整体性能，优化工作主要涉及如下几个方面。
异步化
服务所需要处理的工作越少，其性能自然越高。可以通过将部分操作异步化来减少需要同步进行的操作，进而提升服务的性能。异步化有两种方案。
异步化带来一个隐患，如何保障异步操作的执行。这个场景主要发生在应用重启时，对于通过线程或线程池进行的异步化，JVM重启时，后台执行的异步操作可能尚未完成。这时，需要通过JVM优雅关闭来保证异步操作进行完成后，JVM再关闭。通过消息来进行的，消息本身已提供持久化，不受应用重启影响。
具体到订单系统，我们通过将部分不必同步进行的操作异步化，来提升对外服务接口的性能。不需要立即生效的操作即可以异步进行，比如发放红包、PUSH推送、统计等。
以订单配送PUSH推送为例，将PUSH推送异步化后的处理流程变更如下所示：
![]()
PUSH异步化后，线程#1在更新订单状态、发送消息后立即返回，而不用同步等待PUSH推送完成。而PUSH推送异步在线程#2中完成。
并行化
操作并行化也是提升性能的一大利器，并行化将原本串行的工作并行执行，降低整体处理时间。我们对所有订单服务进行分析，将其中非相互依赖的操作并行化，从而提升整体的响应时间。
