如何做架构设计说明书

背景

需求

1.数据

举例来说：

• 如果这是一个政府行政办公的系统，那么办公流转过程就是数据，每个环节办理状态就是数据；

• 如果这是银行信用卡管理系统，那么用户信用卡可用金额、账单、有效期等状态信息就是数据，每笔刷卡流水就是数据；

• 如果这是电子商务系统，那么商品信息、用户订单、购物车信息就是数据。。。等等，

2.计算

还是以上面的例子来说：

• 政府行政办公系统需要将线下的纸质签字盖章从发起请求到办结的全过程搬移到线上由系统处理，

  那就需要转化成线上的在线申请、办理、流转、通知、办结、存档等过程，这些过程在线下可能有不同的部门来负责，

  但是线上将由我们设计的系统完全支撑；

• 对于银行信用卡管理系统，需要将银行对信用卡的管理业务转化成具体的设置或查询可用金额、账单、有效期等信息的功能，

  还有记录和统计用户消费流水等，如果业务有需求，甚至需要根据用户的消费流水对用户画像，以便进行精准营销等所谓的大数据分析模块；

• 电子商务系统也是一样，需要系统提供向用户展示商品信息，记录用户点击购买后的购物车信息，创建或更新用户的订单信息，

  以及跟踪订单从仓库打包到送达的物流信息。。。等等，

常见的动作有：

• 数据跟踪记录、

• 查询统计、

• 修改更新、

• 导出展现、

• 汇总分析等。

当然有一点需要注意，我们在寻找计算因素的时候一定要基于计算机世界的客观现实，毕竟计算机不是万能的。

3.关系

明确了数据及如何处理数据，架构设计接下来要做的就是如何平衡好各种相互影响的关系，这些关系是所有我们能想到的会影响到系统的矛盾体，

• 数据处理效率与处理能力的关系、

• 数据体量与存储能力的关系、

• 数据展现与用户要求的关系、

• 系统部署与网络环境的关系、

• 系统建设与建设成本的关系、

• 系统易用性与客户要求的关系等等，

在做架构设计的时候要尽可能多的考虑到这些关系，并根据实际情况划分关系的重要程度，重点保障那些重要性高的关系，
毕竟再完美的架构设计也无法平衡好所有的关系，从这个角度来说，架构设计是一种平衡的艺术。
当然，要准确找出这些关系，并对它们划分重要性等级，还需要做到按等级进行平衡是需要经验积累的，非一朝一夕之功，
这也是人人都能做架构设计，但不是人人都能做好架构设计的原因。好在这一步并不是完全无规律可循的，
首先我们讲如何找出这些关系，虽然涉及影响一个系统的矛盾体很多，

但是大致上我们可以从以下3个方向来挖掘出这些关系：

1. 与人相关的：

这里的人包括筹建系统的甲方、建设系统的乙方、以及使用系统的用户，
- 对于筹建系统的甲方来说，他一般关注系统的建设进度、成本、质量等，
- 对于建设系统的乙方来说，重点会关注建设范围、风险、开发工具、实施环境等，
- 对于用户来说，更关系系统易用性、界面友好，操作舒畅、能帮其解决实际问题等。

涉及到与人相关的关系，除了从经验中获取，更重要的是需要在前期系统设计的过程中通过调研的方式，
多与相关的干系人沟通，从他们那里获取，这也是为什么系统建设一般都是有需求调研过程的原因。
针对与人相关的关系这部分设计内容一般体现在架构设计说明书中的概述里，包括项目目标、项目背景及其他说明等，
当然与用户相关的一般也会在非功能性上有所体现，如易用性、可用性、安全等；

2. 与外部系统相关的：

主要指其运行所在的操作系统及服务器，以及与之交互的外部系统，系统需要运行在服务器特定的操作系统上，受服务器操作系统计算存储网络等因素影响，
需要考虑服务器计算能力是否能处理数据、存储能力是否足够、网络是否稳定、如果服务器计算存储网络能力不够如何扩展等；
与外部系统的交互方面，本系统需要从外部系统获取哪些数据与能力、需要为外部系统提供哪些数据与能力、交互方式是什么、交互协议如何等。

    一般来说，服务器的能力总是会有不够的，尤其是设计大数据量处理，大量用户同时访问的系统时，
    这就需要我们根据系统的特点提前做好扩展的设计，高并发处理、分布式理论、多机房部署等这些技术概念可以给我们很好的指引，
    这也是为什么架构师一定要眼界开阔的原因。

这部分的设计内容一般体现在架构设计说明书中的

• 逻辑架构、

• 技术架构、

• 接口设计、

• 部署架构、

• 性能、

• 可维护、

• 可扩展等非功能性设计上

3. 与数据相关的：

数据是系统处理的主体，需要划分本系统所处理的数据与外部数据的边界，明确与外部数据的流向关系，
还需要根据实际业务来区分数据内部之间的关系，数据如何划分、各部分数据的边界在哪、与整体数据的关系如何等等。
在划分与外部数据的边界时要基于本系统所承载的实际业务内容，从业务出发，那些只受本业务影响的数据肯定在边界内，
而本业务与其他业务共同影响的还需要进一步分析哪方是影响主体，如果本业务是影响主体，那么在边界内，但是需要考虑提供给外部系统的交互接口，
如果本业务非影响主体，那么再看是否有间接影响或关联影响，一般来说这部分数据都要考虑与外部系统的交互关系。
对于边界内的数据关系也是如此，可以根据业务特点划分一些区块，每个区块内又是一个相对独立的单元，
与相关的其他区块单元存在哪些数据上的直接或间接影响，他们之间如何交互等。所有这些关系都是我们需要发现并在架构设计时考虑的。
针对这部分的设计内容一般体现在架构设计说明书中的数据架构、整体架构里。

重要需求相关>特色亮点需求>甲方相关>用户相关>乙方相关>外部系统相关>外部数据相关>内部数据相关>其他次重要的数据，

• 筹建系统的甲方要求的低成本与高质量、

• 系统间数据交互与操作舒畅等，

技术评审提纲

业务项目千差万别，没有一个统一的方法论完成架构设计和技术评审，架构设计只需要从某些关键点来表达系统即可，
提纲就是用来帮助大家做架构评审的工具，帮助大家整理思路并形成可实施的方案，
因此在做系统设计时，可有选择性的参考此提纲，根据业务特点来完成一个可实现的有效的架构设计。

现状

业务背景

• 项目名称

• 业务描述

技术背景

• 架构描述

• 当前系统容量(系统调用量平均值)

• 当前系统调用量峰值

需求

业务需求

• 要改造的需求

• 要实现的需求

性能需求

• 预估系统容量(预估系统调用量平均值)

• 预估系统调用量峰值

• 其他非功能质量

方案描述

方案1：

• 概述

一句话概括方案的亮点，比如说: 双写，主从分离，分库分表，扩容，归档等。

• 详细说明

方案的具体描述，文字描述不清楚的话可以结合图（任何图：UML，概念图，框图等）的方式说明，
如果是改造方案最好突出变动的地方，以下列举了几种描述的角度：

* 中间件架构（应用服务器、数据库、缓存、消息队列等）
* 逻辑架构（模块划分、模块通信、信息流、时序等）
* 数据架构（数据结构、数据分布、拆分策略、缓存策略、读写分离策略、查询策略、数据一致性策略）
* 异常处理，容灾策略，灰度发布

• 性能评估

给出方案的基准数据，并按性能需求评估需要使用的资源数量。

单机并发量
单机容量
按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)
伸缩方式

• 方案优缺点

列出方案的优缺点，优缺点要具有确定性，不要有“存在一定风险”这种描述，也就是要量化。

方案2：

等等

方案对比

对比可选方案，并给出选择这种方案的理由，选择倾向的方案，

风险评估

标识所选方案的风险，提出解决此风险发生时候的应对策略，比如：上线失败时的回滚策略。

工作量评估

性能和容量评估案例

背景

物流系统包含如下两个质量优先需求：

• 维护会员常用地址，下单时提供会员地址列表。

• 下单时异步产生物流订单，物流系统后台任务从第三方物流轮循拉取物流状态，已经下单用户查询订单的物流订单和物流记录。

目标数据量级

选取行业内一线电商平台的量级作为目标：

• 会员量2亿，平均增长5万/天。

• 平时订单量400万/天，所有订单下单时段集中在9:00-23:00，促销日订单量1400万/天，50%订单下单时段集中在晚上7:30-8:30和晚上22:00-23:00。

量级评估标准

• 通用标准

• 容量按照峰值5倍冗余计算。

• 会员常用地址容量按照30年计算，而物流订单时效性较强按照3年计算。

• 第三方查询接口5000 QPS。

• Mysql

• 单端口读：1000 QPS

• 单端口写：700 TPS

• 单表容量：5000万条

• Redis

• 单端口读：4万 QPS

• 单端口写：4万 TPS

• 单端口内存容量：32G

• Kafka

• 单机读：3万 QPS

• 单机写：5000 TPS

• 应用服务器

• 请求量每秒峰值：5000 QPS

方案

方案1: 最大性能方案

需求1.  会员常用地址

• 提供Restful服务增加会员常用地址。

• 提供Restful服务获取会员常用地址列表。

数据库资源评估：

读QPS：

会员每次下单，拉取一次会员地址列表，按照促销日订单量1400万/天，50%订单下单时段集中在两个小时内计算：

(1400万 × 0.5) / (2 × 60 × 60) = 1000/秒

容量评估按照5倍冗余计算，读QPS峰值1000/秒 * 5 = 5000/秒，需要5端口数据库服务读。

写TPS：

假设每天增加的会员全部添加一次常用地址，并且高峰期会员下订单时有20%的会员会增加一条常用地址：

(1400万 × 0.2 + 5万) / (2 × 60 × 60) = 400/秒

容量评估按照5倍冗余计算，400/秒 * 5 = 2000/秒，需要3端口数据库服务写。

数据容量

当前有2亿会员，每天增长5万会员，平均每个会员有5个常用地址，30年会员常用地址表数量计算：

（2亿 + 5万 × 365 × 30年） × 5 = 35亿

设计结果：4端口 × 32库 × 4表， 4主8从

缓存资源预估

1400万 × 5 × 1k = 70G

设计结果：11台，主从

应用服务器资源评估

根据数据库的读QPS（5000/s）峰值和写TPS（2000/s）峰值计算，单台应用服务器即可，选择2台避免单点。

设计结果：2台

需求2： 物流订单和物流记录

• 订单提交后，通过消息队列产生物流订单，消息传入物流系统，物流系统消费物流订单消息然后入库。

• 后台任务轮循未完成物流订单，查询第三方物流接口状态，填写物流记录信息。按照每天1400万的订单，订单平均3天到货，第三方查询接口5000 QPS，

  每次状态查询需要时间计算如下：1400万 × 3 / 5000 = 8400 / 60 / 60 = 2小时，定时任务2小时查一次

• 提供REST服务获取物流订单信息。

• 提供REST服务获取物流记录信息。

• 提供REST服务获取物流订单和物流记录信息。

数据库资源评估

读QPS：

会员下单三天到货，三天内50%客户会查询一次物流订单和一次物流记录，计算如下：

(1400万 × 3 × 0.5) / (24 × 60 × 60) = 250/秒

容量评估按照5倍冗余计算，2 × 250/秒 × 5倍 = 2500/秒，需要3端口数据库服务读。

(1400万 × 0.5) / (2 × 60 × 60) = 1000/秒

按照每天1400万的订单，订单平均3天到货，每条物流订单产生8条物流记录，并且8条物流记录在三天内均匀产生，物流记录写TPS计算如下：

1400万 × 3 × 8 / 3 / （24 × 60 × 60） = 1200/秒

数据容量

当前2亿物流订单积累，每天增长400万订单，30年订单数量计算：

2亿 + 400万 × 365天 × 3年 = 46亿

设计结果：16端口 × 32库 × 8表，16主16从

消息队列资源评估

设计结果：1台Kafka，主从，1台处理机

应用服务器资源评估

设计结果：2台

方案2: 最小资源方案

因此，方案如下：

• 需求：会员常用地址

设计结果：1端口 × 32库 × 16表， 1主1从

• 需求：物流订单和物流记录

设计结果：1端口 × 128库 × 32表，1主1从

总结

• 当前线上流量并不大，使用最小资源方案节省成本。

• 最小资源方案充分的考虑了数据库的分库分表，当读QPS和写TPS突增时，DBA可以拆分库到不同的端口，也就是增加端口来应对。

• 最小资源方案在应用层设计了开关，如果性能突增可以临时申请和开启缓存和消息队列。

总结内容

欢迎分享转发，有帮助的话点个“在看”