架构师考点大纲6 架构分类

软件架构 2.6k 字 次

本文整理几个架构分类知识。从网上收集，加了个人的理解，汇总而得。

传统的五类风格

其它

试分析和比较B/S，二层C/S和三层C/S，指出各自的优点和缺点。

image-20211013000705765

image-20211013000715234

image-20211013000734355

image-20211013000742800

image-20211013000840308

三层C/S架构

传统的二层C/S结构有以下几个局限性：
1、二层C/S结构是单一服务器组成以局域网为中心，难以扩展到大型企业的广域网或Internet。
2、软硬结合有限。
3、客户机负荷太重，难以管理大量的客户机。
4、数据安全性不好。

正是因为二层C/S有这么多缺点，因此，三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三个部分，如图2所示。

image-20211013003143402

表示层 是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户接口，操作简单、易学易用。在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。

功能层 相当于应用的本体，它是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额，按照定好的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如，用户检索数据时，要设法将有关检索要求的信息一次性地传送给功能层，而由功能层处理过的检索结果数据也一次性地传送给表示层。通常，在功能层中包含有确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。功能层的程序多半是用可视化编程工具开发的，也有使用COBOL和C语言的。

数据层 就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用SQL语言。
　　 三层C/S的解决方案是：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。

一般情况是只将表示层配置在客户机中，如果连功能层也放在客户机中，与二层C/S结构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变坏。

如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器。因此，系统规模越大这种形态的优点就越显著。

一篇文章中的分类

分层架构

分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。
这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。
虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。

  • 表现层（presentation）：用户界面，负责视觉和用户互动
  • 业务层（business）：实现业务逻辑
  • 持久层（persistence）：提供数据，SQL 语句就放在这一层
  • 数据库（database） ：保存数据

有的软件在逻辑层和持久层之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。

分层实现、负责，功能明确，责任清晰。可单独测试每一层。如果修改、调整、扩展功能，较麻烦，涉及层级多。

实例：
参与某公司软件重构，使用分层架构，从底至顶有：

  • 平台接口层(如点灯，读写eeprom)
  • 一般接口层（封装平台接口，如点灯，读写eeprom，封装系统函数，如延时，时间转换）
  • 业务层（再次将底层接口封装为类，如外存读写类、线程类）
  • 应用层（应用程序，如守护进程，升级进程，主进程）

实操中有些不完善的地方，如：从上至下，每一层都做参数的检查判断，调用一个基础接口，要经过2~3层的接口，而且有部分接口只是简单的封装（为了分层而分层）。一些功能不必要逐层调用函数，可直接越过中间层到最底层，但可能与组织管理者理念冲突，而且控制不当会泛滥，不好维护。

事件驱动架构

事件（event）是状态发生变化时，软件发出的通知。
事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。

  • 事件队列（event queue）：接收事件的入口
  • 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
  • 事件通道（event channel）：分发器与处理器之间的联系渠道
  • 事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

异步处理，性能较好，扩展性好，事件处理器之间解耦。开发复杂，涉及远程通信。测试麻烦。原子操作难，回滚比较困难。

实例：
暂未实质搞过，KubeEdge 的 beehive 可能算是一个。

微核架构

微核架构（microkernel architecture）又称为”插件架构”（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

插件形式，安装卸载方便，容易部署。延伸性（extensibility）好，高度定制，需要添加功能时，加插件即可。开发难度大，添加内核和插件的通信、插件登记。展性（scalability）差，不易做成分布式。

微服务架构

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
微服务架构分成三种实现模式。

  • RESTful API 模式：服务通过 API 提供，云服务就属于这一类
  • RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
  • 集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群

扩展性好，各个服务之间低耦合，部署方便，开发容易，易于测试。服务可能拆分太细，微服务过多，杂乱且性能不好，原子操作难，回滚比较困难。
实例：
未搞过。

云架构

云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。
它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（processing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。
这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。
*处理单元：实现业务逻辑
*虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。

虚拟中间件又包含四个组件。

  • 消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
  • 数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
  • 处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
  • 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

高负载，高扩展性，可动态部署。实现复杂，成本高，测试难，适合网站类应用。

实操：

参考资料

阮一峰，软件架构入门： http://www.ruanyifeng.com/blog/2016/09/software-architecture.html