常见的软件架构模式(译)
请设想下一个大型企业级系统需要如何设计？ 在开始主要软件开发之前，我们必须选择一个合适的架构，以提供所需的功能和质量属性。 因此，在将它们应用到的设计之前，我们应该了解不同的的架构。
译自：10 Common Software Architectural Patterns in a nutshell
架构模式定义
架构模式（Architectural Pattern）是软件架构中在特定环境下，针对常见的问题、通用性且可复用的解决方案。
类似于软件设计模式但覆盖范围更广，致力于软件工程中不同问题，如计算机硬件性能限制、高可用性、业务风险极小化。一些架构模式会透过软件框架实现。
常见架构模式
分层模式
Layered pattern：分层模式，此模式可用于构建可分解为子任务组的程序，每个子任务都处于特定抽象组别。
分层架构中的每一层都被标记为封闭或开放。封闭层意味着请求从一层移到另一层，每一层都为下一层更高层提供服务。请求不能跳过任何层。
最常见的通用信息系统的 4 层，如下所示。
- 表示层（也称为 UI 层）
- 应用层（也称为服务层）
- 业务逻辑层（也称为领域层）
- 数据访问层（也称为持久层）
应用场景：
- 一般桌面应用程序
- 电商网络应用程序
C/S 模式
Client-server pattern：C/S 模式，这种模式由两方组成； 一个服务器和多个客户端。
服务器组件将为多个客户端组件提供服务。 客户端向服务器请求服务，服务器为这些客户端提供相关服务。 此外，服务器会持续侦听客户端请求。
应用场景：
- 在线应用程序。如，电子邮件，文档共享 和 银行业务。
主从模式
Master-slave pattern：主从模式，这种模式由两方组成：主组件和从组件。 主组件在相同的从组件之间分配工作，并根据从组件返回的结果计算最终结果。
应用场景：
- 在数据库复制中，主数据库被视为权威源，从数据库与之同步。
- 连接到计算机系统中总线的外围设备（主驱动器和从驱动器）。
管道过滤器模式
Pipe-filter pattern：管道过滤器模式，此模式可用于构建生成和处理数据流的系统。 每个处理步骤都包含在一个过滤器组件中。 要处理的数据通过管道传递。 这些管道可用于缓冲或同步目的。
应用场景：
- 编译器，连续的过滤器执行词法分析、解析、语义分析和代码生成。
- 生物信息学的工作流程。
代理模式
Broker pattern：代理模式，此模式用于构建具有解耦组件的分布式系统。 这些组件可以通过远程服务调用相互交互。 代理组件负责协调组件之间的通信。
服务器将其功能（服务和特征）发布到代理。 客户端向代理请求服务，然后代理将客户端从其注册中心重定向到合适的服务。
应用场景：
- 消息代理软件，例如 Apache ActiveMQ、Apache Kafka、RabbitMQ 和 JBoss Messaging。
点对点模式
Peer-to-peer pattern：点对点模式，在此模式中，各个组件被称为对等的。
这些组件既可以作为客户端，向其他组件请求服务，也可以作为服务器，向其他组件提供服务。 组件可以充当客户端或服务器或两者兼而有之，并且它可以随时间动态地改变其角色。
应用场景：
- Gnutella and G2等文件共享网络。
- 多媒体协议，例如 P2PTV 和 PDTP
- 基于加密货币的产品，例如 比特币，区块链
事件总线模式
Event-bus pattern：事件-总线模式，该模式主要处理事件，有 4 个主要组件：事件源、事件监听器、通道和事件总线。
源将消息发布到事件总线上的特定通道。 消费者订阅特定通道，监听器会收到发布到这些通道的消息通知。
应用场景：
- Android 开发
- 通知服务
MVC模式
Model-view-controller pattern：模型-视图-控制模式，也称为 MVC 模式，将交互式应用程序分为三个部分：
- model：模型，包含核心功能和数据
- view：视图，向用户呈现信息（可以定义多个视图）
- controller：控制器，处理来自用户的输入
这样做是为了将信息的内部表示与向用户呈现和接受信息的方式分开。 它解耦了组件并允许有效的代码重用。
应用场景：
- 主要编程语言的互联网Web应用架构。
- Web 框架，例如 Django 和 Rails。
黑板模式
Blackboard pattern：黑板模式，最初被设计用来处理复杂、模糊的问题（对于不知道确定性解决方案的问题很有用），在人工智能领域有应用。
一种常用的架构模式，应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。就好像多位不同的专家在同一黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家。
黑板模式是一种问题求解模型，是组织推理的步骤、控制状态数据和问题求解之领域知识的概念框架，它将问题的解空间组织成一个或多个应用相关的分级结构。分级结构的每一层信息由一个唯一的词汇来描述，它代表了问题的部分解。
黑板（一个公共的知识库）在一个问题说明开始到问题被解决的过程中，被不同的专家知识源反复更新。每个知识源部分更新解决问题，只有当黑板中问题的状态符合知识源的内在限制时。
黑板图案由三个主要部分组成。
- blackboard：黑板，一个公共知识库，一个结构化的全局内存，包含来自解决方案空间的对象
- knowledge source：知识源，具有自己表示的专门模块
- control component：控制组件，选择、配置和执行模块。
所有组件都可以访问黑板。 组件可能会产生添加到黑板上的新数据对象。 组件在黑板上寻找特定种类的数据，并可能通过与现有知识源的模式匹配来找到这些数据。
应用场景：
黑板模式的应用场景是要解决的任务可以分为多个子任务。
- 语音识别
- 车辆识别和跟踪
- 蛋白质结构鉴定
- 声纳信号解析。
解释器模式
Interpreter pattern：解释器模式，此模式用于设计一个组件，该组件解释以专用语言编写的程序的组件。 它主要指定如何评估程序行，即以特定语言编写的句子或表达式。 基本思想是为语言的每个符号设置一个类。
应用场景：
- 数据库查询语言，如 SQL
- 用以描述通信协议的语言
微服务架构
Microservices Architecture：微服务架构，是一种软件架构风格，它是以专注于单一职责与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的 API 集相互通信。
微服务是一种以业务功能为主的服务设计概念，每一个服务拥有自己的进程与轻量化处理，都具有自主运行的业务功能，对外开放不受语言限制的 API (最常用的是 HTTP)，服务可以用不同的编程语言与数据库等组件实现，应用程序则是由一个或多个微服务组成。
微服务的规划与单体式应用程序十分不同，微服务中每个服务都需要避免与其他服务有所牵连，且都要能够自主，并在其他服务发生错误时不受干扰。
应用场景：
- 大型 Web 应用系统，例如，电商系统，物流系统，医疗系统。
