《架构模式》阅读笔记 —— 经典的5种架构模型

 

 

引自：《Software Architecture Patterns》

附脑图

分层架构

分层架构（layered architecture）是最多见的软件架构，也是事实上的标准架构。

• 解耦方式：每一层都有清晰的角色和分工，而不须要知道其余层的细节。
• 通信方式：层与层之间经过接口通讯。

架构模型

一般结构可分为4个标准层级，各层级的定义以下：

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

So why not allow the presentation layer direct access to either the persistence layer or database layer? After all, direct database access from the presentation layer is much faster than going through a bunch of unnecessary layers just to retrieve or save database information. The answer to this question lies in a key concept known as layers of isolation.

The layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers: the change is isolated to the components within that layer, and possibly another associated layer (such as a persistence layer containing SQL).

The layers of isolation concept also means that each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture.

层级隔离的设计理念，使得层与层之间实现了高内聚、低耦合。

Creating a services layer is usually a good idea in this case because architecturally it restricts access to the shared services to the business layer (and not the presentation layer). Without a separate layer, there is nothing architecturally that restricts the presentation layer from accessing these common services, making it difficult to govern this access restriction.

层级架构也使得增长新的业务层更加容易——由于层级（模块）间的耦合度很低，新的层级只须要处理层与层之间的接口就OK了。

示例

调整业务结构，咱们增长一个新的层级——服务层。

The services layer in this case is marked as open,  meaning requests are allowed to bypass this open layer and go directly to the layer below it.

In the following example, since the services layer is open, the business layer is now allowed to bypass it and go directly to the persistence layer, which makes perfect sense.

因为新的层级是开放的而非闭合的，它容许上游层越过自身，实现直接对下游层数据的访问。

小结

分层架构能够直观的实现不一样层级逻辑代码的解耦合，除此以外：

• 结构简单，容易理解和开发
• 不一样技能的程序员能够分工，负责不一样的层，自然适合大多数软件公司的组织架构
• 每一层均可以独立测试，其余层的接口经过模拟解决

缺点：

• 一旦环境变化，须要代码调整或增长功能时，一般比较繁杂和费时
• 部署很麻烦：即便只修改一个小地方，每每须要整个软件从新部署，不容易作持续发布
• 软件升级时，可能须要整个服务暂停
• 扩展性差：用户请求大量增长时，必须依次扩展每一层，因为每一层内部是耦合的，扩展会很困难

模式分析：

• 整体灵活性： 低
• 发布易用性： 低
• 可测试性： 高
• 性能： 低
• 规模扩展性： 低
• 开发容易度： 高

事件驱动架构

事件驱动架构（Event-Driven Architecture）是一个流行的分布式异步架构模式。基于这种架构模式应用可大可小。它由高度解耦、单一目的的事件处理组件组成，能够异步地接口和处理事件。

事件：系统或组件的状态发生变化时，系统层发出的通知。

解耦方式：每一个对象都经过与中间件（Mediator or Broker）实现与外界的沟通，而不是相互依赖（迪米特法则）。

通信方式：以消息为载体、经过中间件传递通信。

拓扑结构 - 分类

The event-driven architecture pattern consists of two main topologies, the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events together without the use of a central mediator. Because the architecture characteristics and implementation strategies differ between these two topologies, it is impor‐tant to understand each one to know which is best suited for your particular situation.

Broker拓扑架构

相比于后面讲到的Mediator，Broker是一种更本质也更简洁的EDA（不知道做者为什么选择先讲解复杂的Mediator，我的认为应该将这个顺序调整过来）。

该结构包含了三个组件：

1. Event：事件消息；
2. Event Channel：消息队列或者是Topic，根据订阅推送（或是转发）消息；消息可能被转发到Event Processor，或是其余的Event Channel中。
3. Event Processor：得到消息后执行处理。它多是一个消息的处理终结点，也可能在处理过程当中继续下发消息，或生成新的事件，并被再次提交到Event Channel中，继续下一轮的转发和处理。

示例

如上图：当系统中的某个对象触发了某个事件，事件被提交到Custormer Process，而后派送到Broker。Broker将解析事件并转发到相关的Processor中执行处理（注意，两个Processor是各自独立进行的，不存在任何耦合）。而在Processor中又触发了新的事件（“责任链”模式），并经过各自的Channel转发到另外的Processor中完成处理。

在Mediator中，咱们将看到Mediator模式对该问题的另一种处理方式。

Mediator拓扑结构

Mediator能够说是Broker的一种拓展，更适用于粗粒度事件的处理——因为业务逻辑更复杂，细粒度的拓扑结构将形成消息臃肿而混乱，固然，粗粒度也增长了EDA架构的复杂度。

采用Mediator模式的架构中，事件通常是复杂的（包含多个执行单元的合集），而Mediator的责任就是将该复合事件拆解为独立的子事件，而后发送到不一样类型的子事件处理系统中，由子系统完成独立子事件的分发和处理。

在结构上，Mediator的EDA架构包括4个组件：

1. event queues：用于原始事件（分类）存储，并转发给Event Mediator，通常是以MQ的形式存在。
2. event mediator：用于原始事件的拆解（成为多个独立子事件），并转发给相关的Channel；
3. event channels：通道（能够理解为细分的Event Queue），按照事件的类型不一样做以划分。它能够是一个消息队列，提供给特定的Processor查询，或是消息Topic，发送特定的广播。
4. event processors：事件处理器，监听特定的Channel，并在捕获事件后进行处理

在逻辑上，Mediator的处理过程以下：

The event flow starts with a client sending an event to an event queue, which is used to transport the event to the event mediator. The event mediator receives the initial event and orchestrates that event by sending additional asynchronous events to event channels to execute each step of the process. Event processors, which listen on the event channels, receive the event from theevent mediator and execute specific business  logic to process the event.

It is common to have anywhere from a dozen to several hundred event queues in an event-driven architecture. The pattern does not specify the implementation of the event queue component; it can be a message queue, a web service endpoint, or any combination thereof.

EDA对 Event Queues 并无特定的实现要求，不管是数量仍是类型，均可以根据实际须要肯定。

There are two types of events within this pattern: an initial event and a processing event. The initial event is the original event received by the mediator, whereas the processing events are ones that are generated by the mediator and received by the event-processing components.

对应于 Event Queues 和 Event Channel，也一样存在着两种事件类型：原始事件（或者称为：复合事件）和处理事件。
呃，这句话倒过来讲更合适：由于有不一样的事件类型，因此须要对应存在不一样的队列。

Event channels are used by the event mediator to asynchronously pass specific processing events related to each step in the initial event to the event processors. The event channels can be either message queues or message topics, although message topics are most widely used with the mediator topology so that processing events can be processed by multiple event processors (each performing a different task based on the processing event received).

The event processor components contain the application business logic necessary to process the processing event. Event processors are self-contained, independent, highly decoupled architecture components that perform a specific task in the application or system. While the granularity of the event-processor component can vary from fine-grained (e.g., calculate sales tax on an order) to coarsegrained (e.g., process an insurance claim), it is important to keep in mind that in general, each event-processor component should perform a single business task and not rely on other event processors to complete its specific task.

事件处理器包含实际的业务逻辑。每一个消息处理器都是自包含的，独立的，高度解耦的，执行单一的任务（高内聚低耦合的要求使然）。这部分是咱们开发和拓展业务的主要战场。

有一些开源的框架实现了这种架构，如Spring Integration, Apache Camel, 或者 Mule ESB。

固然，这种架构包含了多种形式的变种，你应当可以根据须要，灵活的替换相应的子模块以适配需求。

示例

仍是刚才的Move的例子，在Broker的架构中，事件以递归方式，实现自包含，经过Processor与Channel的互相调用完成消息的传递。这是所谓“责任链”模式的体现。

而Mediator则是经过统一的封装性，将自己的Move事件封装成若干子事件，每一个子事件由不一样的Event Channel在子系统内实现派发。这样的模式效率无疑是更高的，但它要求固定的问题域——这就致使其可拓展性较差，一旦体系须要拓展，或原Event结构出现变化，子系统也必须全盘修改。

小结

架构考量：

事件驱动架构模式实现起来相对复杂，主要是因为它的异步和分布式特性。这可能会带来一些分布式的问题，好比远程处理的可用性，缺少响应，broker重连等问题。

优势：

• 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
• 适用性广，各类类型的项目均可以用
• 性能较好，由于事件的异步本质，软件不易产生堵塞
• 事件处理器能够独立地加载和卸载，容易部署

缺点：

• 涉及异步编程（要考虑远程通讯、失去响应等状况），开发相对复杂
• 难以支持原子性操做，由于事件经过会涉及多个处理器，很难回滚
• 分布式和异步特性致使这个架构较难测试

模式分析

• 整体灵活性： 高
• 发布易用性： 高
• 可测试性： 低
• 性能： 高
• 规模扩展性： 高
• 开发容易度： 低

微内核架构

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都经过插件实现。

内核（core）一般只包含系统运行的最小功能。插件则是互相独立的，插件之间的通讯，应该减小到最低，避免出现互相依赖的问题。

解耦方式：业务相关项以插件的形式发布，能够选择动态加载。业务插件只与内核交互，实现业务间的低耦合。

通信方式：插件与内核，经过内核发布的特定接口进行通信（通信样式无限制）

架构模型

The microkernel architecture pattern consists of two types of architecture components: a core system and plug-in modules. Application logic is divided between independent plug-in modules and the basic core system, providing extensibility, flexibility, and isolation of application features and custom processing logic.

因为许多的系统都是采用的相似架构设计，该架构模式所以得名。

The microkernel architecture pattern consists of two types of architecture components: a core system and plug-in modules. Application logic is divided between independent plug-in modules and the basic core system, providing extensibility, flexibility, and isolation of application features and custom processing logic.

内核系统是一种最小化开发的、可以保证程序基本运行的应用。通常不包含业务层，基本的业务逻辑也是抽象化的通用性规则。而具体规则和业务逻辑，则经过不一样的插件拓展实现。

The plug-in modules are stand-alone, independent components that contain specialized processing, additional features, and custom code that is meant to enhance or extend the core system to produce additional business capabilities. Generally, plug-in modules should be independent of other plug-in modules, but you can certainly design plug-ins that require other plug-ins to be present. Either way, it is important to keep the communication between plug-ins to a minimum to avoid dependency issues.

想要插件之间彻底没有耦合是不合理的，但尽量的减小插件之间的耦合，关系到整个体系的运转与维护。

The core system needs to know about which plug-in modules are available and how to get to them. One common way of implementing this is through some sort of plug-in registry. This registry contains information about each plug-in module, including things like its name, data contract, and remote access protocol details (depending on how the plug-in is connected to the core system). For example, a plug-in for tax software that flags high-risk tax audit items might have a registry entry that contains the name of the service (AuditChecker), the data contract (input data and output data), and the contract format (XML). It might also contain a WSDL (Web Services Definition Language) if the plug-in is accessed through SOAP.

通常的，插件经过注册机制挂载到内核上。内核将维持一个插件列表，以了解当前系统中的每个组件。插件的挂载方式能够有多种，例如经过 dlopen( ) 将lib库载入内核进程内存；或是经过 SOA 模式加载服务项，并执行服务调用；或是经过点对点 socket 创建 romote object  proxy 的队列，并执行RPC调用，等等。更多的方式见下一段：

Plug-in modules can be connected to the core system through a variety of ways, including OSGi (open service gateway initiative), messaging, web services, or even direct point-to-point binding (i.e., object instantiation). The type of connection you use depends on the type of application you are building (small product or large business application) and your specific needs (e.g., single deploy or distributed deployment). The architecture pattern itself does not specify any of these implementation details, only that the plug-in modules must remain independent from one another.

插件架构模式自己并无限定core与module的链接方式——链接方式通常须要根据具体的应用场景选择不一样的方案。

The contracts between the plug-in modules and the core system can range anywhere from standard contracts to custom ones. Custom contracts are typically found in situations where plug-in components are developed by a third party where you have no control over the contract used by the plug-in. In such cases, it is common to create an adapter between the plug-in contact and your standard contract so that the core system doesn’t need specialized code for each plug-in. When creating standard contracts (usually implemented through XML or a Java Map), it is important to remember to create a versioning strategy right from the start.

插件之间的通讯方式也能够有多种实现，通常的建议使用通用协议，如HTTP或标准socket消息结构。

小结

架构考量：

微内核的架构模式能够嵌入到其它的架构模式之中。微内核架构经过插件还能够提供逐步演化的功能和增量开发。因此若是你要开发基于产品的应用，微内核是不二选择。

模式分析：

• 整体灵活性： 高
• 发布易用性： 高
• 可测试性： 高
• 性能： 高
• 规模扩展性： 低
• 开发容易度： 低

优势：

• 良好的功能延伸性（extensibility），须要什么功能，开发一个插件便可
• 功能之间是隔离的，插件能够独立的加载和卸载，使得它比较容易部署，
• 可定制性高，适应不一样的开发须要
• 能够渐进式地开发，逐步增长功能

缺点：

• 内核扩展性差：内核一般是一个独立单元，不容易作成分布式
• 开发难度相对较高，由于涉及到插件与内核的通讯，以及内部的插件登记机制