系统设计

背景

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

大纲

• 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 总结，系统设计的三板斧

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