微服务与其他三种软件架构的优缺点
空心菜
读完需要
8
分钟
速读仅需 3 分钟
当你开始构建一流的 Web 软件应用程序的时候，当你拥有适当的敏捷方法的时候，开发团队可以开始布局软件体系架构。
这将是开发过程中要克服的第一个障碍。使软件设计过于严格会与敏捷软件开发方法冲突，并会导致过多的 Big Design Up Front ( https://en.wikipedia.org/wiki/Big_Design_Up_Front )。使设计过于宽松或无法完全实现设计的边界会使开发人员感到困惑。在此博客文章中，我们将更深入地研究四种软件架构，并讨论其优缺点，最佳用例。
有时，可以将多个体系结构和模式组合到一个系统中，并且将完美的设计融入您的解决方案中通常感觉就像是一门艺术。可以查看更多关于构建模块化整体的文章 ( https://www.foreach.be/blog/building-a-modular-monolith-with-spring-boot-and-across )，以深入了解这种混合系统。
1
分层架构
这可能是最常用的体系结构，因为它以数据源为中心。许多业务应用程序无非是一种操纵表中存储的数据的方法，而表之间存在一些业务逻辑。
代码的排列方式使数据或输入进入顶层，并沿每一层向下移动，直到到达底层为止。每个层都有自己的任务和责任，程序员可以同时在不同的层上工作。
例如，三层体系结构通常用于 Web 应用程序的开发中。
这种体系结构的优点是:
- 易学且非常一致;
- 明确分离关注点,每层负责一个明确的任务;
- 由于关注点的分离，易于测试：每个层都是可测试的，可维护的并且易于更新。
这种体系结构的缺点是:
- 如果没有组织，源代码可能会变得臃肿;
- 需要跳过某些层并造成逻辑混乱时，需要“快速修复”时产生紧密耦合的风险;
- 大多数用于单片应用程序，因此即使很小的更改也需要完全重新部署。
当需要在短时间内构建应用程序，很少有复杂的业务场景或与初级开发团队合作时，应考虑使用此体系结构。
2
微服务架构
当软件程序增长并在顶部添加新功能时，就有可能成为僵化的，庞大的巨人。微服务体系结构旨在帮助开发人员解决此问题。创建多个不同的较小的程序，而不是构建单个程序，每个程序都有自己的目标。每当请求新功能时，都会创建一个新程序。
每个微服务都是一项独立的应用程序服务，提供一项自包含的功能，并通过 REST，HTTP 等轻量级消息传递协议相互通信。
微服务只有在不违反其 API 协议的情况下才能独立于其他微服务发展。如果您更改协议，它将影响所有其他连接的微服务或 API 网关。需要以新旧版本的微服务协议同时运行的方式增量部署微服务的新版本。因此，为服务版本制定一个好的策略很重要。
Netflix 是微服务架构的最早采用者之一。当您打开 Netflix 主页时，将从其他服务中检索所有信息。为了说明这一点，您的收藏夹列表是从与您的帐户信息不同的服务中检索到的。
这种体系架构的优点是:
- 没有供应商或技术锁定：每个微服务都可以拥有自己的技术栈，或者可以作为测试新技术的场所;
- 微服务很小，因此更易于测试，部署，维护和扩展。例如，如果您要在网站上启动促销活动，则可以仅扩大订购服务的规模;
- 围绕多个团队组织开发。每个小型团队负责一个或多个微服务。每个团队可以独立于其他团队的服务来部署和扩展其服务。
该体系架构的缺点是:
- 分布式系统的开发可能很复杂：一切都是单独的服务，你需要非常仔细地处理从服务到服务的请求。应包括额外的验证和错误处理，以避免中断和超时，
- 使用多个数据库带来的事务管理的复杂性。当请求在一项服务中成功但在另一项服务中失败时，您应该回滚数据库更改吗？
- 尽管分别测试服务很容易，但是对所有应用程序进行集成测试可能很困难，因为所有服务都应运行并需要自己的测试数据集。
当应用程序或应用程序的一部分应易于扩展或缩小时，建议将这种体系结构用于具有许多小的单独组件的应用程序。当与分布在不同位置或时区的几个开发团队合作时，微服务架构也可以成为福音。
3
面向服务的架构
面向服务的体系结构，通常简称为 SOA，是一种基于业务服务的体系结构。服务是定义明确且自包含的。服务是松散耦合的，并且彼此通信以执行活动。基本上，它由服务使用者和服务提供者组成：服务使用者请求服务，而提供者执行服务并返回请求的结果。提供者和消费者都同意预定义的消息传递协议。
企业服务总线（ESB）实现了不同软件应用程序之间的通信系统。ESB 将消息转换为正确的消息类型，然后将消息发送到正确的消费者服务。
乍一看，看起来微服务架构和面向服务的架构非常相似，但是如果仔细研究，它们在服务特性方面会有很大差异。
- 服务粒度，微服务体系结构中的组件集中于一个目的，并且确实做到了这一点。在面向服务的体系结构中，组件的大小范围可以从小型应用程序到整个企业应用程序;
- 中间件与 API：微服务使用 API 层和简单的消息传递协议进行通信，而 SOA 具有具有额外功能的消息传递中间件组件;
- SOA 体系结构依赖于多个组件来处理业务请求，而微服务体系结构则试图将其最小化。微服务是应满足唯一目的的独立应用程序，SOA 依靠多种服务来按设计完成请求。
SOA 的优点是：
- 服务可重用性：通过组合松散耦合的功能来构建应用程序。可以在多个应用程序中重用服务，而无需与其他服务进行交互;
- 可用性和可扩展性：可以产生服务的多个实例;
- 没有技术约束，生产效率更高：开发人员可以重用现有的旧版应用程序，并且可以与平台和技术独立的其他供应商的产品进行连接。
SOA的缺点是:
- 大量的开销：每次服务与另一个服务进行交互时，都会在 ESB 上完成请求和参数的完整转换和验证;
- 该体系结构不适用于不需要消息中间件的小型应用程序。
如果您有大型复杂的企业级系统需要与需要消息中间件的异构应用程序和服务集成，那么我建议使用面向服务的体系结构。该体系结构的另一个重要优点是合同解耦功能。服务和消费者可以分别发展，但仍然保持合同关系；SOA 使数据保持一致。如果您在架构中需要这种抽象级别，则应该考虑使用 SOA 解决方案，而不是微服务架构。
4
事件溯源
事件溯源是一种架构，其中您不存储模型的当前状态，而是存储模型发生的一系列事件。检索模型时，将播放所有存储的事件并重新应用它们。这称为为对象补水。
事件溯源通常与"命令和查询责任隔离 ( https://en.wikipedia.org/wiki/Command%E2%80%93query_separation#Command_query_responsibility_segregation )"模式结合使用，因为为对象补水会对性能产生严重影响。
事件溯源的真实例子是会计。添加费用时，您不会更改总金额的值。而是，在新行中添加值和操作。发生错误时，不应删除事件，因为它们实际上是过去发生的。为了纠正这种情况，应该创建新事件以消除错误事件。
事件溯源的优点是:
- 设计模式提供了开箱即用的完全可靠的审核日志;
- 可以实施查询来确定对象在任何时间点的状态;
- 由于事件是存储的而不是域对象，因此可以避免对象关系阻抗不匹配。
事件溯源的缺点是：
- 具有（陡峭的）学习曲线的不熟悉的编程风格，
- 事件存储并不总是很容易查询，并且可能相当困难或复杂。CQRS 很可能会被使用，这意味着应用程序应该能够处理最终一致的数据。
事件溯源应用于需要大量更改跟踪的应用程序。对于常规业务数据可能会是这种情况，但对于安全性至关重要的数据或敏感数据则更为重要。您需要以所有可能的方式查询统计数据的审计或业务分析应用程序也将从该方法中受益匪浅。
5
结论
为您的业务应用程序选择正确的软件体系结构对于开发人员的成功至关重要。它是沟通的基础，是系统的计划，对于所有利益相关者之间的理解至关重要。
该体系结构定义了软件的模型，其功能以及定义在实现时可能遇到的问题。它使决策和管理各种变更变得更加容易，并且可以更好地估计项目的时间和成本。