某达架构设计说明书

背景说明

业务背景

物流快递公司，主要进行同城快递业务

环境限制

• 公司技术部门人员 20 人；

• 开发周期 2 个月；

• 目标日订单量 50 万

  假设高峰期（如双 11）订单量为平日的 5 倍，即 250 万；

产品业务说明

业务拆分

运营管理端（仅包含 Web 端）

主要提供给运营，客服人员使用。主要功能：客服功能，投诉受理，退单审核，服务纠纷处理，数据统计分析，快递员信息录入等。

客户端（iOS，安卓，H5，小程序，web 端）

其中，web 端需要给商家提供独立的商家端，服务商家大批量订单处理；

主要提供给对外的客户，商家使用。功能主要是，下单退单，快递查询，快递投诉等。客户端，商家端功能相似，仅操作逻辑不同。

快递员端（安卓端）

快递员设备由合作方提供的定制设备，降低多环境开发成本，提升快递员工作效率，工作稳定性。

仅提供给快递员使用：接单，任务管理（快件流转：出入库，装车，签收或送达），代下单等；

业务图

技术架构说明

人员组织结构说明

人员分配情况

技术人员 20 人，配置为：

• 架构师：1 名

• 运维工程师：1 名

• 原生开发工程师：2 名

• 前端开发工程师：3 名

• 测试工程师：4 名

• 后端开发工程师：9 名

  其中包含：

  地图方案专项研发：1 名

  支付系统专项研发：1 名

  其余均为通用型后端开发：7 名

人员分配补充说明

地图，支付系统专项研发工程师：专项研发能力平台服务；

原生开发工程师：客户 iOS 端，客户安卓端，配送人员定制配送 App 安卓端；

通用型后端开发：4 人投入服务中台，3 人投入业务研发（可调配）；

前端工程师：研发产品：产品 web 端，小程序端，运营管理 web 端；

系统架构设计说明（后端架构说明）

服务情况

服务主要拆分如下：

• 能力平台（向中台提供服务，不接受外部调用）：

  资金服务：用于控制所有的资金流入/流出；

  地图服务：提供针对地图相关的能力，包括但不限于：路径规划，经纬度/地址互相转换，距离计算，物流流转方案计算等；

• 中台服务（向业务总线服务提供服务，不接受外部调用）：

  订单服务：提供订单管理，订单状态变更流转；

  物流服务：实际物流情况的流转管理；

  工单服务：提供投诉工单的管理，流转；

  用户服务：用于管理全部用户信息；

• 业务服务：

  业务总线服务：为实际业务提供服务基础服务，同时作为调用中台的服务总线；

  运营端接口服务：主要用于暴露接口，和少量运营端个性化服务；

  客户端接口服务：主要用于暴露接口，和少量客户端个性化服务；

  配送端接口服务：主要用于暴露接口，和少量配送端个性化服务；

  
  

服务架构图

部署构设计说明

业务部署说明

考虑开发周期，部署运维成本，初期仅部署华南地区，广州数据中心，后续将数据中心横向扩展到北京，上海。详细部署结构如下：

• 多地部署 CDN 加速：主要处理静态资源加速，该服务成本根据流量定价，运维成本较低，可多地部署；

• DNS 域名解析：域名解析，根据用户访问的域名，将流量，泛解析到我们的 Nginx 服务器；

• Nginx 服务器反向代理：Nginx 服务器进行流量的分发，根据流量目标的耳机线域名访问。反向代理服务器决定了所有流量的，虽然不承担计算服务，但还是需要部署备用服务器进行高可用储备；

• 负载均衡服务器：将流量分发到目标服务集群；

• Web 集群：整个服务的核心，内部子网将其联通，可配置独立网络安全权限，进行内部互相通信；

• Mysql 主从：读写分离，主机可用于读写，副本仅用于读流量；

• Redis 分布式缓存：主要存储数据库热点数据，和快递员当前位置信息；

• 消息队列：对于可能发生的波峰流量，将进入消息队列，进行削峰填谷；

部署架构图

业务架构补充说明

快递流转说明

流转描述

• 客户端：进行下单操作，全程可以查询订单状态；

• 快递员端：接单（取件），接单（配送），操作的同时更新订单状态；

• 订单服务：在用户下单时，生成订单，同时，根据快递员的操作和物流状态的更新，更新订单状态；

• 物流服务：在快递员成功取货后，创建物流单，然后根据物流进度实时更新物流信息；

流转时序图：

投诉流转说明

• 客户端，商家端：发起投诉请求；并同时可跟踪投诉工单的进度；（客户端一般不可自行对工单进行后续操作，工单由后台客服关闭）

• 运营端：查看投诉工单，操作投诉工单状态，关闭投诉工单；

• 快递员端：查看被投诉信息，提起申诉，或者接受整改；

订单状态流转说明

• 已取消：创建，和简单的过程中，下单人可以取消订单；

• 已创建：默认状态，由客户或者商家下单，暂无人处理状态；

• 已接单：被快递员接单以后的状态；

• 已取货：快递员已经取到快件；

• 运输中：由站点已经转交给物流，开始运输；

• 分拣中：物流转给站点，正在等待站点分配快递员；

• 配送中：快递员收到快件，正在进行配送；

• 已送达（已完成）：快递员已经将快件配送至指定地点；

召回过程：

配送过程，从已取货开始，到已送达完成之前，均可由下单人发起召回服务。

• 已取货（召回中）：快递员已经取到快件，被召回，快递员需将快件送回下单人手中；

• 运输中（召回中）：由站点已经转交给物流，开始运输，被召回，物流中心需要送回快件到起始站点；

• 分拣中（召回中）：物流转给站点，正在等待站点分配快递员，被召回，将不在进行下一步分配，分拣过程中应流转会物流中心；

• 配送中（召回中）：快递员收到快件，正在进行配送，被召回，快递员应将快件送回站点；

其实际业务，就是将配送流程反过来：

配送中发起召回，快递员将快件送回分拣中心，进入「分拣中（召回中）」，分拣中心将快件再转回物流中心，进入「运输中（召回中）」，然后流转到快递员手中，转入「已取货（召回中）」。召回这部分，订单状态对于下单人时不可见的，但是下单人可以查看订单状态——召回中。

状态流转图

最后的最后

说点补充内容，和心里话。

整体设计方向，针对描述要求的几个必备点，和建议做设计，尽量都满足。毕竟这是最基本的审题。不过部分设计，也做了修改，比如：

• 题目描述中的泳道图，个人就使用了时序图。其实主要原因是因为，老师的专栏里，泳道图貌似没有出现。说实话，不太会画。而且，个人认为时序图的表现能力是足够的；

• 针对通知 5km 范围内的快递员抢单问题。个人认为，其实现实业务中也是不存在的。因为，国内的快递员，会区分站点。只有同一个站点负责片区内的快递，才能涉及接单。也就是说，下单请求会先请求到后台，然后后台去识别地址属于那个站点管辖，然后下发到这个站点的快递员。所以，实际业务应该并不需要考虑 redis 存储快递员位置信息的功能；

• 很多架构图自认为自己还没有做的很好。一方面受时间和精力约束，这算是近期抽空做的第一版方案（其实，实际上架构方案也会有若干个版本）。另一方面是，很多业务，心里明白，但是不知道如何表述。比如，知道在双 11 之类的大促期间，下单量会飙升，这时候订单需要考虑进入消息队列，但是一直没有一个清晰的表述思路。算是空有一身武力，打不出来的感觉；当然，这也是我个人的能力不足以及需要提升的点；

• 关于虎头蛇尾。回头看了看自己的架构设计，其实是有一些虎头蛇尾的。无论架构文字描述的详尽与严谨性，还是架构图的美观程度，其实后半部分是有所下降的。部分原因是，前半部分，是一开始就构思好要这么画了。而后半部分，大方向做完，等到看作业详细要求的时候才补的。所以质量差距其实不小。这也是我下一版待完善的点（如果还有下一版的话）；

最后，说说心里话。

其实，从李老师的专栏一开始，就有一直在积极思考，并与李老师积极互动。中间，得到了一些认可之后，也确实有过一些飘飘然。这个作业，算是一个让自己进行实践的机会，同时也是让自己认清自己不足的机会。学习的步骤：学习+思考+运用+融会贯通。之前一直只能走到思考这一步。还没有机会能好好运用（受限于工作环境）。这次是一个很好的机会，认清了自己能做到什么，也认清了自己的不足。

一开始，其实认为自己在理论+思想上，其实已经基本算是及格的。但是，等到真的给自己一个业务，要去做设计的时候发现，并不是自己预想的那么简单。因为，这时候，你需要思考的并不是某一个单一的业务场景：秒杀业务，地理位置解决方案，全球化用户加速访问之类的。这时候，你面临的是一个更加真实的挑战，现在的情况是 xxxx，xxx。现在让你来做设计，你会怎么设计。

这其实跟个人的工作也有关系。自己的工作其实更多的也是解决某个局部的问题，或者局部的难题。就算需要针对问题设计解决方案，也仅仅是某个领域的解决方案。当你需要通过更高维度的全局去考虑的时候，你需要思考的地方远远不止当前业务那么简单。过程中你会不断的思考，有哪里是自己还没有想到的，有哪里是还存在隐患的，如果没有考虑到，上到真实的业务会产生怎样的不良结果。。等。

好在，最后也算是迈出了第一步，做出了从 0->1 的第一版。当然，也希望李老师能指出我的设计文档的问题与不足，现在专栏才到一半，有可能等专栏全部完结的时候，我能补足这些，作出更优雅完善的设计！