首页手记系统设计的三板斧

系统设计的三板斧

标签：

架构设计模式

【一凡sir，原创文章，禁止转载】

背景

对于技术来说，每一个系统都少不了最重要的一个环节，系统设计。
系统设计的成功与否直接决定了后续的系统开发能否成功。
这次的分享，我们将系统设计的方法简化为三板斧，简单易懂，居家旅行学习进修必备。
三包承诺：包记住，包理解，包会用。如有问题，请再看一遍。如想快速浏览，可以先看总论

大纲

1 系统设计的基本流程
2 三板斧的招式
3 实例讲解，权限系统设计
4 总结

什么是系统设计

The process of defining the 　　　　　　　　　　定义（产出）
architecture, 　　　　　　　　　　　　　　　　　架构
components, 　　　　　　　　　　　　　　　　　组件
modules, 　　　　　　　　　　　　　　　　　　　模块
interfaces, 　　　　　　　　　　　　　　　　　　接口
and data 　　　　　　　　　　　　　　　　　　　数据
for a system to satisfy specified requirements. 　　需求（目标）

1 系统设计的基本流程

1.1 软件开发流程

1 需求分析
2 概要设计
3 详细设计
4 系统开发
5 系统测试
6 软件交付
软件开发流程，详细内容可以参考： https://baike.baidu.com/item/软件开发流程
需求分析就是一个很专业的工作，对于大型的软件开发，也有专门的需求分析师，所以这里面的方法和流程也还有很多细分的内容，有兴趣的同学可以继续挖掘。
系统设计主要就是2、3两部分，大学毕业设计的时候，应该也都有深刻的印象，自己的文档是怎么写出来，怎么组织和编排的吧。

1.2 系统设计的流程

系统设计的内容可以用16或者32课时来专门开一课，大学时候应该也有这样的课，可能是选修吧。
详细内容可以参考：从 0 到 1 教你设计业务系统 https://36kr.com/p/5105245

1.3 总结，系统设计的基本流程

上面的软件开发流程和系统设计流程，看着就很复杂，分工很细，要完全遵守这些方法来做互联网产品开发的话，很多人是无法想象的，2周上线，1天1个版本？
所以，上面的流程都是来自传统的企业软件开发方法。而传统软件的开发周期，最少也是半年、一年的周期，交付物也都会比较严格，也不会有持续迭代一说。
传统企业软件开发，有很多是外包公司，规模很大，类似富士康的工厂。而规模的基础就需要标准化，遵守各种认证体系的要求，这样也更能被企业认可和信任。
但是，这些流程、方法，对于我们互联网研发就很不合适，系统设计也是。所以，才有了本文的核心方法。

2 三板斧的招式

2.1 第一招：抽象，万物归一

1 人，主体对象
实体模型，数据结构
2 事，核心功能
组件模块，功能需求
3 物，资源要求
系统规模，开发周期，架构设计

宏观上的面，提炼和定义，不拘泥细节。
从繁杂的系统中剥离、提炼，抽象出来我们系统的核心，定义好系统的人、事、物，也就有了系统的大致样貌。
抽象，这是最重要的一步，也是最厉害的一招。

2.2 第二招：具象，有血有肉

1 数据结构设计
对象的属性，数据表
2 业务功能设计
功能模块，任务清单
3 系统架构设计
性能、并发、伸缩、扩展、安全

微观实现的点，为后续的编码扫平模糊。
系统设计在这一招完成后，基本上就要全面完工了，交付给开发来编码。如果这时候还有不清晰的地方，还有遗留的点，那么后续就会出现很严重的需求变更、技术变更、甚至重构，会严重影响项目开发的周期和质量。
具象，这是需要细致且耐心的一步，也是势大力沉的一招。

2.3 第三招：演算，活灵活现

1 业务流程
让功能细节发生互动（业务恋爱）
2 数据流程
让对象之间发生关系（数据怀孕）
3 模拟操作与系统预估
模拟的运转和系统压力评估（成长烦恼）

流程不通，操作不顺，系统瓶颈，及早发现和补充完善。
纯脑力运算的过程，可能是设计者来做，也可能是要系统相关人一起来做。
这里用时2小时或者一起开个会，把系统设计的方方面面都模拟的运转起来，各个环节，各个角色带入进来，发现问题马上调整前面的抽象和具象的设计。
演算是一个快速查缺补漏的环节，也是对系统设计进行方案优化、调整的最后环节，这里投入的每一分钟都是十倍百倍于后续研发阶段的调整时间效率。
演算，这是最容易忽略的一步，也是最难的一招。

2.4 总结，系统设计的三板斧

围绕系统设计中的人、事、物，我们通过宏观层面的抽象，提炼和定义出来核心内容，在通过微观层面的具象，把各个细节补充完善，最后，运用演算，让这个系统在我们的脑子里面活起来，重复这三板斧，完善我们的系统设计。

3 实例讲解，权限系统设计

介绍：权限系统管理着应用和服务之间的调用关系。应用要调用服务的接口，必须先申请对应的服务接口权限才可以。

3.1.1 抽象：权限系统的核心对象（主体）

1 主要对象
应用，服务
2 派生对象
接口，应用请求服务
权限，接口权限
3 外部对象
网关，系统平台，第三方服务等
提炼权限系统内部的主体对象，确定系统的数据模型。

3.1.2 抽象：权限系统的核心功能（硬性）

1 权限相关功能
应用端申请，服务端审批，查询
2 后台管理功能
服务信息和扩展权限的配置
3 扩展功能
消息通知，权限推送
定义必须的应用的全后端功能，扩展的与外部系统的交互功能。

3.1.3 抽象：权限系统的资源要求（软性）

1 权限的管理系统，不涉及权限验证
系统并发量很有限，性能要求低
2 平台内应用、服务的权限依赖度高
系统的安全和稳定性高
3 内部和外部服务的权限定义差别大
扩展性要求高
系统的架构设计不必过于复杂，保证应用程序的安全和稳定性，定义好系统的可扩展性。

3.2.1 具象：权限系统的数据结构

1 申请记录表 tb_privilege
应用相关
服务相关
接口相关
申请相关
审批相关
标准字段
2 服务配置表 tb_paas
服务信息
推送相关
外部相关
扩展相关
标准字段
3 操作日志表 tb_log
数据模型
新旧数据
标准字段

3.2.2 具象：权限系统的业务功能

细化每一个功能的处理过程，要结合交互页面，操作流程，数据输入和产出等。

3.2.3 具象：权限系统的系统架构

1 分层模型，前后端分离
前端展现和交互，后端数据和逻辑，前后端耦合度低
2 服务的权限订阅和推送，预留第三方服务和扩展权限
定制化多端推送，扩展能力强
3 多机分布式，定时任务更新权限和通知
资源伸缩性强
**架构演化：**单机 -> 分布式，单库 -> 主从库 -> 缓存层 -> 数据分拆（水平、垂直） -> 应用分拆（微服务）
架构选择，只有合适与否，没有好坏之分。

3.3 演算：数据流程、业务流程和交互模拟

1 权限申请流程
方便查找服务，方便申请接口权限

2 权限审批流程
方便查找服务，方便申请接口权限

3 接口权限申请的状态变更
申请、审批和推送、通知，把开发者、服务方、网关、服务都串联起来
流程，让整个系统运转起来，是一个活的系统，不再是冷冰冰的数据结构和系统框架。
考虑开发者和服务方的用户，带入用户的立场和操作，更好地模拟整个系统的交互体验。

3.4 总结，实例讲解，权限系统设计

这里的实例比较简单，但毕竟是最近设计开发的一个系统。
而对于更加复杂的系统，方法还是互通的。
定义好，写下来，画下来，这就是一个系统设计和项目文档。
当然系统设计不仅仅是上面呈现出来的内容，还有关于接口，任务清单等内容。

4 总结，系统设计的三板斧

一句话形容，从宏观到微观，互动更长久。
抽象，先从宏观层面做好抽象；
具象，再从微观层面补充完善细节；
演算，全流程的模拟，查缺补漏；
重复上述三板斧，不断完善系统设计。
注意：不用纠结未知和差异化太大的部分。
系统设计的三板斧，相信不仅仅可以用在系统设计中，在其他的很多方面应该也是类似，比如：写作。
主题 -> 目标
创意 -> 抽象（人、事、物）
细节 -> 具象（有血有肉）
故事 -> 演算（活灵活现）