交易系统架构

一直以来表达能力都是自己的短板，不知道如何分享出自己觉得比较好的设计，所以决定好好的整理一下这几年使用的架构，以一种更加简单、清晰的思路将之前工作中的系统设计分享给大家。这是第一篇，后面会持续分享。

本博客主要从架构层面讨论交易系统的设计，不涉及细节。细节内容可以参考《交易体系-交易、支付、物流、退款退货》

一 主要内容

本博客主要从以下几个方面讲述交易系统架构：

交易系统的业务域是什么？即交易系统应该负责那些内容。

面对多样性的业务场景，交易系统如何承接他们？即交易系统的业务扩展性如何保证。

交易系统的复杂性问题，以及如何处理，特别是业务、系统解耦问题。

事件驱动流程。

简述高并发与高可用技术。

二 交易

首先我们聊聊什么是交易，以及交易系统的业务域。

1.   概念

交易是一种行为：是buyer在某一时间以某一价格购买了seller的一个或多个商品。现实世界中，这种行为是价值的交换；系统中，这种行为产生的是订单。

订单是一种契约：这种契约要求买卖双方按照订单的内容进行履约。以实物商品交易为例，buyer需要付钱契约才有效，seller需要将商品寄送给buyer。

交易至少涉及以下模型：买家、卖家、订单。

2.   交易

以实物商品交易为例，交易包括以下环节：

注意：这是一个完整的交易涉及的业务，但如果将以上所有业务都放在一个系统中却是一个非常糟糕的注意，后面会详细讨论此点。

3.   业务域分析

1)    下单

卖家必须有某个商品才能卖给买家，所以交易必然需要与商品系统打交道。为了让买家掏腰包，卖家、平台会想方设法的使用各种营销手段，吸引并促进交易的达成。常见的营销手段有：优惠（单品优惠、跨类目优惠、店铺优惠、平台优惠以及其他的组合方式）；优惠券（单品优惠券、跨类目优惠券、店铺优惠券、平台优惠券以及其他组合方式）；使用积分、金币等虚拟资产抵扣；多次付款（例如预付款等）。

相关业务模型：交易订单、商品、优惠、优惠券、积分、金币等。 

2)    付款

为了方便用户购买，很多时候需要支持多种支付方式，例如：支付宝、微信、银联等。

相关业务模型：支付订单

3)    发货与配送

对于拥有成千上万SKU的大商家而言，他们拥有自己的仓库，这些仓库也可能分布在不同的城市，所以他们需要能够管理所有的货物，直到他们的详细信息，选择一个最为经济、快捷的仓库给买家发货。

对于仅拥有几十上百SKU的小商家而言，他们对自己有多少货物心中有数，不需要仓库，甚至直接从家里发货。

发货是一个复杂的过程，如果用户购买了多件，可能会打包一起发送给买家，也可能将一个大件物品拆成多个物流单发给买家；配送的过程也很复杂，涉及物流订单的集散以及派送过程。不过幸运的是很多情况下这些都不需要我们自己实现，直接用第三方的物流服务，我们尽关心物流信息即可。

相关业务模型：商品、商品SKU、货物

4)