SOA（面向服务的架构）定义了一种可通过服务接口复用软件组件并实现其互操作的方法。     服务使用公共接口标准和架构模式，因此可以快速整合到新应用中。 这让应用开发人员无需像之前那样重新开发或复制现有功能，也不必了解如何连接现有功能或提供与现有功能的互操作性 。

SOA 中的每项服务都包含执行完整的独立业务功能（例如，检查客户信用、计算每月还贷额或处理抵押申请）所需的代码和 数据 。      服务接口可提供松散耦合，这意味着即便对底层的 服务 实施方式知之甚少或根本不了解，也可以调用这些服务，减少了应用之间的依赖性。

此接口是服务供应商和服务使用者之间的服务合同。      服务接口背后的应用可采用  Java、Microsoft  . Net、Cobol 或任何其他编程语言来编写，由供应商（如 SAP）作为打包软件应用提供，作为软件即服务应用（如 Salesforce CRM）提供，或作为开源应用获取。  服务接口经常使用 Web 服务定义语言 (WSDL) 定义，这是基于  xml（可扩展标记语言）的一种标准标记结构。

使用 SOAP（简单对象访问协议）/HTTP 或 Restful HTTP (JSON/HTTP) 等 标准网络 协议来公开服务，以便发送有关读取或更改数据的请求。 服务管制控制开发生命周期，且服务将在相应的阶段发布在 注册表 中，以便于开发人员快速查找并复用服务来组装新的应用或业务流程。

此类服务可从头开始构建，但通常是通过将原有记录系统的功能公开为服务接口来创建。

因此，SOA 代表了过去几十年中应用开发和集成发展的重要阶段。    在 20 世纪 90 年代末 SOA 出现之前，将应用连接到其他系统中包含的数据或功能需要进行复杂的点对点集成 - 开发人员必须为每个新开发项目部分或全部重新创建这种集成。 通过 SOA 服务公开这些功能后，开发人员只需复用现有功能并通过 SOA ESB 架构 进行连接即可（查看下文）。

请注意，尽管 SOA 以及最近的 微服务架构 会共用许多词汇（如“服务”和“架构”），但它们仅松散相关，且事实上在不同的范围运行，本文稍后会加以讨论。

ESB 或企业服务总线是一种架构模式，此处，集中的软件组件会执行应用之间的集成。     它执行数据模型的变换、处理连接/消息传递、执行路由、转换通信协议，且可能会管理多个请求的组合。      ESB 可以将这些集成和转换作为服务接口提供，以供新应用复用。       通常使用专用的集成运行时和工具集来实施 ESB 模式，以确保最佳的生产力。

可以在不实施 ESB 的情况下实施 SOA，但这样便等同于仅拥有一堆服务。    每个应用所有者都需要直接连接到所需的服务，并执行必要的数据转换以满足每个服务接口。  即便接口可复用，这一工作量也非常大，且因为每个连接都是点对点连接，未来的维护也会困难重重。  实际上，ESB 最终被认为是所有 SOA 实施都包含的事实元素，以致于有时将这两个术语作为同义词使用，从而造成了混乱。

阅读有关 ESB 的更多信息

与它之前的架构相比，SOA 为企业带来了巨大的好处：

• 业务灵活性更高；上市速度更快： 可复用性是关键。    从可复用服务（即构建块）高效组装应用， 而不必对每个新开发项目进行重写和重新集成，让开发人员能够更快构建应用，从而把握更多新的商机。 面向服务的架构方法支持应用集成、数据集成和服务编排一类的业务流程或工作流程自动化场景。       这让开发人员在集成方面花费的时间明显减少，而更多地 专注于交付和 改进应用，从而加速了软件设计和软件开发。
  
• 能够在新市场中利用原有功能： 通过精心设计的 SOA，开发人员可以轻松地将功能“锁定”在一个计算平台或环境中，并将其扩展到新的环境和市场。       例如，许多公司都使用了 SOA 将基于大型机的财务系统中的功能向新的 Web 应用公开，从而让客户能够自行了解先前只能通过与公司员工或业务合作伙伴直接互动才能访问的流程和信息。
  
• 改善业务与 IT 之间的协作： 在 SOA 中，可以用业务术语（例如，“生成保险报价”或“计算资本设备投资回报率”）来定义服务。 这样，业务分析人员就可以在重要洞察（例如，使用服务定义的业务流程的范围或者更改流程对业务的影响）方面与开发人员更有效地合作，从而获得更好的成果。

• 到 2010 年，几乎每个行业的领先公司都已全面实施了 SOA。 例如：

  • Delaware Electric 公司通过转为使用 SOA 集成以前彼此不通信的系统提高了开发效率，在国家规定的五年电费冻结期内帮助该公司保持了偿付能力。
    
  • Cisco 公司采用了 SOA，通过将订购流程作为服务（可供 Cisco 的部门、并购的公司和业务合作伙伴整合到其网站中）公开，确保其产品订购体验在所有产品和渠道之间保持一致。
    
  • 费城的 Independence Blue Cross (IBC) 公司实施了 SOA，从而确保了处理患者数据的各方（IBC 客户服务代理、医师办公室、IBC 网站用户）使用的是相同的数据源（“单一真相来源”）。

  行业专家已发布了大量文章（包括印刷版和数字版）来比较 SOA 与 微服务 ，并定义了这两者之间的微妙关系。 就本文而言，这两者的主要区别在于组件的耦合和使用范围：

  • SOA 是一种集成架构样式，也是一个企业级概念。   凭借 SOA，可以通过松散耦合的接口公开现有应用，每个接口对应于一个业务功能，从而使扩展企业某个部分中的应用可以复用其他应用中的功能。
    
  • 微服务架构是一种应用架构样式，也是一个应用级概念。     凭借微服务架构，可以将单个应用的内部结构分解成若干个可单独更改、缩放和管理的小块。 由于它没有定义应用的通信方式，因此我们还是改为使用 SOA 提供的企业范围的服务接口。

  伴随 虚拟化 、 云计算 、敏捷开发实践和 DevOps 的兴起，微服务架构如雨后春笋般涌现和发展。    在这些情况下，微服务的主要优势来自组件的去耦，因为这可以简化并改善以下方面：

  • 开发人员敏捷性和工作效率： 微服务支持开发人员将新技术整合到应用的一个部分，且不会影响应用的其他部分。   任何组件都可以独立于其他组件进行修改、测试和部署，从而缩短了迭代周期。
    
  • 可伸缩性： 微服务可以最大程度地利用云可伸缩性的优势 - 任何组件都可以独立于其他组件进行扩展，以最快的速度响应工作负载需求并最有效地利用计算资源。
    
  • 安全永续性： 由于微服务的去耦特性，一个微服务的故障并不会影响其他微服务。    每个微服务都可以达到自己的可用性要求，而无需让其他组件或整个应用达到最高的通用可用性要求。

  要深入了解 SOA 和微服务之间的差异，请参阅“ SAO 与  微服务：有何区别？ ”

  就像微服务架构可以在应用设计中提高敏捷性、可伸缩性和安全永续性一样，这些相同的技术也可以应用于集成。     这一点很重要，因为随着时间的流逝，高度集中的 ESB 模式及其相关的集中式集成专家团队可能会成为瓶颈。 借鉴微服务的原理，我们可以将 ESB 分解为更细粒度的分散式集成。   这是 敏捷集成 背后的主要前提之一。