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 以及最近的微服务架构会共用许多词汇（如“服务”和“架构”），但它们仅松散相关，且事实上在不同的范围运行。

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

• 业务灵活性更高；上市速度更快：可复用性是关键。    从可复用服务（即构建块）高效组装应用， 而不必对每个新开发项目进行重写和重新集成，让开发人员能够更快构建应用，从而把握更多新的商机。 面向服务的架构方法支持应用集成、数据集成和服务编排一类的业务流程或工作流程自动化场景。       这让开发人员在集成方面花费的时间明显减少，而更多地专注于交付和改进应用，从而加速了软件设计和软件开发。       

• 能够在新市场中利用原有功能：通过精心设计的 SOA，开发人员可以轻松地将功能“锁定”在一个计算平台或环境中，并将其扩展到新的环境和市场。       例如，许多公司都使用了 SOA 将基于大型机的财务系统中的功能向新的 Web 应用公开，从而让客户能够自行了解先前只能通过与公司员工或业务合作伙伴直接互动才能访问的流程和信息。   

• 改善业务与 IT 之间的协作：在 SOA 中，可以用业务术语（例如，“生成保险报价”或“计算资本设备投资回报率”）来定义服务。 这样，业务分析人员就可以在重要洞察（例如，使用服务定义的业务流程的范围或者更改流程对业务的影响）方面与开发人员更有效地合作，从而获得更好的成果。

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

1. Delaware Electric 公司通过转为使用 SOA 集成以前彼此不通信的系统提高了开发效率，在国家规定的五年电费冻结期内帮助该公司保持了偿付能力。

2. Cisco 公司采用了 SOA，通过将订购流程作为服务（可供 Cisco 的部门、并购的公司和业务合作伙伴整合到其网站中）公开，确保其产品订购体验在所有产品和渠道之间保持一致。   

3. 费城的 Independence Blue Cross (IBC) 公司实施了 SOA，从而确保了处理患者数据的各方（IBC 客户服务代理、医师办公室、IBC 网站用户）使用的是相同的数据源（“单一真相来源”）。

SOA 与微服务的主要区别在于组件的耦合和使用范围：

• SOA 是一种集成架构样式，也是一个企业级概念。   凭借 SOA，可以通过松散耦合的接口公开现有应用，每个接口对应于一个业务功能，从而使扩展企业某个部分中的应用可以复用其他应用中的功能。   

• 微服务架构是一种应用架构样式，也是一个应用级概念。     凭借微服务架构，可以将单个应用的内部结构分解成若干个可单独更改、缩放和管理的小块。 由于它没有定义应用的通信方式，因此我们还是改为使用 SOA 提供的企业范围的服务接口。 

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

• 开发人员敏捷性和工作效率：微服务支持开发人员将新技术整合到应用的一个部分，且不会影响应用的其他部分。   任何组件都可以独立于其他组件进行修改、测试和部署，从而缩短了迭代周期。

• 可伸缩性：微服务可以最大程度地利用云可伸缩性的优势 - 任何组件都可以独立于其他组件进行扩展，以最快的速度响应工作负载需求并最有效地利用计算资源。   

• 安全永续性：由于微服务的去耦特性，一个微服务的故障并不会影响其他微服务。    每个微服务都可以达到自己的可用性要求，而无需让其他组件或整个应用达到最高的通用

ESB

ESB 是  SOA（ 面向服务的架构）的基本组件，它是 二十世纪九十年代后期出现的架构。 SOA  定义了通过服务接口来复用软件组件的方法。 此类服务通常会使用标准接口（即 Web Service），能够快速合并到新应用程序中，而不必复制服务在新应用程序中执行的 功能 。

 SOA 中的每项服务都包含执行完整的独立业务功能（例如，检查客户信用、计算每月还贷额或处理抵押申请）所需的代码和 数据 。 服务接口可提供松散耦合，这意味着即便对底层的服务 实施方式知之甚少或根本不了解，也可以调用这些服务，减少了应用程序之间的依赖性。 服务接口背后的应用程序可在 Microsoft 中以 Java 编写 。Net、Cobol 或任何其他编程语言，由供应商（如  SAP）作为打包软件应用提供，作为 SaaS 应用（如 Salesforce  CRM）提供，或作为 开源 应用获取。  

服务接口经常使用 Web 服务 定义语言 (WSDL) 定义，这是基于 xml （可扩展标记语言）的一种标准标记结构。  使用 SOAP（简单对象访问协议）/HTTP 或 JSON/HTTP 等标准 网络 协议来公开服务，以便发送有关读取或更改数据的请求。 服务管制控制开发生命周期，且服务将在相应的阶段发布在 注册表中，以便于开发人员快速查找并复用服务来组装新的应用程序或 业务流程。

这些服务可从头开始构建，但通常是通过将 原有记录系统 的功能公开为服务接口来创建。 企业可在 原有系统之前提供基于服务接口的标准，可以使用 ESB 通过 适配器 或 连接器直接连接到 原有系统 ，或者应用程序提供自己的 API。 在任何情况下，  企业服务总线 都会将新应用程序与原有接口隔离开来。  ESB 执行必要的转换和 路由 ，以连接到 原有系统 服务。

可以在没有 ESB 架构的情况下实施 SOA ，但这样便等同于仅拥有一系列服务。 每个应用程序所有者都需要直接连接到所需的服务，并执行必要的 数据转换 以满足每个服务接口。 即便接口可复用，这一工作量也非常大，且因为每个连接都是点对点连接，未来的维护也会困难重重。