SOA 和微服务有什么区别？
服务导向型架构（SOA）是一种软件开发方法，它使用称为服务的软件组件来创建业务应用程序。每项服务都提供业务功能。而且，它们还可以跨平台和语言彼此通信。开发人员使用 SOA 来重用不同系统中的服务，或者组合几个独立的服务来执行复杂的任务。微服务架构是由 SOA 架构风格演变而来的。虽然每个 SOA 服务都是一个完整的业务功能，但是每个微服务都是一个更小的软件组件，只专注于一项任务。微服务解决了 SOA 的缺陷问题，使软件与基于云的现代企业环境更加兼容。
SOA 架构解决了整体式架构的哪些局限性？
在整体式架构中，开发人员在单个代码库中为所有服务函数编写代码。借助服务导向型架构（SOA），开发人员可以应对整体式架构的挑战，例如：
- 即使只有特定组件需要额外资源，也需要对整个应用程序进行扩展的扩展挑战。
- 由于功能分布在代码库中，因此无法灵活地添加或修改功能。
- 无法在不同的应用程序中重复使用组件。
- 容错能力有限。一个组件出现故障可能会使整个系统停机。
- 采用新技术或与使用不同技术的外部系统集成的挑战。
整体式架构还集中了负责整个应用程序的所有权和开发团队。由于架构的规模和复杂性，他们在持续交付和 DevOps 实践方面面临挑战。
借助 SOA，开发人员可以将软件功能分解到服务提供商层和服务消费者层。这些层通过企业服务总线（ESB）进行通信和交换数据。开发人员使用 SOA 将复杂的应用程序简化为多个可重复使用的服务。
微服务架构解决了 SOA 架构的哪些局限性？
尽管服务导向型架构（SOA）可能很适合用于构建大型企业应用程序，但它需要更大的灵活性来扩展较小的业务特定应用程序。以下是 SOA 的一些限制：
- 企业服务总线（ESB）将多个服务连接在一起，这使其成为单一故障点。
- 所有服务共享一个公用数据存储库。这使得服务难以单独管理。
- 每项服务的范围都很广。因此，如果其中一项服务出现故障，整个业务工作流程都将受到影响。
因此，开发人员转向微服务架构，寻求更精细的方法来构建应用程序。
微服务模型将 SOA 服务划分为较小的服务。每个微服务都在其有限的上下文中运行，并且独立于其他服务运行。简而言之，微服务架构各个服务之间的相互依赖性有限或根本没有相互依赖性，可以降低系统范围内故障的风险。
架构差异：SOA 与微服务
服务导向型架构（SOA）涵盖更广泛的企业适用范围。不同的业务部门在通用数据共享平台上高效协作。相比之下，微服务的适用范围较窄。
例如，库存管理将是电子商务系统的 SOA 服务。但是微服务方法会将库存管理分解为较小的服务，例如可用性检查器、配送和会计。
实施
SOA 的实施涉及将不同类型的服务集成到应用程序中。它使用企业服务总线来连接服务类型，如下所示：
- 支持特定业务运维的功能性服务
- 向其他服务公开特定业务功能的企业服务
- 开发人员用于构建和部署应用程序的应用程序服务
- 用于管理身份验证和安全等非功能功能的基础设施服务
相比之下，微服务架构是更精细和独立的 SOA 实施。微服务不像 SOA 服务那样共享资源。每个微服务都独立运行，以提供非常具体的功能。
交流
为了访问远程服务，SOA 架构使用集中式企业服务总线（ESB）将各种服务与多个消息传递协议连接起来。其中一些协议包括 SOAP、高级消息队列协议（AMQP）和微软消息队列（MSMQ）。如果 ESB 出现故障，所有 SOA 服务都将受到影响。
同时，微服务架构使用更简单的消息传递系统，例如 RESTful API、Java Message Service（JMS）或发布-订阅（pub/sub）事件流。这些方法不需要微服务在交换数据时保持活动连接。
API 是微服务架构的常用工具。API 允许两个或多个微服务直接交换数据，而无需通过集中渠道。但是，它可以在数十种微服务之间创建复杂的数据路径，开发人员可以对其进行监控和管理。
数据存储
SOA 环境包括由其他连接的服务共享的单个数据存储层。不同的企业应用程序在 SOA 实施中访问和重复使用相同的数据，从而优化了数据存储库的价值。
相比之下，每个微服务都有自己的数据存储空间。在微服务架构中，数据独立性比可重用性更重要。
部署
部署 SOA 服务可能具有挑战性，因为它们在一定程度上是耦合的。例如，如果开发人员修改或添加新服务，则必须重建整个应用程序。此外，SOA 应用程序无法充分利用容器化，容器化可将应用程序从操作系统和硬件中抽象出来。
同时，微服务更易于部署，因为它们专为在云环境中扩展而设计。每个微服务都是一个独立的应用程序，开发人员可以将其容器化并在云端部署。
主要优势：微服务与SOA
服务导向型架构（SOA）和微服务都允许开发团队高效地为云环境构建、部署和管理现代应用程序。也就是说，与 SOA 部署相比，微服务具有某些优势。
可重用性
SOA 设计的原则之一是强调可重用性和组件共享。在此架构中，多个前端应用程序使用相同的 SOA 服务。例如，发票开具和订单跟踪控制面板可以访问相同的服务来检索客户详细信息。
另一方面，微服务采用不同的方法。它们应用数据复制而不是共享公共资源。这样，基于微服务的应用程序可以更高效地运行，并且不局限于其他服务的数据操作。
速度
SOA 可能可以在在简单的实施中提供不错的速度，但是随着开发人员向系统添加更多服务，数据延迟会增加。所有服务都争夺相同的通信资源和数据能力。
相比之下，微服务架构可以在系统扩展时保持敏捷性和响应能力，因为它们不共享重叠的资源。如果流量需求增加，开发人员可以为特定的微服务分配和增加计算资源。这使基于微服务的应用程序能够始终以可接受的速度运行。
治理灵活性
基于 SOA 的应用程序可为不同服务使用的常见存储库提供一致的数据治理。
但是，使用微服务的开发人员可以为独立的数据存储单元决定不同的治理策略。开发团队可以更高效地协作，并且可以自由确定数据治理机制。
何时使用：SOA 与微服务
服务导向型架构（SOA）和微服务为组织提供了从单一架构迁移到云环境的不同方式。根据某些因素，在实际应用场景中，其中一种架构可能会更合适。
SOA
拥有传统或独立企业应用程序的组织可以从 SOA 架构中受益。SOA 将传统软件程序简化为较小的模块化部件。它还汇集了共享资源以简化业务功能。开发人员可以重复使用现有的 SOA 服务来实施更多业务解决方案，而不需要构建重叠和冗余的服务。
微服务
微服务架构能更好地支持敏捷开发团队。通过使用持续集成和持续交付（CI/CD）工具，开发人员可以在不影响应用程序稳定性的情况下进行快速增量代码更改。当开发人员有以下目标时，微服务更适用：
- 使用不同的编程语言、库或框架来构建单个应用程序
- 结合使用不同软件框架构建的各项服务
- 预调配计算资源并实时扩展单个服务
借助微服务，公司可以从现代云功能中受益，并轻松部署数百个微服务。
差异摘要：SOA 与微服务
| SOA |
微服务 |
|
| 实施 |
共享资源的不同服务。 |
独立且针对特定用途的小型服务。 |
| 交流 |
ESB 使用多种消息协议，例如 SOAP、AMQP 和 MSMQ。 |
API、Java 消息服务、发布/订阅 |
| 数据存储 |
共享数据存储。 |
独立的数据存储。 |
| 部署 |
具有挑战性。细微更改也需要全面重构。 |
易于部署。每个微服务都可以容器化。 |
| 可重用性 |
通过共享公共资源提供可重复使用的服务。 |
每项服务都有自己的独立资源。您可以通过微服务的 API 重复使用微服务。 |
| 速度 |
速度会随着服务增多而减慢。 |
可在流量增长时保持稳定的速度。 |
| 治理灵活性 |
跨所有服务进行一致的数据治理。 |
针对每种存储采用不同的数据治理策略。 |
AWS 如何帮助满足您的微服务需求？
使用模块化架构模式、无服务器运行模式和敏捷开发流程，在 Amazon Web Services（AWS）上构建现代应用程序。我们为构建高度可用的微服务提供了最完整的平台，可以支持任何范围和规模的现代应用程序。
您可以通过以下方式在 AWS 上使用微服务：
- 在托管容器中构建、隔离和运行安全的微服务，以简化操作并减少管理开销。在 AWS 上的容器中阅读更多内容。
- 使用 AWS Lambda，无需配置和管理服务器即可运行您的微服务。
- 从 15 个专门构建的关系和非关系 AWS Cloud 数据库中选择，为微服务架构提供支持。
- AWS App Mesh 使您可以轻松监控和控制在 AWS 上运行的微服务。
- AWS X-Ray 使您可以监控复杂的微服务交互并对其进行故障排除。
AWS 上的微服务使您能够更快地创新、降低风险、加快上市时间，并降低总体拥有成本。立即创建账户，开始在 AWS 上使用微服务。
