1、前言

我相信，绝大部分程序猿在现实工作中，都会听到架构这个词，但是，什么是架构呢？相信大部分人一碰到这个问题都会很懵逼。去网上搜一下架构这个词，会出现很多文章，然鹅看了很多文章，依然不知道什么是架构，更别说遇到具体业务时如何去设计架构了。架构这个词本身包含的东西太多太多了，一个技术框架需要架构，一个应用系统需要架构，大规模的分布式服务需要架构，甚至产品业务内部也需要架构。由于能力限制，我无法系统地阐述架构的理论知识，反倒是有一点点架构演进的实际经验，因此就以故事的方式写下来。故事里的人和事都是假的，架构演进的路径有些是自己的经验，有些是别人的经验，为了讲故事强行把它们统一进来了。

2、从零到一

富二代小明开了一家跨境电商创业公司，经过一年的产品迭代和努力运营，逐步建立了业内的口碑，越来越多的买家开始关注小明家的电商平台，也有越来越多的卖家开始和小明谈合作，想要入驻平台。原来由于用户量少，用户拍下了商品后，小明就不管了，后续的物流都是由卖家负责，这就导致了小明家的物流体验参差不齐。随着用户量的增加，物流体验成为平台的短板，于是在今年的年初战略会议上，小明果断成立物流部门，该部门的目标是通过整合物流商的能力，为商家输出统一高效的物流服务，从而提高消费者的物流体验，该部门底下分三个子部门，BD部、运营部以及产品技术部，三位子部门的总监直接汇报给小明。

老王作为产品技术部总监，开始着手设计1.0版本的物流系统。在他看来，整个物流部门刚刚成立，后续业务怎么玩完全不确定，在这种情况下，就需要轻装上阵，对于物流系统的架构就是怎么简单怎么来，后续随着业务的发展再不断优化和迭代。于是他设计了如下的1.0版本架构：

在老王的设想中，物流平台就是用来撮合商家和物流商的，因此，就有了物流订单中心，一份物流订单的生命周期就代表一件货物经过物流商从商家手中送到了指定地点。接着，在商家端，需要有一个发货平台供商家使用，商家可以发货，退货，取消订单，查看物流订单等等，而在物流商端，由于大部分物流商都有内部的IT系统，因此只需要开发一个网关和物流商对接就行。物流订单的创建直接监听交易平台的消息，而不用商家手工创建，提高了商家的体验。

完成了上面的初步架构，老王就开始调动资源将架构进行落地。首先是团队的划分，老王大致划分了三个业务团队：快递发货台团队，物流订单团队以及网关团队。快递发货台团队由一个前端两个后端组成，物流订单中心则由两个后端组成，网关团队则由一个资深后端顶着，所有的团队都除了进行业务开发，还需要负责本团队业务的自测，最后的系统间联调由一个测试主导，网关与物流商之间的外部联调则由另一个测试负责。

由于担心团队成员技术经验不够，独立设计系统可能会出问题，老王特地把各个系统的技术难点列出来，让每个技术团队回去思考实现方案，最后给出一份详细的技术方案。

1、物流订单中心

a)、需要在高并发环境下保证订单创建不重复

b)、需要在高并发环境下保证订单更新的原子性

c)、实现数据库分库分表，并实现全局ID生成机制

d)、在分库分表的基础上，需要满足买家视角、卖家视角的订单查询

e)、实现历史数据归档

f)、设计一套完整的状态机

g)、设计一套完整的消息

h)、保证订单状态变更和发送消息同时成功或者同时失败（分布式事务）

i)、定义一套合适的对外的接口以及数据模型

2、快递发货台

a)、设计一套抽象而又稳定的业务接口，同时支持不同的业务。也就是说，一个接口可以被新业务使用，而不是每个新业务都需要重新开一个接口。

b)、尽量做到业务流程可复用，而不是每个业务都是一条业务流程。

c)、保证前端安全，比如防止XSS攻击、CSRF攻击等

d)、保证接口安全，比如使用HTTPS保证传输安全、IP黑名单防止流量攻击等等

e)、保证数据安全，比如防止SQL注入

3、网关中心

a)、实现身份认证（HTTPS）

b)、实现权限管控

c)、实现日志审计，保存30日内的全量日志，随时可追溯

d)、自定义一套网关协议

e)、实现内部系统与外部系统之间的请求转发

f)、保证高并发环境下的系统性能和稳定性

经过一段时间紧张的开发，物流平台1.0终于上线了，商家不仅可以选择更好的物流服务，而且价格还更实惠。就这样，使用物流平台的商家越来越多，消费者对物流体验的评价也慢慢好转。后来，产品经理还开发了更丰富的物流服务，比如货到付款，预售发货等等，这些物流服务在交易平台露出，得到了很好的反馈。

3、第一次架构升级

随着用户量和入驻商家的不断增加，小明成功完成了新一轮融资，公司的品牌也开始得到加强，原来入驻小明的都是一些个体户商家，现在陆陆续续有一些中等商家也希望入驻。由于中等商家往往有自己的ERP，他们不太愿意用外部系统，因此他们希望可以把我们的物流平台和他们的ERP进行对接。

小明把对接ERP这个项目交给了老王，但是由于老王在出差，因此老王让内部技术团队先一起讨论出一个方案来。经过一天的讨论，大家一致得出了下面的方架构1.1：

老王第一时间拿到方案后，总感觉哪里不对，但是由于没有具体和业务部门聊过，所以也说不出哪里不对。老王出差回来后，第一时间和业务部门老大了解具体的对接方案，同时找到产品经理，和他一起梳理具体的业务流程。最后发现ERP发货并不仅仅是对接个网关那么简单，它涉及到的业务流程已经和小商家的快递发货流程不一样了，因此上面1.1架构并非最优解。老王希望快递发货台的业务范围仅仅是小商家，而不是什么都做，另外在1.1架构中，网关中心不仅对接了ERP，而且对接了物流商系统，这样一来，网关中心就会成为业务聚集地，所有的外部系统都需要和网关中心对接，这是一种非常高的耦合。经过一番思考，老王最终得到了下面的架构：

老王把所有发货相关的业务流程单独抽象出一个发货中心，发货中心类似于一个平台业务，提供统一的发货服务，它内部会控制物流订单的状态变更以及处理与物流商之间的交互，而快递发货台和ERP发货台类似于垂直业务，快递发货台专门供小商家使用，让小商家可以在Web端发货，ERP发货台则不仅是一个网关，而且提供了一套ERP发货的解决方案，专门供类似的中等商家的ERP系统使用。

可以看出，上面的架构和原先的架构已经有了明显区别，其根源是业务发展，而业务发展导致了问题域的发展，进而导致了架构的演变。老王把上面的架构称为2.0。

4、快递扩张

自从物流平台升级为2.0之后，又陆陆续续增加了很多使用ERP的商家，这时候业务部门发现，商家端的数量和质量已经不是瓶颈，瓶颈在于物流商的数量以及质量，现有的物流商还是太少，其中一个很重要的原因是，物流平台能够接入的是三通一达这样的全能公司，也就是说它可以支持任意地址之间的配送，然而事实是存在很多小公司，在某个地区的配送能力非常强，超出这个地区就无能为力，这些小公司按理来说也应该能够接入物流平台。为了解决这个问题，老王对物流平台的架构进行了新一轮的改造：

首先将原来的网关中心升级为配送中心，配送中心不仅是网关，而且会创建配送订单，用来跟踪每个配送公司的物流状态，配送订单和物流订单最大的不同是，配送订单是面向线下实体的，而物流订单仅仅是一种契约。配送订单的状态机都是面向真实的快递配送流程的，而物流订单的状态机是面向商家的。配送订单的状态往往比物流订单更丰富。其次，老王新增了一个资源中心，所谓的资源就是物流商，而资源中心的职责就是记录哪个物流商拥有哪些配送能力，这样一来，能力受限的小公司也可以接入到物流平台中。快递发货台在展示订单时，会根据订单地址去资源中心路由资源，然后展示可以选择的物流商，ERP发货是通过发货中心发货，发货中心会为ERP发货的订单自动路由合适的物流商。发货中心将资源下发给配送中心，配送中心根据资源自动下发给合适的物流商。

上面的架构虽然和2.0有了变化，但是仅仅属于优化，没有发生根本性的业务变化，因此上面的架构可以称为2.5。

5、仓储为王

随着商家端体验不断的优化，物流商端更多的公司入驻，小明的平台越发壮大，并完成了新一轮的融资。于是，小明开始和大公司进行战略合作：商家端邀请明星公司入驻，同时邀请国际级物流商入驻物流平台。在物流商入驻的过程中，小明却发现，国际级的物流商都是玩的仓储物流，它们会在各个大都市圈设立大的仓储中心，然后通过仓储中心就近发货，从而降低自己的成本。然而，小明的物流平台竟然完全不支持仓储，于是，一个公司战略级别的项目又落到了老王的身上：尽快增加仓储物流！

虽然小明很着急，但是老王一点也不急，因为增加仓储物流对现有的架构并没有造成太大的冲击：

上面是增加仓储物流后的架构，暂且称为2.8。和配送中心一样，仓储中心也会创建仓储订单，并设计一套状态机来管理实际的仓储操作，同时仓储中心作为一个网关会对接不同的外部仓储系统。资源中心会增加一个新的类型：仓，仓也会有相应的能力。发货中心不仅可以路由快递资源，而且可以路由仓资源。

很快，随着仓储中心的建立，仓储物流也被纳入到了物流平台中，而随着大公司的入驻，小明的公司业务开始了新一轮的扩张。

6、小商家也可以玩大仓储

随着仓储物流的不断入驻，小明对物流平台有了新的思考。目前的物流服务都是和特定的商家结合，比如小商家用三通一达比较多，而大商家用特定的仓储物流比较多，然而理想的情况下，商家是不需要感知具体的物流服务的，他们只需要选择时效快价格适当的服务就可以，服务的具体组合应该由物流平台去完成。进一步地，物流平台的商业闭环应该是：入驻好的物流商，将这些物流商包装成能力，将这些能力组合成服务，将这些服务提供给商家，未来甚至可以开放给全社会。针对这些思考，小明准备启动一个小项目试试水：将仓储服务提供给小商家！

对于小明的项目，业务部门显然意见比较大，毕竟我们只是个平台，并不掌握仓储资源，而要拿到仓储资源提供给小商家，最终的成本可能相当高。在小明的力排众议下，决定拿一个仓进行试水，物流平台开发一个仓储发货台，业务部门谈一个仓资源进行配合。

对于老王来说，这个项目让原本比较完善的架构增加了新的东西，暂且叫2.9吧：

这次新增一个仓储发货台，类似快递发货台，让商家可以进行仓储发货。同时发货中心对接仓储发货台，提供仓储发货服务。最终的结果也如业务部门预料的那样，把仓储服务提供给小商家是一件得不偿失的事。

7、第二次升级

老王觉得，架构2.9应该是一个阶段性的里程碑了，除非出现重大的业务变更，否则这个架构是可以一直用下去的，然后，一次故障让老王彻底推翻了之前的结论。某天晚上，订单中心部分机器被误操作下线，导致集群机器数减少，由于订单中心是所有其他系统的依赖，平时系统压力就比较大，这时候由于部分机器下线，集群负载猛然升高，造成了雪崩效应，最终导致整个集群挂掉。虽然工程师第一时间恢复了机器，然而这次宕机却使整个物流平台的所有服务都受到了不同程度影响。事后复盘发现，物流订单中心已经在不知不觉中变成了整个平台的单点，整个物流平台的心脏就是订单中心，程序猿可以挂，物流中心不能挂！

诚然，故障是由工程师误操作引发的，然而根源是架构问题。痛定思痛，老王决定对整体架构进行一次升级，架构3.0：

老王经过深入的思考认识到，物流订单中心之所以是单点，是因为它既承担了商家端的职责，又承担了物流商端的职责。然而现实是，商家端只需要知道物流的起始和终点，而不关心实际物流运输的过程，物流订单的职责应该是面向商家端的，因此需要将物流商端的职责单独抽离出来，成立订单履行中心。订单履行中心会有履行订单，它负责跟踪实际的履行过程，包括仓储作业，配送作业两段。履行订单会对外发送消息，发货中心只需监听终点的消息，然后去变更物流订单状态。这样一来，商家端和物流商端就进行了解耦，物流订单中心也不再是全平台的单点。除了订单履行中心，老王还增加了一个订单调度中心，这是为了削峰。物流订单的创建峰值是和交易订单创建峰值同等数量级的，而物流订单的履行则取决于物流商的系统，两者在大促的时候完全不是一个数量级的，因此增加一个订单调度中心，让订单以下游可承受的速度进行下发履行，避免上游洪峰把下游系统冲垮。

8、尾声

虽然小明的故事还远远没有结束，然而本文到这里就要结束了，在此，我想说一些我对架构演进的思考：首先，架构演进是业务驱动的，但又不局限于业务，在架构演进的过程中，系统性能以及稳定性等方面也需要考虑，其次，从上面的故事可以看出，架构设计其实就是对问题的划分和解决的过程，最后，架构也有好坏，由于业务的不确定性，架构往往需要演进，然而好的架构演进往往很容易，差的架构却很容易崩盘推倒重来，架构到底如何演进，非常考验一名架构师的功底。