导读：本次作业提交分为两部分：作业和笔记

作业

一、画出微信的业务架构图

网上流传的文章都说微信遵从极简的设计，对功能的增加是非常克制的，所以上述业务架构图以消息系统为核心，把朋友圈也列为消息系统的一部分，完全可以作为一种特殊的消息来实现；作为设计产品，用户系统列为第二重要的系统。

不记得在哪看过的文章，把微信看做如下两种产品的升级：

• 微信是另外一种形式的邮件系统；

• 微信的本质是一个电话本；

正当觉得这个设计还挺有点聪明的味道时，看到群里华仔的两个观点，顿时觉得这个业务架构图没有这么好了（如果有时间就重画吧）：

场景是系统对用户提供的有价值的服务，功能是系统为了实现服务而提供的能力，比如：

• 取款是场景，密码验证，出钞票是功能；

• 付款是场景，输入付款密码，用余额付款是功能；

按场景划分业务，而不是按照功能点划分业务，“阿里支付香港”架构图中，余额之所以放在用户管理的分组里，而不是放在钱包业务分组？放在用户管理里面是因为用户要充值余额，余额提现。

二、“学生管理系统”毕设架构设计

假设今年学校毕业设计要求提升，要求做真正可运行的学生管理系统，学院对毕设的具体要求如下:

1 要求可以通过公网域名访问;

2 要求至少 3 人合作完成;

3 能够支撑管理 1000 个学生;

4 答辩的时候会根据架构方案来进行打分，不推荐太简单和太复杂的方案。

你找了 2 个好朋友一起来做这个项目，你们的基本情况如下:

1 大家都会 Java，但是有一个是 PHP 高手;

2 大家经济条件一般。

作业要求:

1 对照面向复杂度架构设计方法论，构思 2 个以上的备选架构方案。

2 使用 PPT 来画出你的备选架构方案，并说明方案的优缺点。3 给出你选择的最终方案以及选择理由。

使用由本笔记”学生管理云平台实战——学生管理平台的“灵魂”重塑之旅 > 方案取舍“部分根据华仔提出的”面向复杂性“的架构方法论总结出的套路进行分析。

1、判断复杂度

• 复杂度判断“必选动作”

• 高性能：能够支撑管理 1000 个学生，这个性能要求不高，谈不上什么高性能。

• 高可用：只是一个毕业设计，而非真正投产的系统，加上“大家经济条件一般”，所以可以不做高可用设计；不过当做练习的话，可以只是设计一下，不做实现

• 可扩展：设计的目的是为了毕业，可以不做可扩展性的考虑，待日后有需要时，再做考虑。

• 复杂度判断“可选动作”

• 成本：“大家经济条件一般”，部署架构越简单越好。

• 安全：实现必要的、常见的安全防护措施，比如防 SQL 注入、防 XSS 攻击等即可，当做一次实践的机会。

2、拆解

参见本笔记“外包学生管理系统实战 > 拆解”部分写下的思考进行。将思考内容引在下方。

拆解是架构师对负载度的应答。按照架构图的种类，拆解总体上就是两个类型

• 逻辑拆解，目的，一是分离关注点，分解复杂性；二是便于分工协作；

• 物理拆解，目的是便于部署。部署主要是针对服务或者进程的。

• 逻辑拆机和物理拆解是有关系的，它们之间存在某种比例关系。参见下文。

突然有一个想法，系统可以按照“逻辑”上的模块和“物理”上的节点是否重合，分为两类

• 逻辑节点和物理节点一一对应，这个就是垂直拆分，也即按照问题域进行的拆分，也可以叫按照业务的拆分，再进一步的发展就是微服务。逻辑拆分的目的是职责分离，分离关注点，便于协作，同时对应于物理节点，所以涉及到了部署。这种情况更需要 DevOps。由于逻辑节点和物理节点归一了，而物理节点对应资源，此时可以方便的做到节点之间的隔离；同时，逻辑节点位于不同的物理节点上，开发、部署时可以更加自由的独立变化。

• 物理节点可以是虚拟机，也可以基于容器技术。

• 逻辑节点和物理节点的比例是 N:1，这个是水平拆分，每个几点更接近于于单体架构，可以做集群部署。

其实大多数的时候，都有水平拆分，即分层的架构。垂直拆分，每个问题域也都会是分层的。可以立即水平拆分是比较低层级的结构，垂直拆分是比较高层级的结构。参见 AKF 立方体。

逻辑拆解

认为需求和课程中的学生管理系统的相同，所以逻辑上拆分为相同的部分：学生子系统、课程子系统、权限子系统。

物理拆解

因为经济条件都一般，所以尽量减少物理拆解，即减少服务器的数量。

方案一

方案描述：

• 前后端一体架构；尽量减少成本，将前后端部署在同一台机器上，后端采取单体架构，因为不需很高的高可用要求，数据量也不大，所以不使用数据库，数据直接存放在内存中或自定义格式的本地文件中。

• 优点：成本低，满足性能要求，可实际运行

方案二

方案描述：

• 采用前后端分离的架构，前端为 H5 WEB 应用

• 每个子系统分别开发、部署，为前端提供接口服务

• 数据保存在数据库中

• 所有服务部署在同一台机器上

方案三

方案描述：

• 采用前后端分离的架构，前端使用 PHP 实现

• 每个子系统分别开发、部署，为前端提供接口服务，使用 JAVA 开发

• 数据保存在数据库中

• 所有服务部署在同一台机器上

方案取舍

• 取舍时使用的武器——“架构设计三原则”

• 合适原则

• 简单原则

• 演化原则

• 取舍时砍向的“敌人”或出发点——即常见判断维度

• 业务

• 团队

• 技术

• 成本

• 开发周期

• 对方的认可度

• ……

所以，方案的取舍过程就是“武器”和“敌人”这两个维度的排列组合——可以看做是一个二维的表格。

按照上面的方法，最终选择方案三，理由如下。

• “合适”原则

• “合适”原则就是“适合”了某个东西

• “适合”团队技术水平：团队内有 PHP 高手，使用 PHP 开发页面速度更快。大家又都会 JAVA，将三个子系统独立，大家可以分头开发，都可以练练手，还可以提高接口开发、调用的能力。

• “适合”的开发成本，所有服务部署在同一台机器上，降低了大家的负担

• "适合"的场景：开发系统主要是为了毕业设计，不需要高可用以及很高的性能，部署在同一台机器上运行起来也没有问题。即可以综合运用大学学习到的知识，又不至于太复杂，有利于答辩得到较高的分数。

• 简单原则

• 虽然进行了服务的拆分，但是因为不涉及到运维问题，所以部署稍微复杂一点是可以接受的。学生有很多时间。

• 每个系统分头开发，降低了内部复杂性。

• 演化原则

• 业务场景固定，无需太多考虑后期演化

笔记部分

笔记只记录上课时让自己触景生情或者引发了额外思考的内容。

此外笔记部分还有课后的思考题。不过思考题已经于今日（20210706）给出了参考答案，所以这里的笔记只当做是自己的思维练习。

什么是架构

模块与组件

都是对系统的拆分，只是拆分的视角不同

• 模块是从逻辑上对系统进行拆分，每个模块集中在某种“职责”上，便于职责分离

• 模块更常出现在后端逻辑架构即系统架构中。

• 组件是从物理上对系统进行拆分，重点在于复用。可以用“零件”来进行类比。

• 组件的例子有 Nginx、Web 服务器或 MySQL 等，所以组件更常出现在部署架构中。

框架和架构

• 架构更常用来描述系统

• 框架用于搭建系统，比如 Spring。当然，Spring framewo 也是一个 DI 系统，也有自己的架构，比如应用上下文由 Bean Factory 和 Environment 等组件组成，也体现了结构、角色、关系等架构的内容。

4R 架构

• Rank：架构是分层的，某个架构只关注和描述其关联系统的最顶层、最抽象的部分。他的每个部分（模块或组件）可以细分，但细分的结果及描述又下一层的架构图来描述。这里体现了递归的概念。

• 架构是分层的，这里的分层是抽象程度的不同；某个抽象级别可以由某种形式的架构来描述。

• 架构描述的是系统，系统可以拆分成模块（逻辑拆分）和组件（物理拆分）。其中模块集中在某种职责上，如果这些模块是水平的，则可以画出分层的架构。

• “分层架构”就是指分层的架构，每层的关注点不一样，也即职责不一样，比如展现层、业务层、持久化层。从这一点上说，MVC 就可以理解为分层的架构。

• Role：组成角色，指系统包含哪些角色。

• Relation：角色之间的关系，由架构图中各个部分之间的连线体现

• Rule：运作规则，角色如何写作完成系统功能

4R 架构的应用

• 架构师职责及架构文档内容

• 确定层级

• 将系统拆解成角色。对应日常工作中设计系统模块。

• 定义角色之间的关系。对应日常工作中确定模块的分工与依赖关系。

• 涉及角色互动的规则。对应平常工作设计方案时，画某个业务场景的时序图。

思考题 1

对比 4R 架构定义和维基百科架构的定义，主要差别是什么？

• 维基百科架构定义

指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。

• 4R 架构更加明确体现了系统的特点;

• 4R 架构更加明确了“基础结构”，角色即基础结构；

• 更加具体的用 Relation 和 Rule 对基础结构及 Role 进行描述。

如何画出优秀的架构图

架构图可以分成很多种，大体多行可以分成给一般人看的和给码农看的。

同时，系统是由模块（逻辑角度）和组件（物理角度）组成的，所以架构图不论是什么种类的，都离不开这些东西。

• 给一般人看的（都是按模块划分的，一般人不管啥是 WEB 服务器）

• 按业务划分——业务架构：用户看到的系统提供的功能。适合给领导汇报工作，省的细节太多，领导问个没完，反而问出问题。

• 客户端——客户端架构

• 前端——前端架构

• 客户端架构和前端架构没有应用架构和部署架构，因为它们描述的只是一个应用（不能即是支付宝的前端，又是微信的前端），必须部署在某个终端上。但是支付宝和微信客户端有很多功能一样的“部分”，比如文本框啥的，这些都可以解耦为“插件”和“前端组件”，可以做到复用。

• 给码农看的

给码农看的，当然要按照模块和组件充分的划分一下。

• 系统/后端架构（按模块划分）：后端的逻辑架构，又叫后端架构、技术架构。因为后端和前端不同，往往有很多 Role，Role 之间又有 Relation 和 Rule，所以后端架构直接叫系统架构。

• 应用架构（按应用划分）：模块总要在机器上跑起来（部署），模块也总是要交给码农去开发（项目开发、测试），这就是应用架构。当一个模块只由一个应用组成时，应用架构和系统架构就是同一个了。这个往往在中间件上有体现，比如 MongoDB 的系统架构和它的应用架构就是一样的。

分布式系统总会涉及到一大堆独立的通过网络连接的进程，每个独立的进程可以看做一个应用。

• 部署架构，描述后端系统具体如何部署的，是一种物理视图，图中都是组件，比如 Nginx。

• 系统序列图（System Sequence Diagram）

是一种动态架构图，主要描述"4R"中的 Rule，即运作规则。系统序列图用 UML 序列图来画，核心功能需要画序列图。

思考题 2

为什么不能用一种图来展现软件系统的架构？

因为一个系统的诞生是由很多不同角色的人，经历过很多步骤后才产生的，每个阶段、每种人都需要对系统有认知，所以需要不同的架构图。

架构方法论

DDD

在中国不是很火。华仔的理解如下：

1. DDD 是可扩展架构的设计技巧，不是架构方法论。

2. DDD 兼顾架构设计和方案设计，大部分人会搞混。

3. DDD、敏捷架构不关注存储和计算，只关注业务。

架构方法论是关于如何“降低软件系统的复杂度”的套路和模式。

DDD 把问题分为不同的领域，不同的领域又可以不断划分为子域，以此来降低问题的复杂度，不断集中关注点。从这一点上来说，它是一个架构方法论。任杰老师在他的《分布式金融架构课》中认为，只有足够复杂的、运行足够长的系统才值得用复杂的方法去设计，比如 DDD，才能取得投入产出的平衡。

面向复杂度的架构方法论

软件系统的复杂度来源于如下方面，所以判断复杂度的时候也从下面的角度出发

• 高性能

• 高可用

• 可扩展

• 安全

• 成本

• ...

面向复杂度的架构设计方法论就是关于如何降低复杂度，大办法就是拆解，拆解分为两大类，逻辑拆解和物理拆解，这一点正好和架构图的种类是对应的

• 逻辑拆解，目的，一是分离关注点，分解复杂性；二是便于分工协作；

• 物理拆解，目的是便于部署。部署主要是针对服务或者进程的。

• 逻辑拆机和物理拆解是有关系的，它们之间存在某种比例关系。参见下文。

详见本笔记“外包学生管理系统实战——拆解”小节。

一句话总结，架构设计的目的就是好开发，已部署，还能不断演进。

思考题

为什么软件架构最先是在 Rational 和 Microsoft 这类大公司兴起的？

因为软件架构方法论主要是应对软件系统的复杂性，而大公司往往会面临复杂软件的开发任务。

如何做好架构设计？

架构设计三原则

• 合适原则

• 首先是适合某个场景，“场”是指空间，“景”指时间。架构原则设计出的系统就是某个产品，有了场景，产品才有意义。

• 匹配当前已有的资源：团队、基础设施

• 在合适的时间长度内解决问题

• 符合业务发展的阶段

• 合适的成本

• 开发成本

• 运维成本

• 简单原则

• 奥卡姆剃刀：若无必要，勿增实体。

• 复杂度

• 内部复杂度。是指某个系统中某个模块或组件非常复杂。

• 外部复杂度。是指系统中模块和组件的连接关系非常复杂。外部复杂度越高，最直接的会使得部署维护变得复杂：想想单体和分布式系统的部署过程吧，想想分布式系统的网络开通和系统防火墙的设置是多么的麻烦。

• 简单带来的好处

• 越简单越可靠

• 越简单越容易扩展

• 越简单故障越容易处理

• 演化原则

• 既然场景是安放系统灵活的所在，场景是一直变动的，所以系统也需要不断烟花，架构设计自然要符合这个特点。

架构设计原则常见判断维度

• 业务

• 当前业务的量级

• 业务发展速度

• 业务发展形态

• 团队

• 团队规模

• 团队能力水平

• 投入的资源

• 技术

• 已有技术体系

• 当前技术能力

• 技术成熟度

• 成本

• 开发周期

• 对方的认可度

思考题

对于 2B 的系统，都是按照合同一次性交付，那么架构设计还会遵循“演进原则”么？

仍然应该遵循“演进原则”。

• 虽然是 2B 的系统，我们仍然应该引导客户的需求，或者为其设计合理的实现步骤，分多期实现

• 其次客户的需求是变化的，要随时做好演进的准备

• 交付时间是固定的，团队的情况是客观存在的，为了满足客户需求，就要采用最合适的技术，在合理的时间段内完成交付，肯定又不是最优的部分，这些部分可以留给后续改进。

外包学生管理系统实战

判断复杂度

面向复杂度的架构设计，第一步当然是判断复杂度

• 复杂度判断“必选动作”

• 高性能

• 高可用

• 可扩展

• 复杂度判断“可选动作”

• 成本

• 安全

拆解

拆解是架构师对负载度的应答。按照架构图的种类，拆解总体上就是两个类型

• 逻辑拆解，目的，一是分离关注点，分解复杂性；二是便于分工协作；

• 物理拆解，目的是便于部署。部署主要是针对服务或者进程的。

• 逻辑拆机和物理拆解是有关系的，它们之间存在某种比例关系。参见下文。

• 备选架构一是不同的“业务模块”或者“领域”分布在不同的服务器节点上，即不同的服务器节点是“异构”的

• 备选架构二是所有的“业务模块”都住在同一个服务器节点上，但是服务器节点数量是可以变化的，这是所有的节点都是“同构”的

突然有一个想法，系统可以按照“逻辑”上的模块和“物理”上的节点是否重合，分为两类

• 逻辑节点和物理节点一一对应，这个就是垂直拆分，也即按照问题域进行的拆分，也可以叫按照业务的拆分，再进一步的发展就是微服务。逻辑拆分的目的是职责分离，分离关注点，便于协作，同时对应于物理节点，所以涉及到了部署。这种情况更需要 DevOps。由于逻辑节点和物理节点归一了，而物理节点对应资源，此时可以方便的做到节点之间的隔离；同时，逻辑节点位于不同的物理节点上，开发、部署时可以更加自由的独立变化。

• 物理节点可以是虚拟机，也可以基于容器技术。

• 逻辑节点和物理节点的比例是 N:1，这个是水平拆分，每个几点更接近于于单体架构，可以做集群部署。

其实大多数的时候，都有水平拆分，即分层的架构。垂直拆分，每个问题域也都会是分层的。可以立即水平拆分是比较低层级的结构，垂直拆分是比较高层级的结构。参见 AKF 立方体。

今天正好也看了杨波老师的《Spring Boot 与 Kubernetes 云原生微服务实战》课，物理拆分和逻辑拆分的区别与联系也体现在工程代码的组织上。进行服务化拆分后，每个服务可以是独享一个仓库（多仓库，Multi-Repos），也可以共享一个仓库（单体仓库，Mono-Repo）

• 多仓库

• 优点：每个仓库职责单一，代码量和复杂度受控，不同团队独立维护，边界清晰。单个服务便于独立开发、部署、测试、运维。

• 缺点：项目代码不容易规范，每个团队各自为政，随意引入依赖，代码风格各异，不利于 CODE REVIEW；整个应用部署时需要单独的协调；开发人员缺乏对整体项目的认知、缺乏对技术架构、业务整体目标的理解；不同的团队容易重复造轮子（实际上就是造成了“烟囱林立”的局面）。

• 单体仓库

• 优点：易于规范代码：标准化依赖管理，统一 CODE REVIEW；易于继承和部署，配合自动化构建工具，可以做到一键构建、部署，不需要特别的集中管理和协调；易于理解项目整体，便于本地开发测试；利于重用已有代码，重构。

• 缺点：随着规模变大，复杂度会呈指数级上升。需要特别的自研工具。

• 选择：小公司和小团队，项目没有那么复杂，选单体仓库好处更多。

方案取舍

• 取舍时使用的武器——“架构设计三原则”（参见本笔记“如何做好架构设计？-> 架构设计三原则”）

• 合适原则

• 简单原则

• 演化原则

• 取舍时砍向的“敌人”或出发点——即常见判断维度（参见本笔记“如何做好架构设计？-> 架构设计原则常见判断维度”）

• 业务

• 团队

• 技术

• 成本

• 开发周期

• 对方的认可度

所以，方案的取舍过程就是“武器”和“敌人”这两个维度的排列组合——可以看做是一个二维的表格。

实战一的取舍过程如下：

• “合适”原则

• “合适”原则就是“适合”了某个东西

• “适合”团队技术水平和积累

• “适合”的开发成本

• "适合"的运维成本

• “适合”客户的既有技术栈

• 简单原则

• 不进行系统拆分，部署维护简单——即外部复杂性低

• 没用微服务，无需微服务基础设施——还是外部复杂性低

• 演化原则

• 业务场景固定，无需太多考虑后期演化

• 学生数量不会发生很大变化，系统架构够用多年。这一点还可以理解为适合了业务场景的动态发展。

个人理解合适原则是第一位的，其它两个原则可以理解为“合适原则”的特例:

• 简单原则可以理解为适合需求场景时越简单越好。

• 演化原则可以理解为适合当前的阶段。

上述两个维度的变化会演化出很多的架构。架构的变化可以是"4R"的变化，也可以是 4R 本质一样，但各种架构图中的某个局部发生了变化，比如

• 将 MySQL 换成 MongoDB 或 Oracle，这个……好像 4R 都没有变化，只是 Component 种类变化了。

• 某个业务场景下，4R 的本质应该变化不大。所以场景才是系统的灵魂。

• 下一个实战项目就是场景发生了变化，导致系统的灵魂“移形换影”，4R 大变换。

思考题

为什么你做毕业设计的时候没有这样做架构设计?

略，没有这样的毕业设计任务^_^

学生管理云平台实战——学生管理平台的“灵魂”重塑之旅

需求一样，但场景不同，所以说学生管理平台的“灵魂”变了

所谓场景——需求背景

你们是一家创业公司，公司老板具备丰富的高校人脉资源，老板看到各个高校都在重复建设各自的学生管理系统，建设周期长，功能不完善，老板认为做一个学生管理云平台，既能够减少高校这方面的投入，又可以让高校也“上云”。

全中国有 3000 多所高校，这是一个很大的市场。

本节笔记以一种“演化”的视角来写，从外包演化到云平台，紧紧围绕“场景”这个系统的灵魂的演化。

判断复杂度

• 复杂度判断“必选动作”

• 场景变化带来的不一样的高性能——用户人数的巨大提升

• 场景变化带来的不一样的高可用——空间分布的极大扩大化，覆盖全国

• 场景变化带来的不一样的可扩展——高校数量的增多，带来的需求的多样化，使得可扩展由可选变为必选

• 复杂度判断“可选动作”

• 场景变化带来的额外需求——高校之间要隔离，数据要保证安全

拆解

与上一节“外包项目”一样，因为功能需求没有变化，变化的是平台需求。

方案取舍

在这里，进一步的明确了方案的取舍分为两步：

• “复杂性取舍”：到底有哪些复杂性是真正需要架构方案需要考虑的；

• “方案取舍”：确定了需要处理的复杂性后，在设计出的多个备选方案中“取舍”一个

• 复杂性取舍

• 合适原则、简单原则、演化原则

• 此时的“敌人”即分析对象仍然是业务、团队、技术、成本、开发周期、复方的认可度等。

• 高性能：高校数量 * 在校人数 = 3000 * 10万 = 3亿用户： 不适合当前的业务发展现状，即违背演化原则

• 高可用：全国这么多高校，要分四个大区：东南西北大区：同样不符合当前业务发展阶段，同时未必真的四个大区就好，即违背演化原则和简单原则

• 可扩展：这么多高校，需求肯定各种变化，可扩展是必须的：这个适合"高校多"的业务目标，即遵循了合适原则

• 其它：高校之间要隔离，数据要保证安全: 这个适合"高校多"的业务目标，即遵循了合适原则

• 方案取舍

此时已经明确了架构方案需要应对的复杂性，即合适原则已经得到了一定程度的满足，重点考虑简单和演进原则。

根据复杂性分析，数据隔离是必须的，剩下的根据服务是否隔离、单/双机房两个维度分为四个方案。根据简单性原则和演进原则，选择方案一。

• 不采用服务隔离，因为这样增加了复杂性；

• 不采用双机房，因为这样成本大，不符合演进原则。成本分析好像更适合演进原则，因为成本没有复杂和简单之说，而只是一个由少到多的“演进”过程。

思考题 1

如果央行要做一个各个银行都需要接入的系统，请问你会如何考虑“演进原则”?

联系使用本节课的套路进行分析，即首先利用“三原则”判断复杂性，看看哪些复杂性需要重点考虑；然后再使用“三原则”选取方案。

判断复杂度

• 高性能。

• 根据知乎上的搜索结果中国有多少家银行啊？,我国最多有 5000 家银行。所以高性能大体可以从如下几个角度来分析

• 高并发。所有银行全部接入，也才 5000 个，这个数量和互联网的海量高并发比起来，看似不算什么，可是互联网一般面对的是 2C 用户，每个用户一般情况下就一个线程，央行不可能对每家接入的银行分配一个线程，如果每家银行分配 100 个线程的话，那并发量就是 5000*100 = 50 万的并发，数量级还是不低的，况且很多涉及到账务交易，要求强一致性。

• 交易延时。商业银行间的交易由于至少涉及三个主体：两个交易对手行和人行，每家银行的规模，IT 系统的情况千差万别，又涉及到账务交易，所以应该允许一个较高的延迟；同时是异步的，这样才可以更好的处理这种类似分布式事物的场景。

• 吞吐量。较高的延时，加上批量交易的存才，吞吐量应该是较高的。

• 高可用

• 对接 N 家银行，金融又是国民经济的血液，所以高可用是最为看重的，一旦发生宕机，对国家的影响非常重大。

• 可扩展

• 银行间清结算等业务具有固定的逻辑，央行的职责也不可能轻易的发生变化，所以从业务多样性来说，对可扩展性的要求应该不高。但是由于需要满足高可用可一定的高性能，系统一定是具有良好的可伸缩性，但注意：可伸缩性不是可扩展性，不能把二者混为一谈。

• 其它

• 国家政策法规是重要的考量点；

• 技术一定是采用成熟稳定，经过市场检验的技术；

• 成本。央行的经费应该来自于财政拨款，而财政预算是按年度进行的，所以预算明确，以为着目标明确。

拆解问题

还是分为逻辑拆解和物理拆解

• 逻辑拆解

• 通过央行接入的银行众多，所以只有大家都有的需求才会体现在系统中，这就决定了抽象的层次非常高，不会体现很多非常个性的需求，所以整体上逻辑还是不应该非常复杂，否则无法做到这么高的抽象层级。

• 具体的就只能猜了。

• 物理拆解

• 因为要满足高可用，所以部署架构一定非常复杂，比如三地五中心之类的。

方案取舍

• 合适原则

• 在判断复杂度的时候，已经确认了高性能和高可用是必须满足的，是适合业务场景的。

• 简单原则

• 在做到高性能和高可用的目标下，系统由如此重要，所以即使再简单化处理，也是一个复杂的系统。

• 演化原则（重点考虑）

• 考虑到财政预算问题，不可能一下子实现全部功能，要分期进行开发、部署；

• 考虑到接入银行众多问题，不可能一下子接入全部银行，只能分批次接入。

• 高可用带来的大范围、多中心的部署，也不能一下子完成，只能借助良好的可伸缩性，逐渐完成部署。

思考题 2

如果教育部要做一个学生管理云平台，请问你会如何考虑“演进原则”?

因为还是学生管理云平台，所以逻辑拆解应该还是类似的，这里还可以沿用公司开发学生管理云平台的过程的套路。

这里先取舍复杂度。把之前确认的复杂度重新列在这里

• 高性能：高校数量 * 在校人数 = 3000 * 10 万 = 3 亿用户。

• 高可用：全国这么多高校，要分四个大区:东南西北四个大区。

• 可扩展：这么多高校，需求肯定各种变化，可扩展是必须的。

• 其它：高校之间要隔离，数据要保证安全。

下面用”演进原则“来对这些复杂性进行分析。

• 高性能。在设计上，一步到位；投入上，逐渐演化。与公司开发云平台不同，因为是教育部做学生管理云平台，那注定是全部高校都要接入，所以长期来看，高性能里列出的目标是一定会达到的；所以在架构设计的时候一定要针对此点做出设计。但这么多用户不是一下子就达到的，演进原则在这里仍然使用——在投资上，是一个逐渐追加的过程。

• 高可用。这一点和高性能一样，最终也需要达到这个目标，但绝不是一蹴而就的，而是逐步投入。

• 可扩展和其它两项的分析不变。