系统设计的三板斧——抽象、具象和演算

背景

对于技术来说，每一个系统都少不了最重要的一个环节，系统设计。

系统设计的成功与否直接决定了后续的系统开发能否成功。

这次的分享，我们将系统设计的方法简化为三板斧，简单易懂，居家旅行学习进修必备。

三包承诺：包记住，包理解，包会用。如有问题，请再看一遍。如想快速浏览，可以先看总结。

大纲

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/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E6%B5%81%E7%A8%8B

需求分析就是一个很专业的工作，对于大型的软件开发，也有专门的需求分析师，所以这里面的方法和流程也还有很多细分的内容，有兴趣的同学可以继续挖掘。

系统设计主要就是2、3两部分，大学毕业设计的时候，应该也都有深刻的印象，自己的文档是怎么写出来，怎么组织和编排的吧。

1.2 系统设计的流程

系统设计的内容可以用16或者32课时来专门开一课，大学时候应该也有这样的课，可能是选修吧。

详细内容可以参考： 从 0 到 1 教你设计业务系统 https://36kr.com/p/1722044334081

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 具象：权限系统的数据结构

应用相关

服务相关

接口相关

申请相关

审批相关

标准字段

2 服务配置表 tb_paas

服务信息

推送相关

外部相关

扩展相关

标准字段

3 操作日志表 tb_log

数据模型

新旧数据

标准字段

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

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

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

1 分层模型，前后端分离

前端展现和交互，后端数据和逻辑，前后端耦合度低

2 服务的权限订阅和推送，预留第三方服务和扩展权限

定制化多端推送，扩展能力强

3 多机分布式，定时任务更新权限和通知

资源伸缩性强

**架构演化：**单机 -> 分布式，单库 -> 主从库 -> 缓存层 -> 数据分拆（水平、垂直） -> 应用分拆（微服务）

架构选择，只有合适与否，没有好坏之分。

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

1 权限申请流程

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

2 权限审批流程

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

3 接口权限申请的状态变更

申请、审批和推送、通知，把开发者、服务方、网关、服务都串联起来

流程，让整个系统运转起来，是一个活的系统，不再是冷冰冰的数据结构和系统框架。

考虑开发者和服务方的用户，带入用户的立场和操作，更好地模拟整个系统的交互体验。

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

这里的实例比较简单，但毕竟是最近设计开发的一个系统。

而对于更加复杂的系统，方法还是互通的。

定义好，写下来，画下来，这就是一个系统设计和项目文档。

当然系统设计不仅仅是上面呈现出来的内容，还有关于接口，任务清单等内容。

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

一句话形容，从宏观到微观，互动更长久。

抽象，先从宏观层面做好抽象；

具象，再从微观层面补充完善细节；

演算，全流程的模拟，查缺补漏；

重复上述三板斧，不断完善系统设计。

注意：不用纠结未知和差异化太大的部分。

系统设计的三板斧，相信不仅仅可以用在系统设计中，在其他的很多方面应该也是类似，比如：写作。

主题 -> 目标

创意 -> 抽象（人、事、物）

细节 -> 具象（有血有肉）

故事 -> 演算（活灵活现）

在最后，强调一遍，抽象和推理是数学的重要能力，数学绝对是极其重要的学科，掌握好数学，能够更好地掌握科学方法，而不仅仅只有个人的经验和直觉。