软件架构设计学习总结（22）：软件架构——分层架构、事件驱动架构、微内核架构、微服务架构、基于空间的架构…

分层架构 (Layered Architecture)

分层架构是最常见的架构，也被称为n层架构。多年以来，许多企业和公司都在他们的项目中使用这种架构，它已经几乎成为事实标准，因此被大多数架构师、开发者和软件设计者所熟知。比如MVC。

分层架构的一个特性就是 关注分离(separation of concerns) 。在层中的组件只负责本层的逻辑。组件的划分很容易让它们实现自己的角色和职责，也比较容易地开发，测试管理和维护。

我们需要这样的冗余，即使业务层没有处理业务规则，也要通过业务层来调用数据层，这叫 分层隔离 。对于某些功能，如果我们从表现层直接访问数据层，那么数据层后续的任何变动都将影响到业务层和表现层。

注意分层的 开闭原则 。如果某层是关闭的，那么每个请求都要经过着一层。相反，如果该层是开放的，那么请求可以绕过这一层，直接到下一层。

分层隔离有利于降低整个应用程序的复杂度。某些功能并不需要经过每一层，这时我们需要根据开闭原则来简化实现。

但是，上述的好处是有条件的：应用不那么复杂。对于大规模的复杂应用，巨石型应用会显得特别笨重：

• 要修改一个地方就要将整个应用全部部署（PS：在不同的场景下优势也变成了劣势）；

• 编译时间过长；回归测试周期过长；

• 开发效率降低等。

• 巨石应用不利于更新技术框架，除非你愿意将系统全部重写（代价太高你愿意老板也不愿意）。

架构举例

我们看一下淘宝前几年的架构的例子：

围着着这个主架构还有一些外围的产品。比如监控和审计。

Tips:

• 不同的阶段，不同的业务场景，不同的业务复杂度，不同的团队，适合不同的分层。

• 有些分层是兼容低端情况（初创公司用起来也很美，还兼顾以后的发展和迭代），有些不兼容（团队层次达不到，玩不转）。

• 分层将导致复杂度的上升。（博弈）

• 注意接口和边界。（不然白分）

事件驱动架构 (Event-Driven Architecture)

事件驱动架构（Event Driven Architecture）是一种流行的分布式异步架构模式，用于创建可伸缩的应用程序。这种模式是自适应的，可用于小规模或者大规模的应用程序。它由高度解耦的，单一目的的事件处理组件组成，可以异步地接收和处理事件。

它包括两个主要的拓扑结构： 调停者拓扑（Mediator Topology） 和 代理者拓扑（Broker Topology） 。Mediator拓扑结构需要你在一个事件通过mediator时精心安排好几个步骤，而broker拓扑结构无需mediator，而是由你串联起几个事件。这两种拓扑架构的特征和实现有很大的不同，所以你需要知道哪一个适合你。

调停者拓扑（Mediator Topology）

Mediator拓扑结构适合有多个步骤的事件，需要安排处理层次。

例如购买一只股票，首先会校验这个交易，校验股票交易是否符合各种规定，将它交给一个经纪人，计算佣金，最后确认交易。所有这些都安排好各个步骤的顺序，决定它们是否串行还是并行。

通常，架构主要包含4种组件，事件队列（Event Queue）、调停者（Mediator）、事件通道（Event Channel）和事件处理器（Event Processor）。客户端创建事件，并将其发送到事件队列，调停者接收事件并将其传递给事件通道。事件通道将事件传递给事件处理器，事件最终由事件处理器处理完成。

如图所示，它包含两个组件broker和 event processor。broker中的event channel可以是消息队列，消息topic或者它们的复合形式。每个event processor负责处理事件，发布新的事件。

举例

这种模式非常适合桌面应用程序，但是也可以在Web应用程序中使用。事实上，许多不同的架构模式可以作为整个系统的一个插件。对于产品型应用程序来说，如果我们想将新特性和功能及时加入系统，微内核架构是一种不错的选择。

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

微服务架构(Microservices architecture)

尽管微服务的概念还相当新，但它确实已经快速地吸引了大量的眼球，以替代整体应用和面向服务架构（SOA）。其中的一个核心概念是具备高可伸缩性、易于部署和交付的独立部署单元（Separately Deployable Units）。最重要的概念是包含业务逻辑和处理流程的服务组件（Service Component）

不管你使用何种实现风格和拓扑，有几个通用的核心概念应用在这种架构模式上。首先是分隔发布单元（separately deployed units）。

这张图从三个维度概括了一个系统的扩展过程：

• x轴，水平复制，即在负载均衡服务器后增加多个web服务器；

• z轴扩展，是对数据库的扩展，即分库分表（分库是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据通过hash放在不同的数据库服务器上）；

• y轴扩展，是功能分解，将不同职能的模块分成不同的服务。

从y轴这个方向扩展，才能将巨型应用分解为一组不同的服务，例如订单管理中心、客户信息管理中心、商品管理中心等等。

实现方式

有很多实现微服务的方式。最通用最流行的三个方式是:

• API REST-based

• applicaiton REST-based

• 中心化的消息

API REST-based 适合 站提供小规模的，自包含的服务。很多互联 站都提供这样的服务，比如OAuth2服务。

中心消息模式，它类似前面的模式，但是使用一个轻量级的消息broker取代RESTful的服务调用。这个轻量级的broker不会执行服务的编排，传输和路由，这和SOA不同，不要把它看作SOA的简化版

处理单元包含应用程序。小的应用程序可以使用一个处理单元，大的应用程序可以被分隔成几个处理单元。处理单元还包括数据 格。

虚拟化中间件负责管理和通信。处理数据的同步和请求。

基于空间的架构是一个复杂而昂贵的模式。对于小型的负载可变的web应用很适合，但是对于大型的关系型数据库应用不是太适合。

比较