作业

写出外包学生管理系统的架构文档

【作业要求】

1. 基于模块 1 第 5 课 P15 页的外包学生管理系统备选架构 1(见下 1 页)，写出完整的架构设计文档;

2. 注意不是备选架构文档，而是最终落地的详细架构设计文档;

3. 无需考虑数据库表设计，因为表设计是方案设计阶段做的，不是架构设计阶段做的;

前言

本文是为 XXX 学校构建的学生管理系统的详细架构设计文档，用于指导学生管理系统的开发、测试和运维。

词汇表

无。

1.业务背景

随着学校的规模的不断扩大，学生数量的增加，需要处理的信息也日趋增大。带来了如下几个问题：

• 花费大量的教师资源，处理效率十分低下，提高了学生管理的成本;

• 学生信息管理数据信息量大修改不方便，对一系列数据进行分析时花费时间长;

• 管理工作不够规范;

基于以上背景，迫切需要学生管理系统来提高学生管理水平，具体来说，要达到如下几个目的:

• 优化资源，尽可能降低管理成本;

• 方便学生信息管理信息的增删改查，提高数据分析的效率；

• 实现学生信息的系统化、规范化、自动化。

2.约束和限制

• 学校内网访问即可。

• 数据库采用 MySql。

3.总体架构

3.1 架构分析

3.1.1 高可用

由于学生人数众多，信息采集不变，如果这部分信息丢失，处理起来非常麻烦，所以数据的高可用是非常重要的。

对于某个子系统服务不可用的问题，考虑到学校日常管理的实际特点，可以有充分的时间进行问题排查、重启服务等，所以对子系统的可用性要求不高。

3.1.2 高性能

由于学校学生数量比较稳定，学校日常管理工作的计划性较强，不会出现突发流量，所以对性能要求一般。

3.1.3 可扩展

学校学生管理业务需求比较复杂，部门众多，所以对可扩展性有较高的要求。

3.1.4 安全性

由于涉及考试、奖惩等事关学生利益的事情，要求系统有较高的安全性。

3.2 总体架构

• 请求从 Nginx 接入，根据请求的 URL 路由到后端不同的子系统；

• 后端分为学生子系统、课程子系统和权限子系统三个独立的子系统，各系统可独立扩展

• 所有子系统共用一个数据库

• 数据库采用主备架构，保证数据的高可用

4. 详细设计

4.1 核心功能

4.1.1 登录过程

4.1.2 课程管理流程

4.2 关键设计

• 系统可扩展性

• 系统由三个独立的子系统构成，每个子系统向外提供若干接口，实现子系统之间的解耦，提升可扩展性。

• 系统高可用

• 数据库采用主备模式，保证学生管理信息数据的高可靠。两者之间采用同步方式复制数据，主备切换采用手动的方式进行，虽然较慢，但是学校对系统可用性的要求没有那么高，手动切换主备满足学校的使用场景。

• 认证、授权全部由权限子系统提供，学生子系统、课程子系统依赖权限子系统保证整个系统的安全性。

4.3 设计规范

• 前端采用 VUE 框架开发

• 前后端、各个子系统之间，使用 HTTP 方式进行通讯，报文使用 JSON 格式进行序列化

• 后端服务使用 Spring Boot 开发

5 质量设计

5.1 可测试性

不涉及。

5.2 可维护性

整个系统比较简单，系统内置 root 权限即管理(教务)权限，由教务自行分配各类角色。如果某个子系统或者数据库宕机，学校联系我公司，由我公司上门就行维护即可。同时，定期上门巡检。

5.3 可观测性

系统比较简单，依赖日志即可满足可观测性的需求。

5.4 成本

Nginx 以及三个子系统可以根据情况部署在不同的服务器上，或者部署在同一个服务器上，能很好的适配学校的预算要求。

6 演进规划

整个系统比较简单，一次性开发完成。同时系统设计上分为三个子系统，保证系统的可扩展性。后续需求汇总后，根据学校的要求则期开发。

笔记部分

架构师的工作

架构师职责

架构师的核心职责是消除不确定性和降低系统复杂性。

• 这两项的职责就是架构的本质即 4R 架构——Rank、Role、 Relation、 Rule 的体现。

• 消除不确定性

• 确定系统的逻辑组成即系统/后端架构

• 确定系统组件的选型及部署架构

• 降低系统复杂性

• 确定系统的应用架构，不同的应用交给不同的团队进行开发

• 确定系统的逻辑组成即系统/后端架构本身就是一个“分而治之”的过程，将复杂的大问题分解为相对容易的小问题，模块还可以在团队内进一步任务分解

架构师定位

业务与技术之间的桥梁，即业务与技术“两手抓，两手都要硬”。但也容易两头不讨好。

既懂技术，又懂业务，正好与目前所在团队的岗位职责重复，所以团队成员应该都应该把架构师作为职业目标之一。

架构师三个核心能力

• 判断

• 业务理解力：判断业务需求、业务场景

• 技术能力：将业务场景转化为技术语言，比如所谓的“手机盾”其实就是二次密码

• 沟通能力：有问题需要和业务方沟通，也需要和技术方沟通

• 拆解

• 技术深度，基础技术部门有更高的要求

• 技术宽度，业务部门的技术要求偏好。同领域多个技术的掌握程度。

• 技术广度，业务部门的技术要求偏好。跨领域的技术掌握程度。

• 取舍

• 设计理念，价值判断问题，不是事实问题，所以要取舍

• 决断能力，资源是有限的，必须有所取舍

• 说服能力，要和利益干系人一起前进

架构师三个关键思维

• 判断需要确定性思维。判断的前提是信息量够多、够准确，所以要把模糊的、不确定的说法转换为具体的、定量的信息，比如例如“大量用户”应该明确为“XX 万用户”。

• 拆解需要创造性思维。拆解就是把未知问题转换为已知问题的过程，很像数学，基础是原理、定理、遇到新的问题，要拆解、转化到已知的定理、原理上。换成通俗的说法，就是先不要着急创新，先学套路（即成熟的模式）、掌握套路，站在前人的肩膀上，通过创造性的排列组合，得到更多的方案。拆解的前提是理解业务、理解自己的系统，明确的规则组合后得到的结果往往是“出人意料”的；反过来，一些复杂问题的解决办法也是“出人意料”的可以分解为简单问题，“出人意料的程度就是创造性的程度”。

• 取舍需要系统性思维，从系统出发，进行逻辑和推导。架构师的任务就是构建一个系统、落地一个模式。

• (来自梁宁老师“得到”专栏《增长思维 30 讲》)

  任何一个系统都包括三个构成要件：目标、要素和连接。

  1. 目标和要素

  2. 目标不同，核心要素就会不同，采用不同的模式，得到的结果也不同。以星巴克和瑞幸咖啡举例如下，可以看出，合适的就是最好的，这也是架构三原则中的“合适原则”。

  • 星巴克

  • 目标，利用咖啡业务实现规模盈利

  • 模式核心要素：第三空间、外带、专业感知、标准化、品牌、网红。

  • 比如你进商场如果有个星巴克，离着很远，就能闻到浓烈的咖啡香。这是来自运营者的设计。为此星巴克砍掉了很赚钱的热食业务，就是为了不让任何其他气味干扰咖啡的香气。这就是取舍。

  • 瑞幸咖啡

  • 目标：速度，用资本杠杆撬动用户数，再获得资本杠杆，再进一步撬动用户数

  • 核心模式追求用户数而放弃品牌。这也是取舍。

  2. 连接

  3. 要素是系统的内部因素，如果要达到目标，还需要和外部交互，与外部产生连接。

  4. 因果链，少吃多运动，就能减肥。

  5. 增强回路，不断获得能量补充，让系统的动能越来越高：自律减肥瘦了，所以穿衣服好看，有人夸，更加自律减肥。从自律开始，转了一个圈，又回到自律，形成回路。

  6. 调节回路，和增强回路相反，让系统的动能不断的降低。懒是生物本能，减肥中一方面要克制天然贪欲，要少吃；另一方面，要运动，要拉高自己的能耗，所以减肥很痛苦。

  7. 滞后反馈。做完事后希望立即看到效果，错也好，对也好，最好能及时给个反馈，给个痛快，可是，反馈基本是滞后的。这样增强回路的形成需要时间。

  8. 取舍就是只做有利于增强回路形成的事情，撑住调节回路和滞后反馈。

架构设计 VS 方案设计

• 架构设计，影响系统结构的设计

• 方案设计，不影响系统结构的设计，比如数据库表结构的设计、接口的增删、类的合并等。

所谓影响系统结构，就是改变了 4R 架构中的某一项：

• Rank：改变系统分层的设计属于架构设计，例如将支付宝提升到和淘宝同级别

• Role：修改（增删改拆合）角色属于架构设计，例如微服务拆分

• Relation：修改角色关系属于架构设计，例如用消息队列代替接口访问。

• Rule：修改角色之间的运作规则，例如将 MongoDB 将选举算法从 Bully 改为 Raft。

问题一：将同步接口改为异步接口算是修改 Relation 么？

看影响范围（来自华仔老师）：

• 如果两个 role 之间的连接方式从同步改为异步，那就是改了 rule；

• 如果某 1 个接口从同步改为异步，只要不增加系统中新的 role，就不算改结构，如果为了实现同步改异步，要引入消息队列，那就是增加了 role

问题二：把营销子系统从硬编码改为规则引擎，属于架构设计还是方案设计?

属于架构设计。类似的，将系统中的 MySQL 替换成 postgresql，也属于架构设计。因为把某个角色的底层实现给替换了，相当于替换了系统中的一个零件；又比如将拖拉机换成皮卡也属于架构涉及。

架构设计的三个阶段

和架构师的定位紧密关联，架构师是业务和技术之间的桥梁，所以架构设计的三个阶段就是：和业务方沟通 -> 自己消化 -> 向技术输出明确方案 。

架构设计前期（开会）——明确问题

一句话总结：和相关人员开会

• 主要任务——对应架构师职责

• 澄清不确定性（个人理解：确定要干啥）

• 明确利益干系人的诉求（利益相关方想要干啥）

• 消除冲突的诉求（利益相关方想干的互相矛盾咋办）

• 诉求优先级排序（资源有限，时间有限，知道了要干啥，还要确定优先干啥）

• 识别复杂性

• 识别核心场景：先搞定主要矛盾的复杂性

• 明确或者预估质量需求：完善、提高架构质量

• 识别复杂度

• 工作模式：与业务方交流；与利益干系人交流

• 关键输出（得到整体和重点）

• 总体业务架构图：这个架构图是给领导汇报用的，得到整体面貌（整体）

• 核心场景流程（重点）

架构设计中期——明确方案

一句话总结：架构小组开会和写架构设计文档

• 主要任务

• 设计备选方案——扩散

• 头脑风暴

• 筛选方案

• 设计备选方案

• 选择备选方案——收敛

• 全面评估方案

• 明确评估标准

• 确定最终方案并汇报

• 工作模式（架构小组内）

• 讨论

• 写文档

• 汇报

• 关键输出——最终方案即主攻方向

• 备选方案

• 方案评估结论

• 方案汇报结论

架构设计后期——细化和完善

写文档和开会宣讲

• 主要任务

• 细化架构：遵从 4R 架构方法论

• 完善架构：确定质量属性，如可维护性、可测试性、可运维性、成本、安全。

• 工作模式

• 写最终架构设计文档

• 给技术团队宣讲方案（交接工作）

• 关键输出

• 完整的架构设计方案

架构验证阶段（贯穿项目全流程）

• 主要任务

• 收集架构意见

• 跟进架构落地效果

• 工作模式

• 总结复盘

• 收集吐槽

• 关键输出

• 架构优化建议

• 架构迭代计划

思考题

为何不能在架构设计阶段进行架构验证，而只能在项目流程中验证架构?

因为架构设计阶段的主要参与者是架构师，而架构设计的两个主要方面——复杂性处理和架构质量属性如可测试性、可维护性，需要开发人员、测试人员、运维人员一起参与进来才可以得出结论，这些人员是在项目流程的不同阶段参与进来的。

架构设计前期

这一段的主要目的就是工作就是澄清不确定性、识别复杂性，所以需要和利益干系人开会，收集他们的需求，并确定需求的优先级。

利益干系人分析框架

• 投资者（俗称“老板”）

• 内部：“我”的上级\业务负责人，利益诉求为（特别关注）成本，时间，竞争力

• 外部：2B 领域购买系统的金主、客户；利益诉求为价格、时间、竞争力

• 监管者：政府、媒体

• 构建者：指构建系统的人（开发团队、施工团队、生产商/供应商），在意技术、复杂度、时间

• 维护者：负责维护系统的人或系统，比如运维团队，在意的是可维护性和高可用

• 使用者：使用系统的人员或其它系统，在意易用性和高可用。这一点和产品经理有一的重复。

• 评估者：对系统进行评估的人员或其它系统，在意的是可观测性可测试性

可以看出，上述利益干系人的关注点就是架构设计中的如下特性

• 复杂性：可扩展（构建者）、高性能（投资者/构建者）、高可用（维护者、使用者）

• 成本（投资者）

• 质量属性：可观测性、可测试性（评估者）

诉求优先级排序

对不同的诉求按照一定的维度进行分组后进行排序，并就排序结果与相关干系人进行沟通。

分组维度

• 时间：项目周期、交付时间。

• 成本：人力成本、硬件成本。

• 范围：必做、可做、尽量做。

• 质量：可维护性/可测试性/性能/安全/可用性/可维护性……

这里的利益干系人诉求分组维度和架构设计中期的架构评估维度不同，这里分组的维度更加全面，包括技术面和业务面；而架构评估维度更加偏向技术面，是为了解决利益干系人的诉求对架构的各个方面就行评估的维度。这里是在明确问题的优先级，那里是在明确解决方案针对已经排好序的问题的优劣。

利益干系人诉求分组排序后，按照排序的优先级，去评估备选架构的优劣。

排序

排序主要处理差异性和冲突性诉求

• 差异性，指相同维度上、不同的需求，比如你的老板期望 5 个月交付，业务大老板期望 4 个月交付。

• 冲突性，指不同维度上相矛盾的需求，这是由资源的稀缺性决定的，比如减少项目时间要么缩减业务范围，要么降低系统质量，要么投入更多的人。

利益干系人诉求排序常见原则

• 取舍原则：排序时对于各种需求无法做到面面俱到，需要根据业务目标决定哪个目标优先（具有系统性思维），做出取舍。

• 影响力原则：按照影响力大小排序:监管者 > 投资者 > 评估者 > 使用者 > 构建者 > 维护者。

• 但也不一定严格按照这个顺讯，在“消息队列备选架构设计实战”中，投资者即老板的的诉求就排在最后一位。

利益干系人诉求排序沟通

• 对于差异性诉求，按照影响力沟通，谁权利大听谁的，采用点对点的形式沟通；

• 对于冲突性诉求（不可同时满足的），采取"PK+老板拍板"的解决方案，一般采取多方会议的形式

• 在 PK 的过程中，架构师要将业务、技术等方面的厉害给各方讲清楚，不可以坐山观虎斗。

架构设计中期

此阶段的任务是“明确方案”，设计方案时要落地“架构设计三原则”，选用最合适的，而选最牛的、最热的、最熟悉的都是不对的。

什么是备选架构

备选架构分为两个层次，架构模式和技术选型

• 架构模式，架构模式就像设计模式，是解决问题的逻辑套路，只有架构模式是不够的，它只是架构的整体样貌，还没有落地，个人理解是系统/后端架构。比如高性能、高可用、可扩展。

• 技术选型，决定架构里面具体是什么组件，个人理解对应部署架构，确定具体的组件 Component。比如确定存储是用 MySQL 还是 Redis；负载均衡是用 DNS 还是 Nginx；分布式决策是用 zookeeper 还是 Raft。

• 这里技术选型也确定了一个备选架构，正好对应“架构设计 VS 方案设计”小节中的问题 2.

备选架构设计过程

• 排列组合可选技术方案得到可能的方案，这是一个头脑风暴的过程。

• 对可能的方案进行筛选，这是一个初筛的过程，根据系统明确的约束和限定，一票否决某些方案。注意这里不是 N 选 1 的过程，而是一个 N 选 M 过程。

• 这里的红线来源于利益干系人。

• 4R 设计：确定 Role， Relation，基于核心场景来设计 Rule。

备选架构设计技巧

• 数量合适：3-5 个为最佳

• 少于 3 个说明技术宽度不够，考虑不够周全。由此看出，架构师除了模式，对底层组件也需要一定的了解。

• 多于 5 个时耗费的精力和时间过大，还会导致方案之间差异不够明显

• 差异比较明显

• 粒度要覆盖核心业务场景，但无需全面细化

• 会不会因为某个非核心场景导致架构重大变化?

  不会。因为非核心业务场景没有那么重要，不需要花精力设计；此外，非核心业务场景砍掉都可以。

常见困难

• 如果不知道哪些可用，则说明技术宽度不够，此时需要平时多积累

• 如果不知道能不能用，则说明学得太浅或者是只学细节（这是编码工作才需要的）。此时需要记住关键性能指标，对类似的组件使用比较学习法进行学习。

评估和选择备选方案

• 错误的方法

• 让领导选：领导可能并不是很懂，作为最懂此项业务和技术的人，正确的做法是选好后告诉领导为什么选。如果领导的方案和自己有差异，自己也有责任告诉方案的合理性和不合理性做在。如果领导坚持自己的方案，那就先用领导的方案。

• 综合打分：对多个维度进行打分，然后挑选最高的。这么做将所有维度一视同仁，没有分级，是不对的。

• 正确的做法：“360 度环评 + 优先级排序”，从多个维度评估备选方案，形成环评表格，然后按照排序后的利益干系人诉求对各个方案进行评估，首先使用高优先级的利益干系人诉求评估备选方案的各个维度，筛选掉不合适的，对于剩下的方案，再使用下一级优先级的利益干系人诉求进行下一轮的评估，直到得出最终的架构方案。

常见架构评估维度和注意事项

• 性能

• 可用性

• 可扩展

• 成本

• 安全

• 技术复杂度

• 团队技术储备

这里的架构评估维度和架构设计前期的利益干系人诉求分组维度不同，那里分组的维度更加全面，包括技术面和业务面；而架构评估维度更加偏向技术面，是为了解决利益干系人的诉求对架构的各个方面就行评估的维度。那里是在明确问题的优先级，这里是在明确解决方案针对已经排好序的问题的优劣。

利益干系人诉求分组排序后，按照排序的优先级，去评估备选架构的优劣。

思考题

做备选方案需要花费多一些时间，这样会不会导致效率很低?

首先，因为架构有不同的 Rank，所以要在不同的 Rank 上去思考。

• 对于高层次的架构来说，做备选方案不会导致效率降低。

• 高层次的架构设计要面对更多的不确定性、更高的复杂性，有更多的利益干系人。针对某个具体的场景，总要对性能、可用性、可扩展性、成本、安全等架构评估维度做出评估，不是这个阶段做，就是下个阶段做，是省不了的。

• 此外，做备选方案也是一个全面思考的过程，可以促使架构师全面分析问题。

• 最后，备选架构是给老板看的，给老板一个选择题，而不是只能这么做，也是有好处的。

• 对于低层次的架构设计而言，由于问题比较简单，目标比较明确，所以此时不做备选方案也是可以的。

架构设计后期

主要是做详细架构设计。

区分三个概念

• 备选架构：拆解系统，得到 4R，也就是备选架构的两个方面——架构模式和技术选型，只有拆解后才会得到这两个东西：模式即系统的分解方法以及各个部分之间的交互方式；技术选型是对系统组件的选择，而组件是组成系统的要素。备选架构由备选架构设计文档承载，给老板/利益干系人看的。

• 详细架构：详细架构是对选中的备选架构的细化（明确 4R）和优化（提升系统的质量属性，比如可观测性、可测试性）。详细架构由详细架构设计文档承载，下一级架构师/开发团队是器受众。

• 上面都是由架构师进行的工作。PPT 架构师主要就是负责备选架构的设计，对详细架构设计不怎么关注；这并不代表他们完全不同技术和业务。

• 方案设计，不是由架构师进行的，是由设计师进行的，可能就是有开发同学确定的，目标是基于架构实现需求，由项目的方案设计文档承载，给开发团队看。

详细架构内容

• 架构规范（提升架构落地效率），主要关系到 Role 和 Relation 的具体设计

• 交互/通讯协议（比如 HTTP 还是 TCP）

• 数据格式/数据序列化方法（比如是 XML 还是 JSON）

• 开发框架的选择

• 架构质量（提升架构落地质量）

• 可测试性设计

• 可观测性设计

• 可维护性设计

• 其余质量设计

在详细架构涉阶段加入架构质量的设计，也符合之前说的，先考虑系统的复杂性，然后考虑在考虑系统的质量属性是相符的。

上面的内容在开发过程中也可以调整，这样不会影响总体架构。因为上面的两部分的作用是提升架构落地效率和提升架构落地质量，它们的调整是不会影响总体架构的。

架构设计文档内容

• 第一部分

• 业务背景，交代解决什么问题，带来什么价值。

• 相关技巧：使用系统边界黑盒图描述系统定位（Rank 和业务背景）

• 系统边界黑盒图：把系统当成黑盒，描述系统与同级别其它系统交互和关联关系（本系统和外部系统的 Role 和 Relation）。

  
  

• 约束 & 限制，描述明确的、无需进行设计的相关条件。这些内容来自架构设计前期对利益干系人的诉求进行分组时的维度。

• 第二部分

• 总体架构设计：Rank，Role， Relation（这三部分直接来源于备选架构设计文档）

• 用系统边界白盒图来展示 Rank（外部结构）。系统边界白盒图，即把系统当成白盒，描述系统内部的 Role 与同级别其它系统的交互和关联关系。

  
  

  用系统架构图来展示 Role 和 Relation（内部结构）

• 详细架构设计：Rule、架构规范

• 用系统序列图来展示

• 第三部分

• 架构质量设计：可测试性、可维护性、安全等

• 可能会增加 Role，例如管理后台。但这里增加的 Role 并不会影响系统结构，因为这种 Role 不是为了解决系统的复杂性。

• 架构演进规则：第一期，第二期……

思考题

PPT 架构师也完成了复杂度分析和备选架构设计，为何经常会被人吐槽？

PPT 架构师不是完全不懂技术和业务，之所以被人吐槽是因为 PPT 架构师没有做详细架构设计，没有指定架构规范，这样实施团队做起来，效率不高，所以被人吐槽。

消息队列备选架构设计实战

1、架构设计前期，针对业务背景以及要解决的问题，收集了各个利益干系人的诉求，并对其进行排序，明确了哪些问题是需要优先解决的，最后针对当前问题，分析其复杂度。

2、架构设计中期——选择备选方案。

思考题

为什么我们做架构设计的时候，有时候需要“重复造轮子”?

• 首先，如果是备选架构设计阶段，此时是一个“头脑风暴”的阶段，需要尝试尽可能多的方案，不应该限制自己；

• 其次，架构设计的三原则是合适、简单和演进，而不是“是否是重复的轮子”，只要论证后，是最合适的方案，就可以造轮子。

消息队列备选架构选择和细化实战

基于以下维度对备选架构做了评估

• 性能

• 复杂度（团队技术实力）

• 硬件成本

• 人力成本

• 可维护性

• 可用性

• 业务契合度

• 团队声誉

思考题

如果你现在的团队做消息队列架构选型，你觉得会优选哪个方案，理由是什么?

我会选择开源方案，因为此时我们的利益诉求排序为

• 复杂度（团队技术实力）

• 人力成本

• 性能

按照上述诉求排序，最优方案就是“引入 Kafka”。