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

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

此接口是 服务供应商 和 服务使用者之间的 服务合同 。  服务接口 背后的应用程序可在 Microsoft 中以  Java  编写。 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  分解为更细粒度的分散式集成。 这是 敏捷集成背后的主要前提之一。

随着贵公司将 IT 基础架构转向 混合云 方法，您很有可能会将各种工作负载（包括基于 SOA 的工作负载）转换为更轻便、更灵活的云部署模型。

这些转换只是 应用现代化 的一部分，其目的是改进客户体验，还有更多应用会影响您的业务和 IT 运营。 为了满足这些需求， 进一步 提高自动化水平也会有所助益。 理想情况下，将从相当成功的小型 项目  开始 ，然后针对其他流程和组织的其他部门进行 扩展和优化。 

通过与 IBM 合作，您可以访问 AI 驱动的自动化功能，包括预先构建的工作流，帮助您通过提高每个流程的智能化水平来加速创新。

采取下一步行动：

• 通过  IBM Cloud Pak for Integration 打开了与客户、供应商和合作伙伴的全新互动通道，这是一个混合集成解决方案，可跨多种样式的企业集成提供自动化和闭环生命周期。
• 要了解如何跨多个 私有 和 公有 云连接您的所有应用程序和数据，以创建个性化的客户体验，请访问  IBM 云集成。
• 下载  IBM 应用现代化领域指南 ，了解如何加速现代化、改善开发人员的生产能力，并提高操作效率和标准化。
• 执行  集成成熟度评估 ，以评估 您的 跨关键维度的集成成熟度，并发现 您 可以采取哪些措施以达到更高的成熟度。 
• 下载我们的 敏捷集成指南  (PDF, 206 KB)，此指南将 探讨基于容器且与微服务一致的分散式解决方案集成方法的优点。  
• 阅读 HFS Research 报告，了解 成功自动化项目的五项"必备条件"  （链接位于 ibm.com 之外）。

立即开始通过  IBM Cloud 帐户 使用该产品。