系统架构师训练营大作业（一）- 同城物流快递业务系统架构设计



本架构设计将从“背景分析、产品需求”、“架构关键点分析”和“架构策略”、“业务建模”、“系统建模”、“部署架构”、“组织分工协作”等方面进行设计，下图为大纲（截取至PPT）。



一、项目背景分析：







架构设计重点关注点：

1.系统要求2个月就上线，包括需求分析、设计、开发、测试、上线等工作，工期紧任务重。为了权衡系统上线要求和系统演变的需求，系统第一版本采用单体应用，但是基于领域驱动设计，划分领域，虽然第一版所有领域都部署在一个单体中，但是单体应用内部要满足高内聚低耦合，层次分明、边界清晰。在水平方向遵循DDD的四层架构，在垂直方向以聚合为单位划分逻辑边界，后续演变可以把聚合独立成微服务。通过建设“业务中台”、“数据中台”双中台，为企业引入一种面向未来的，可持续优化和扩展的长效机制，让业务、数据沉淀成服务，提高企业的响应能力；（可分阶段实施，本阶段以快速的推出第一版为第一要务）



2.团队有20人应该分层几个组，每个组5-6人，遵循康威定律，每个组负责一个细分领域。



3.由于预期一年内系统的并发量会从日1万增长到50万，系统的吞吐要求扩容50倍，为了让系统具有可扩展性，能够水平伸缩，在进行数据库设计、缓存设计时，采取预分区策略，预定义一定数量的分区，比如50个，允许多个逻辑分区对应一个物理节点。



4.下单和抢单通过消息中间件解耦，由于下单的用户比快递员多，为了平衡两边的处理能力，使用消息中间件来削峰填谷，降低耦合性，提高系统可靠性。



5.下单和订单跟踪对地理位置信息有非常高的实时性要求，如何同时保障高并发和高性能是关键。在技术设计上可以采用消息中间件+Hbase方式处理，消息中间件负责接收各种终端上报的地理位置，HBASE用于存储格式化的地址序列。下单和订单跟踪从HBASE中读取数据。



6.建立数据中台，基于大数据平台、数据仓库理论，把数据资产化、数据服务化和孵化数据产品化，提供各层级、各角色数据分析需要，同时业务与数据结合形成闭环，让数据驱动业务。



建立业务中台、数据中台，双中台战略



“业务中台”与“数据中台”各自有应用场景和问题域，但是两者并不是孤立存在，如何理顺和建立两者之间协同关系，发挥1+1>2的价值显得尤为重要，上图给出了“业务中台”与“数据中台”协同框架，清晰的描述了：

1.        业务中台和数据中台的共同目标是为企业“输出洞察能力”、“快速响应能力”；

2.        以市场为驱动，捕获市场变化，提供洞察能力；以客户为中心快速响应，提供创新能力；

3.        业务中台对能力固化、赋能业务，数据中台对数据资产化，提供数据服务；业务数据化成为数据中台的输入并资产化，数据业务化，驱动业务变革和优化。业务数据化、数据资产化、资产服务化、服务业务化（数据驱动业务），四种转换周而复始，围绕企业价值提升，不断的迭代、螺旋上升。

4.        业务中台通过领域建模和微服务技术落地，数据中台通过数据资产建模和大数据技术落地。

5.        整个技术体系要求，遵循“标准统一”、“技术统一”、“平台统一”规范。规范和标准是重要的治理工具，业务中台、数据中台建设是持续过程，无法通过一次项目就完成建设，所以必须有可以长期遵守的标准、规范、框架、机制，来指导和约束跨组织、跨项目工作，推进战略战术的落地。





用例分析：



顶层业务蓝图规划、领域建模、微服务设计



业务活动如下：

1.用户（寄件人）注册成为会员，在平台上填写快递信息并下单。

2.系统地址计算模块结合用户位置和快递员位置，给附近的快递员推送订单；

3.快递员抢单确认，锁定订单；

4.快递员到现场取件，用户现场付款，也可以下单后就直接付款；

5.快递员投递快递过程中，实时上报地址信息，用户可跟踪；

6.快递送到后，接收人签收，快递员确认；

7.用户（寄件人）跟踪快递信息，并对服务进行评价。





状态设计如下：



组件设计如下：

1.核心组件包括：订单组件、支付组件、地理位置组件、用户组件、快递员组件、数据应用组件、微服务运行平台、大数据平台平台等。

2.按照架构策略要求，规划将建设双中台，“业务中台”和“数据中台”。业务中台对能力固化、赋能业务，数据中台对数据资产化，提供数据服务；业务数据化成为数据中台的输入并资产化，数据业务化，驱动业务变革和优化。

3.数据中台基于大数据平台、数据仓库理论、数据治理和服务化理论建设，通过数据应用平台和数据产品对外输出数据服务，驱动业务。







系统部署架构：

部署架构设计考虑两个因素：1.为技术架构涉及的中间件、组件、服务、应用提供运行环境，2.提供的集群方案，确保系统高可用、高性能。基于SpringCloud构建微服务运行平台的部署架构分为：用户层、接入层、SpringCloud组件、应用集群、存储器、监控等层次。本部署架构与基于Nginx的部署架构本质区别在于：在Nginx后，引入了SpringCloud核心组件，来构建分布式服务治理层，请求经过Nginx后，并不直接发送给后端应用，而是先经过分布式服务治理层，再进行分发；



微服务运行平台技术选型：

系统采用“厚平台、薄应用”、“服务化、组件化”的设计理念，采用前后端分离技术，采用SpringBoot+SpringCloud体系作为分布式治理平台，支持微服务落地。平台提供服务注册发布、安全网关、负载均衡、反向代理、限流容错、系统监控、日志分析、调用链分析、分布式事务等治理能力。





技术栈选型（含SpringCloud平台）：





团队组织结构划分和分工：

通过领域划分、微服务设计、以及组件规划，把系统划分成多个组件，整个团队有20人，需要划分成工作组，遵循康威定律，每个组负责一个或多个细分领域（组件）。

共分为六个工作组：订单服务工作组、支付服务工作组、地理位置服务工作组、用户信息工作组、快递员信息工作组、微服务平台搭建和运维工作组、大数据平台搭建和运维工作组（含数据产品开发）。





参考 DDD 分层架构模型来设计微服务代码模型：

系统要求2个月就上线，包括需求分析、设计、开发、测试、上线等工作，工期紧任务重。为了权衡系统上线要求和系统演变的需求，系统第一版本采用单体应用，但是基于领域驱动设计，划分领域，虽然第一版所有领域都部署在一个单体中，但是单体应用内部要满足高内聚低耦合，层次分明、边界清晰。在水平方向遵循DDD的四层架构，在垂直方向以聚合为单位划分逻辑边界，后续演变可以把聚合独立成微服务。



包括用户接口层、应用层、领域层和基础层，分层架构各层的职责边界非常清晰，又能有条不紊地分层协作。

用户接口层：面向前端提供服务适配，面向资源层提供资源适配。这一层聚集了接口适配相关的功能。可理解为BFF。

应用层：实现服务组合和编排，适应业务流程快速变化的需求。这一层聚集了应用服务和事件相关的功能。

领域层：实现领域的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。

基础层：贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。

业务逻辑从领域层、应用层到用户接口层逐层封装和协作，对外提供灵活的服务，既实现了各层的分工，又实现了各层的协作。因此，毋庸置疑，DDD 分层架构模型就是设计微服务代码模型的最佳依据。