主页
topics
什么是 SOA(面向服务的架构)?
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 实施都包含的事实元素,以致于有时将这两个术语作为同义词使用,从而造成了混乱。
与它之前的架构相比,SOA 为企业带来了巨大的好处:
到 2010 年,几乎每个行业的领先公司都已全面实施了 SOA。 例如:
行业专家已发布了大量文章(包括印刷版和数字版)来比较 SOA 与微服务,并定义了这两者之间的微妙关系。 就本文而言,这两者的主要区别在于组件的耦合和使用范围:
伴随虚拟化、云计算、敏捷开发实践和 DevOps 的兴起,微服务架构如雨后春笋般涌现和发展。 在这些情况下,微服务的主要优势来自组件的去耦,因为这可以简化并改善以下方面:
要深入了解 SOA 和微服务之间的差异,请参阅“SAO 与 微服务:有何区别?”
就像微服务架构可以在应用设计中提高敏捷性、可伸缩性和安全永续性一样,这些相同的技术也可以应用于集成。 这一点很重要,因为随着时间的流逝,高度集中的 ESB 模式及其相关的集中式集成专家团队可能会成为瓶颈。 借鉴微服务的原理,我们可以将 ESB 分解为更细粒度的分散式集成。 这是敏捷集成背后的主要前提之一。
将应用、服务和数据连接到市场上最全面的集成平台 IBM Cloud Pak for Integration。
使用功能强大的人工智能自动化应用集成软件来连接应用和数据。
IBM API Connect® 是一个安全的 API 管理解决方案,它利用直观的体验来帮助一致地创建、管理、保护、社会化和货币化 API。