五种软件架构

五种软件架构

分层架构

基本描述

每一层负责不同的任务

关键概念

通常不能跨层交互

如图，每一层都有一个CLOSED标识

但是在某些情况下，比如需要一个公共服务层，而业务层可以选择是否使用某些服务，公共服务层就可以被跨越

总结

整体敏捷度

1. 评分：低
2. 解释：整体敏捷性是能够快速响应不断变化的环境。虽然在这种模式中，层与层之间的变化可以被束缚在某一层，但是通常由于软件实现的整体性和组件间的紧密耦合，在这种模式下更改软件结构仍然是繁琐和耗时的。

易于部署

1. 评分：低
2. 解释：根据您实施此模式的方式，部署可能会成为问题，尤其是对于大型应用程序。对组件的一小处更改可能需要重新部署整个应用程序（或应用程序的很大一部分），从而导致需要在下班时间或周末计划，安排和执行部署。因此，这种模式不容易使其适用于连续的交付管道，从而进一步降低了部署的总体评级。

可测试性

1. 评分：高
2. 解释：由于组件属于体系结构中的特定层，因此可以对其他层进行模拟或存根，使这种模式相对易于测试。开发人员可以模拟演示组件或屏幕以隔离业务组件中的测试，也可以模拟业务层以测试某些屏幕功能。

性能

1. 评分：低
2. 解释：虽然确实可以很好地执行某些分层架构，但是由于必须经过架构的多个层来满足业务请求的效率低下，因此该模式无法将其自身应用于高性能应用程序。

可扩展性

1. 评分：低
2. 解释：由于这种模式趋向于紧密耦合和整体实现的趋势，使用这种架构模式构建的应用程序通常很难扩展。您可以通过将层划分为单独的物理部署或将整个应用程序复制到多个节点来扩展分层体系结构，但是总体而言，粒度太宽泛，因此扩展成本很高。

易于开发

1. 评分：高
2. 解释：易于开发获得相对较高的分数，主要是因为这种模式众所周知，并且实施起来不会过于复杂。因为大多数公司通过将技能集按层次（表示，业务，数据库）分开来开发应用程序，所以这种模式成为大多数业务应用程序开发的自然选择。概述了公司的沟通和组织结构与软件开发方式之间的联系，这就是所谓的康韦定律。

事件驱动架构

基本描述

事件驱动架构模式是一种流行的分布式异步架构模式，用于生成高度可扩展的应用程序。它还具有很高的适应性，可用于小型应用程序以及大型，复杂的应用程序。事件驱动的体系结构由高度分离的，单一目的的事件处理组件组成，这些组件异步接收和处理事件。事件驱动的架构模式由两个主要拓扑组成，即分发器（mediator）拓扑和代理（broker）拓扑。

关键概念

组成组件

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

分发器拓扑

分发器结构对于具有多个步骤并且需要某种编排级别的事件才能处理的事件很有用。例如，进行一次股票交易的单个事件可能要求您首先验证交易，然后对照各种合规性规则检查该股票交易的合规性，将交易分配给经纪人，计算佣金，最后放置与那个经纪人交易。所有这些步骤都需要一定程度的编排，以确定步骤的顺序，以及哪些步骤可以串行和并行完成。

代理拓扑

代理拓扑与中介器拓扑的不同之处在于，不存在中央事件中介器。相反，消息流通过轻量级消息代理（例如ActiveMQ，HornetQ等）以链状方式分布在事件处理器组件之间。当您具有相对简单的事件处理流程并且不需要（或不需要）集中事件编排时，此拓扑很有用。

总结

整体敏捷度

1. 评分：高
2. 解释：总体敏捷性是指对不断变化的环境做出快速响应的能力。由于事件处理器组件是单一用途的，并且与其他事件处理器组件完全脱钩，因此更改通常隔离到一个或几个事件处理器，并且可以快速进行而不会影响其他组件。

易于部署

1. 评分：高
2. 解释：总体而言，由于事件处理器组件的分离性质，这种模式相对容易部署。代理拓扑往往比分发器拓扑更易于部署，主要是因为事件分发器组件在某种程度上与事件处理器紧密耦合：事件处理器组件的更改也可能需要事件介体的更改，这需要双方部署用于任何给定的更改。

可测试性

1. 评分：低
2. 解释：尽管单个单元测试不是很困难，但是它确实需要某种专门的测试客户端或测试工具来生成事件。这种模式的异步特性也使测试变得复杂。

性能

1. 评分：高
2. 解释：尽管由于所有涉及的消息传递基础架构，肯定有可能实现一个性能不佳的事件驱动架构，但总体而言，该模式通过其异步功能可以实现高性能；换句话说，执行解耦，并行异步操作的能力超过了对消息进行排队和出队的成本。

可扩展性

1. 评分：高
2. 解释：通过高度独立和解耦的事件处理器，自然可以在这种模式下实现可伸缩性。每个事件处理器可以分别缩放，以实现细粒度的可伸缩性。

易于开发

1. 评分：低
2. 解释：由于模式的异步特性以及合同创建，并且对于无响应的事件处理器和失败的代理程序，在代码内需要更高级的错误处理条件，因此开发可能会有些复杂。

微内核架构

基本描述

微内核架构模式（有时称为插件架构模式）是用于实现基于产品的应用程序的自然模式。基于产品的应用程序是一种打包的应用程序，可以作为典型的第三方产品的版本进行下载。但是，许多公司还开发和发布其内部业务应用程序，例如软件产品，版本，发行说明和可插入功能。这些也很适合这种模式。使用微内核架构模式，您可以将其他应用程序功能作为插件添加到核心应用程序，从而提供可扩展性以及功能分离和隔离。

关键概念

微内核架构模式包括两种类型的架构组件：核心系统和插件模块。微内核架构模式的核心系统通常只包含使系统正常运行所需的最小功能。插件模块是独立的独立组件，包含专门的处理，附加功能和自定义代码，旨在增强或扩展核心系统以产生更多的业务功能。

总结

整体敏捷度

1. 评分：高
2. 解释：总体敏捷性是指对不断变化的环境做出快速响应的能力。通过松散耦合的插件模块，可以很大程度上隔离和快速实现更改。通常，大多数微内核架构的核心系统都趋于快速稳定，因此相当强大，并且随着时间的推移几乎不需要更改。

易于部署

1. 评分：高
2. 解释：根据实施方式的不同，可以在运行时（例如，热部署）将插件模块动态添加到核心系统，从而最大程度地减少部署期间的停机时间。

可测试性

1. 评分：高
2. 解释：插件模块可以单独进行测试，并且可以由核心系统轻松模拟，以演示或原型化特定功能，而对核心系统的更改很少或没有更改。

性能

1. 评分：高
2. 解释：尽管微内核模式无法自然地适合高性能应用程序，但通常来说，使用微内核架构模式构建的大多数应用程序都表现良好，因为您可以自定义和简化应用程序以仅包含所需的那些功能。JBoss应用服务器就是一个很好的例子：借助其插件体系结构，您可以将应用服务器缩减为仅需要的那些功能，删除昂贵的未使用功能，例如远程访问，消息传递和消耗内存，CPU和线程并降低应用服务器的速度的缓存。

可扩展性

1. 评分：低
2. 解释：因为大多数微内核架构实现都是基于产品的，并且通常尺寸较小，所以它们被实现为单个单元，因此无法高度扩展。根据实现插件模块的方式，有时可以在插件功能级别提供可伸缩性，但是总的来说，这种模式不以构建高度可扩展的应用程序而闻名。

易于开发

1. 评分：低
2. 解释：微内核体系结构需要周到的设计和合同管理，使其实施起来相当复杂。合同版本控制，内部插件注册表，插件粒度以及可用于插件连接的广泛选择，都增加了实现此模式所涉及的复杂性。

微服务架构

基本描述

微服务体系结构的每个组件都作为一个独立的单元进行部署，从而可以通过有效且简化的交付管道，更强的可伸缩性以及应用程序内部高度的应用程序和组件去耦来简化部署。

关键概念

设计正确级别的服务组件粒度是微服务体系结构中的最大挑战之一。微服务架构模式中的另一个关键概念是分布式架构，这意味着架构中的所有组件都完全相互分离，并可以通过某种远程访问协议（例如JMS，AMQP，REST，SOAP，RMI等）。

基于 REST的API拓扑

基于REST的应用程序拓扑（服务组件粒度更大）

集中式消息传递拓扑

避免依赖和编排

1. 如果发现需要从应用程序的用户界面或API层内部编排服务组件，则可能是服务组件的粒度太细。
2. 同样，如果发现需要在服务组件之间执行服务间通信以处理单个请求，则从业务功能的角度来看，服务组件的粒度可能太细或分配不正确。

总结

整体敏捷度

1. 评分：高
2. 解释：总体敏捷性是指对不断变化的环境做出快速响应的能力。由于是分开部署的单元的概念，通常将更改隔离到单个服务组件中，从而可以快速轻松地进行部署。同样，使用此模式构建的应用程序往往非常松散地耦合在一起，这也有助于促进更改。

易于部署

1. 评分：高
2. 解释：由于远程服务的细粒度和独立性，微服务模式的部署特性非常高。服务通常作为独立的软件单元进行部署，从而能够在白天或晚上的任何时间进行“热部署”。总体部署风险也大大降低了，因为失败的部署可以更快地恢复，并且只影响正在部署的服务上的操作，从而导致所有其他操作的持续操作。

可测试性

1. 评分：高
2. 解释：由于将业务功能分离和隔离到独立的应用程序中，因此可以对测试进行范围划分，从而可以进行更有针对性的测试工作。与针对整个整体应用程序的回归测试相比，针对特定服务组件的回归测试要容易得多，也更可行。而且，由于这种模式中的服务组件是松散耦合的，因此从开发的角度来看，进行更改的可能性较小，这会破坏应用程序的另一部分，从而减轻了必须测试整个应用程序的测试负担。一个小的变化。

性能

1. 评分：低
2. 解释：尽管您可以创建通过这种模式实现的性能很好的应用程序，但是由于微服务体系结构模式的分布式性质，因此总体而言，此模式自然不会适合高性能应用程序

可扩展性

1. 评分：高
2. 解释：由于将应用程序拆分为单独部署的单元，因此可以单独缩放每个服务组件，从而可以对应用程序进行微调。例如，由于该功能的用户量低，股票交易应用程序的管理区域可能不需要扩展，但是由于大多数交易应用程序为此需要的高吞吐量，因此交易扩展服务组件可能需要扩展功能。

易于开发

1. 评分：高
2. 解释：由于功能被隔离在单独且不同的服务组件中，因此由于范围更小且隔离，开发变得更加容易。开发人员对一个服务组件进行更改而影响其他服务组件的机会要少得多，从而减少了开发人员或开发团队之间所需的协调。

基于空间的架构

基本描述

基于空间的体系结构模式专门设计用于解决和解决可伸缩性和并发性问题。对于具有可变且不可预测的并发用户数量的应用程序，这也是一种有用的架构模式。从结构上解决极端和可变的可伸缩性问题通常是比尝试扩展数据库或将缓存技术改造为不可扩展的体系结构更好的方法。通过消除中央数据库约束并使用复制的内存中数据网格来实现高可伸缩性。应用程序数据将保留在内存中，并在所有活动处理单元之间复制。随着用户负载的增加和减少，处理单元可以动态启动和关闭，从而解决了可变的可扩展性。因为没有中央数据库，所以消除了数据库瓶颈，在应用程序内提供了几乎无限的可伸缩性。

关键概念

该体系结构模式中有两个主要组件：处理单元和虚拟化中间件。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-94UcXGD1-1594033180245)(基于空间的架构.png)]

总结

整体敏捷度

1. 评分：高
2. 解释：总体敏捷性是指对不断变化的环境做出快速响应的能力。因为可以快速启动和关闭处理单元（应用程序的部署实例），所以应用程序对与用户负载增加或减少有关的更改（环境更改）反应良好。使用这种模式创建的体系结构通常会因小应用程序大小和模式的动态性质而对编码更改做出很好的响应。

易于部署

1. 评分：高
2. 解释：尽管基于空间的体系结构通常不分离和分布，但是它们是动态的，并且基于云的复杂工具允许将应用程序轻松地“推送”到服务器上，从而简化了部署。

可测试性

1. 评分：低
2. 解释：在测试环境中实现非常高的用户负载既昂贵又耗时，从而难以测试应用程序的可伸缩性方面。

性能

1. 评分：高
2. 解释：通过内存中的数据访问和此模式中内置的缓存机制，可以实现高性能。

可扩展性

1. 评分：高
2. 解释：高可伸缩性来自于对集中式数据库的依赖很小或根本没有依赖性的事实，因此从本质上消除了可伸缩性方程式中的这一限制瓶颈。

易于开发

1. 评分：低
2. 解释：复杂的缓存和内存中的数据网格产品使这种模式的开发相对复杂，这主要是由于对创建这种类型的体系结构所使用的工具和产品缺乏了解。此外，在开发这些类型的体系结构时必须格外小心，以确保源代码中的任何内容都不会影响性能和可伸缩性。

五种架构对比

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qa4uYFhg-1594033180246)(五种架构对比.png)]