架构实战营模块一作业

1. 架构的理解

1.1 架构定义

4R 架构 – Rank + Role + Relation + Rule

软件架构指软件系统的顶层结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。

以上是老师给出的一个架构定义和图示，其中这四个 R 还是比较好理解的，但是个人对于顶层结构这个有点疑惑，既然是分层的，为何是顶层的？那应该也是对应的层级结构，而且不同的架构类型不一定都具备这 4R，我的理解架构是不同层级和不同应用场景下架构的一个打包，在整个架构包中包含了 4R。

1.2 架构的种类以及应用场景

1.2.1 业务架构

【定义】：描述系统对用户提供了什么业务功能。

【使用场景】：

1.产品人员规划业务；

2. 给领导汇报业务；

3. 给新员工培训业务。

1.2.2 客户端架构、前端架构

【定义】：客户端和前端的领域逻辑架构。

【使用场景】：

1. 整体架构设计；

2. 架构培训

1.2.3 系统架构

【定义】：后端的逻辑架构。

【使用场景】：

1.整体架构设计；

2. 架构培训。

之前公司领导分配一个画系统架构的任务，由于对架构理解不清晰，分不清楚各类架构，根本不知道从何处下手，在网上搜索一通反而更加迷惑 。这次通过老师的讲解，有一种豁然开朗的感觉。

2.画出微信的业务架构图。

微信从 2011 年诞生至今已有 11 年有余，由 1.0 版本逐渐演化到如今的 8.0 版本，功能与场景愈发丰富，从最初的通讯工具到社交平台信息平台，生活入口，连接人连接设备连接服务。可以想见当时的第一个版本其架构设计具备很好的扩展性。

学习首先是模仿，它山之石可以攻玉，为更好的学习微信优秀的系统架构，试着从业务架构逐步解构微信，后续学习其客户端架构，后台系统架构，应用架构，部署架构。

微信顶层业务架构图如下：

第一个 R，Rank 分层，这次是对其业务功能模块进行划分，应该是属于最顶层；第二个 R，Role 对象角色，我们解构的是系统的功能模块，需要根据业务的相似性进行组织划分；第三个 R，Relation，关系，模块内是业务功能具有相似性，高内聚，模块之间需要低耦合，此处的业务架构图无法体现各个模块之间的关系，需要交互图作为补充，但是貌似这些模块之间没有很明确的关系；第四个 R，Rule，规则，由于是一个顶层的业务架构，比较抽象，所以不在此处体现规则，所以我的理解是不是每一层的架构都有四个 R。

3.学生管理系统”毕设架构设计

3.1 业务背景

假设今年学校毕业设计要求提升，要求做真正可运行的学生管理系统。

3.2 约束和限制

① 要求可以通过公网域名访问；

② 要求至少 3 人合作完成；

③ 能够支撑管理 1000 个学生；

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

3.3 架构分析

3.3.1 高可用

学生、课程、选课、考试成绩数据对于学校来说都是非常重要的，若出现大量数据丢失影响验证，数据恢复需要人工一条一条手工补录，恢复时间长，因此在数据高可用这块需要保障，系统层面若发生故障对学校的正常教学影响不大，所以系统高可用不需要过多考虑。

3.3.2 高性能

因为用户数量不多，整体性能也不需要过多要求。

3.3.3 可扩展

选课业务流程和场景相对清晰稳定，可以不考虑可扩展性。

3.3.4 可维护性

软件一次性交付完成后交由专门的人员进行运维，需要具备一定的可维护性。

3.3.5 安全性

考虑到学生的信息私密性、学生成绩不能造篡改以及考试题目不能泄露，系统要考虑防攻击措施，保证数据安全。

3.3.6 成本

学生无收入来源，经济条件一般，无太多的预算。

综合来看，系统首要需要满足数据的高可用和安全性，其次满足成本、可维护性、高可用、高性能的要求。

3.4 架构设计

3.4.1 架构一

1）采用 B/S 架构，客户端使用浏览器；

2）前置采用 Nginx 作为入口网关，部署单个实例，域名解析至单台 Nginx 服务器；

3）为了防御一般性攻击 Nginx 前配置公有云 WAF，来保障安全性；

4）服务端拆采用 MVC 框架 Java 实现；

5）数据存储层采用 MySQL，Innodb 作为存储引擎，部署一主一备，主备复制，以达到高可靠目标。

3.4.2 架构二

1）在方案 1 的基础上采用双实例部署，Nginx 实现负载均衡，从而达到一定的高可用性。

2）数据存储层替换，采用 MongoDBL，主从配置，保证数据可靠。

3.4.3 架构三

1）与方案 1 区别在于采用微服务，服务端前端使用 PHP，后端子系统 Java 开发微服务；

2）为了满足计算层高可用，三个子系统均采用双实例部署，部署整套微服务基础设施。

3.4.4 最终方案

合适原则

方案 1 和 2 的区别在于业务系统的部署和底层数据存储的区别，Java 开发也符合团队的技术要求，开发和运维的成本都是比较低，方案 3 虽然符合了团队中的技术水平，但采用了微服务运维成本更高，所以是不合适的。

简单原则

方案 1 和 2 都没有进行系统拆分，但方案 2 采用了集群部署，增加了维护难度，对于学校的运维人员来说会有一定的难度，方案 3 采用了微服务，需要微服务基础设施，增加了开发和运维的复杂度。

演化原则

整体功能已比较清晰，未来业务也不会有大的变化，一次交付即可。

综上所述

方案 3 不符合简单和合适原则，不予考虑。方案 2 在没有高可用的情况下增加高可用部署，增加了运维复杂度，不符合简单原则，综合来看方案 1 是比较合适的。