什么是 SOA？面向服务 Archi建筑原理
伊利亚·霍尔
⚡ 智能摘要
面向服务 Archi架构原则定义了独立软件服务如何通过标准化通信进行通信。trac构建模块化、可重用且可互操作的应用程序。本教程解释了面向服务的架构 (SOA) 的基本原理、九大核心设计原则、关键组件、优势，以及 SOA 与现代微服务架构的区别。
什么是 SOA（面向服务 Archi结构（tecture）？
面向服务的 Archi架构（SOA） 面向服务是一种计算机软件设计架构模式，其中应用程序组件通过通信协议（通常是通过网络）向其他组件提供服务。面向服务的原则独立于任何产品、供应商或技术。
SOA 使跨不同网络运行的软件组件能够更轻松地相互协作。它促进了业务逻辑的重用，并鼓励分布式系统之间进行标准化通信。
基于面向服务的架构 (SOA) 构建的 Web 服务往往更加独立。这些 Web 服务可以彼此交换数据，并且由于其底层原理，无需任何人工干预或代码修改。这确保了网络上的 Web 服务能够顺畅地相互交互，即使它们采用不同的技术或由不同的团队开发。
现代企业采用面向服务的架构 (SOA) 将传统系统、云应用和第三方 API 整合到一个统一的数字化生态系统中。这种结构化方法降低了集成复杂性，并支持软件的长期演进。
面向服务 Archi架构（SOA）原则
SOA设计共有九项核心原则，具体如下。这些原则指导开发人员在任何基于SOA的应用程序中设计可靠、可重用和可互操作的服务。
1. 标准化服务合同tract
服务必须遵循服务描述。服务必须有某种形式的描述，清晰地定义其功能。这使得客户端应用程序更容易理解服务提供的功能以及如何与之交互。
2.松耦合
Less 彼此依赖。这是 Web 服务的主要特性之一，它指出 Web 服务与其调用客户端之间的依赖性应尽可能低。因此，即使服务功能在任何时候发生变化，也不应该破坏客户端应用程序或使其停止运行。
3. 服务绝对值tracTION
服务会将封装的逻辑对外部世界隐藏起来。服务不应该暴露其功能的执行方式；它应该只告诉客户端应用程序它做了什么，而不是它是如何做的。
4.服务可重用性
逻辑被拆分成多个服务，旨在最大限度地提高代码重用性。在任何开发公司，代码重用性都是一个重要议题，因为企业不希望在多个应用程序中反复编写相同的代码。因此，一旦编写完成，Web 服务的代码就应该能够与各种类型的应用程序兼容。
5. 服务自主性
服务应该对其封装的逻辑拥有控制权。服务了解其提供的所有功能，因此也应该对其包含的代码拥有完全的控制权。
6. 服务无状态
理想情况下，服务应该是无状态的。这意味着服务不应该将信息从一个状态传递到另一个状态。这是客户端应用程序的责任。例如，考虑在商店下的一个订单。ping 网站。网络服务可能会返回特定商品的价格，但如果将商品添加到商店中，则价格可能会发生变化。ping 当购物车页面跳转到支付页面时，将价格信息传递到支付页面的责任不应由Web服务承担，而应由Web应用程序处理。
7. 服务可发现性
服务通常可以通过服务注册中心被发现。我们已经在UDDI的概念中看到了这一点，UDDI充当注册中心的角色，存储有关Web服务的信息，使用户能够轻松找到并使用该服务。
8.服务可组合性
服务将大问题分解成小问题。绝不应该将应用程序的所有功能都嵌入到一个服务中，而应该将服务拆分成多个模块，每个模块负责一项独立的业务功能。
9.服务互操作性
服务应采用允许不同用户群体使用的标准。在网络服务中，诸如以下标准： XML 通过 HTTP 进行通信，以确保服务在不同平台和语言中都符合这一原则。
面向服务的关键组成部分 Archi质地
SOA 生态系统通过几个主要角色协同工作，实现流畅的服务交互。理解这些组件有助于初学者形象地理解分布式系统中服务之间的通信方式。
- 服务提供商： 创建 Web 服务并将其描述发布到服务注册中心，以便消费者以后可以找到它。
- 服务消费者（请求者）： 通过注册表查找所需服务并调用它以使用其提供的功能。
- 服务注册中心（代理）： 充当目录，存储有关可用服务的信息，使消费者能够发现并联系服务提供商。
- 服务中心tract: 定义提供者和消费者之间的通信规则、消息格式和预期行为。
- 企业服务总线 (ESB)： 处理大型企业系统中服务之间的消息路由、转换和集成。
这些组件共同构成了一个模块化框架，支持跨部门、应用程序和云环境的灵活服务重用。
服务导向的优势 Archi质地
面向服务 Archi架构为构建可扩展、适应性强的数字系统的企业提供了战略优势。它将开发工作从编写重复性代码转变为构建模块化服务，从而高效地解决业务问题。
以下优势解释了为什么 SOA 对于现代应用程序设计、云集成和传统系统现代化项目仍然具有相关性。
- 更快的发展： 重用现有服务可以减少编码工作量，加快交付速度。
- 提高可维护性： 小型、专注的服务比庞大的代码块更容易更新、调试和增强。
- 平台独立性： 服务通过开放标准进行通信，使 SOA 与任何技术栈兼容。
- 业务敏捷性： 团队可以通过添加或替换服务来快速适应不断变化的需求，而不会中断整个系统。
- 成本效益： 重复使用成熟的服务可以降低长期开发和集成成本。
- 可扩展性： 各项服务可以独立扩展，以满足负载需求。
这些优势使得 SOA 非常适合银行系统、电子商务平台、医疗保健应用程序以及任何需要可重用业务逻辑的环境。
SOA 与微服务：主要区别
微服务架构通常被视为面向服务的架构（SOA）的演进。虽然两种方法都提倡模块化，但它们在范围、通信方式和治理模型方面存在显著差异。
| 方面 | SOA的 | 微服务 |
|---|---|---|
| 服务规模 | 规模更大的企业级服务 | 小型、单一用途的服务 |
| 外场通讯 | SOAP、XML、ESB | REST、JSON、轻量级 API |
| 治理 | 中心化 | 去中心化 |
| 部署 | 通常共享运行时 | 可独立部署 |
| 数据存储 | 共享数据库 | 每项服务专用 |
| 最合适 | 企业整合 | 云原生应用程序 |
选择面向服务的架构 (SOA) 还是微服务取决于组织规模、技术成熟度和集成复杂性。许多企业会将两者结合使用，SOA 用于遗留系统集成，而微服务则用于新的云端功能。
