@mSolo 2015-04-28T21:53:04.000000Z 字数 2765 阅读 2363

极简软件架构模式（Mark Richards）

架构

分层架构

尽管分层架构没有规定自身要分成几层，但大多数的结构都分成四个层次:展示层，业务层，持久层，和数据库层。
分层架构中的每⼀层都着特定的角色和职能。
分层架构的⼀个突出特性是组件间关注点分离，一个层中的组件只会处理本层的逻辑。比如说，展示层的组件只会处理展⽰示逻辑，业务层中的组件只会去处理业务逻辑。
request 必须⼀层一层的传递。举个例子，从展示层传递来的请求首先会传递到业务层，然后传递到持久层，最后才传递到数据层。
注意事项
- 污水池反模式 (architecture sinkhole anti-pattern)，80-20 原则可以帮助你确定架构是否处于反污水模式。
评级
- 整体灵活性: 低。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。
- 易于部署: 中。
- 性能: 低。因为⼀次业务请求要穿越所有的架构层，做了很多不必要的工作。
- 伸缩性: 低。由于这种模式以紧密耦合的趋势在发展，规模也比较⼤大，用分层架构构建的程序都比较难以扩展。

事件驱动架构模式是一种主流的异步分发事件架构模式，常用于设计高度可拓展的应用。
设下标准的数据格式成为使用事件驱动架构模式中至关重要的一环（例如： XML，JSON，Java 对象，等等……），并在架构创建之初就为这些数据格式授权，以便处理。
顾虑: 如果你发现用多个不同的事件处理器处理的哪些业务其实是可以合并到⼀个业务事件之中的，那么这种模式可能并不适合你的应用，又或者是你的设计出了问题。
评级
- 整体灵活性: 高。
- 易于部署: 高。
- 性能: 高。
- 伸缩性: 高。
事件驱动架构模式包含了两种主要的拓扑结构

适合用于拥有多个步骤，并需要在处理事件时能通过某种程度的协调将事件分层的场景。
结构中主要有四种组件
- 事件队列（event queue）
- 事件中介: 事件中介最简单、常⻅见的实现就是使⽤用开源框架，例如： Spring Integration，Apache Camel 或 Mule ESB。事件流在这些开源框架中通常⽤用 Java 或领域特定语言（ domain-speciﬁc language）。在调节过程和业务流程都很复杂的使⽤用场景下，你可以使用业务流程执行语言（BPEL - business process execution language）结合类似开源框架 Apache ODE 的 BPEL 引擎进行开发。
- 事件通道（event channel）
- 事件处理器（event processor）: 为了能顺利处理待处理事件，事件处理器组件中包含了应用的业务逻辑。此外，事件处理器作为事件驱动架构中的组件，不依赖于其他组件，独立运作，高度解耦，在应用或系统中完成特定的任务。

也称为插件化应用架构
需要考虑设计和规约管理
应用逻辑被划分为独⽴立的插件模块
通常，插件模块之间应该是没有任何依赖性的，但是也可以设计⼀个需要依赖另一个插件的插件。但无论如何，使得插件之间可以通信的同时避免插件之间产生依赖又是一个特别重要的问题。
核心系统需要了解插件模块的可用性以及如何获取到它们。一个通用的实现方法是通过⼀一组插件注册表。这个插件注册表含有每个插件模块的信息，包括它的名字、数据规约和远程访问协议(取决于插件如何与核心系统建立连接 )。
插件模块可以通过多种方式连接到核心系统，包括 OSGi、消息机制、web 服务或者直接点对点的绑定( 比如对象实例化，即依赖注入 )。
插件和核心系统的通信规范包含标准规范和自定义规范。自定义规范典型的使用场景是插件组件是被第三方构建的。在这种情况下，通常是在第三方插件规约和你的标准规范创建一个Adapter来使核心系统根本不需要知道每个插件的具体细节。
对于微内核架构来说⼀个很重要的⼀点就是它能够被嵌入或者说作为另⼀种架构的⼀部分。
评级
- 整体灵活性: 高。
- 易于部署: 高。
- 性能: 高。
- 伸缩性: 低。

仍然在不断的发展中，在业界存在很多困惑。
微服务架构的每个组件都作为⼀个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通信，同时它还有很强的扩展性，应用和组件之间高度解耦，使得部署更为简单。
也许要理解这种模式，最重要的概念就是服务组件（service component）。不要考虑微服务架构内部的服
务，而最好是考虑服务组件，从粒度上讲它可以小到单⼀的模块，或者大至⼀个应⽤用程序。服务组件包含⼀个或多个模块（如Java类），这些模块可以提供⼀个单⼀功能（如，为特定的城市或城镇提供天气情况），或也可以作为⼀个大型商业应⽤用的⼀个独立部分（如，股票交易布局或测定汽车保险的费率）。
微服务架构模式的另⼀个关键概念是它是⼀个分布式的架构。
虽然有很多方法来实现微服务架构模式 ,但三个主要的拓扑结构脱颖而出，最常见和流行的有 :基于REST API 的拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。
如果你发现需要从应⽤用内部的用户接口或 API层编排服务组件，那么很有可能你服务组件的粒度太细了。要么是没有从业务功能⾓角度正确划分服务组件。
评级
- 整体灵活性: 高。
- 易于部署: 高。
- 性能: 低。
- 伸缩性: 高。
- 易于开发: 高。