​ 定义： SOA(Service-Oriented Architecture),面向服务架构，一种企业系统集成的架构

​ 在了解SOA架构前，需要了解一些企业应用发展的历史。在分层架构中，企业应用系统从混沌架构拆分为分为客户端和服务端，并在服务端进一步分成多层架构，如Java EE的N层架构，在这种架构中，单体系统有N层，如Web层，业务逻辑层，数据访问层，JavaEE把业务逻辑层，数据库访问层封装成EJB部署在远程系统上，供其他系统远程调用，这构成了早期基于Java的分布式系统。 随着IT信息化的发展，企业拥有越来越多的系统。这些系统可能使用不同的技术架构，不同的开发与语言和部署方式，当这些系统需要集成在一起时候，EJB方式远程调用不再是解决方案。 如何让这些系统互操作性更强，以及所有的系统提供的服务能有效被IT团队管理？

​ 如今的IT系统很少都单独存在，如何将他们集成在一起，需要一种自上而下的技术架构解决，这就是SOA架构。 下图展示了一个金融公司在未使用SOA前的混乱状况，以客户审批贷款为例子，贷款管理系统可以通过使用EJB调用同样JavaEE技术栈的风险管理系统，如确认客户是否有资格贷款，风险管理系统将使用HTTP调用OA系统，申请一个贷款流程。OA系统此时使用财务系统私有协调用获取客户的财务状况。

上述系统之间直接调用能完成系统之间的集成。但这种集成方式的缺点是

• 提供的API与具体技术和平台相关，缺少跨平台的API调用机制
• 缺乏对提供的API构成的服务的描述，以及缺乏服务发现机制。
• 提供的API构成的服务无法治理,如服务监控，安全，服务降级，服务熔断，导致集成后的系统质量不高，比如可用性和伸缩性

​

企业和IT团队面临当企业有数十个系统时候，成千上百个API调用，如何把这些大量异构系统集成在一起。面向服务的架构是当时首选的解决方案，它定义和发布每个系统所提供的服务，以及这些服务之间的调用通道。它是针对企业系统集成的一种架构，面向服务架构包含了如下组件

• 服务：对其他系统提供的接口，此服务通过WSDL描述和发布。其他系统可以通过SOAP或者REST等协议调用此服务。

• ESB（Enterprise Service Bus ）： 企业服务总线，提供了连接不同服务功能，具备服务注册和查找，消息路由，消息转化，安全管理，审计等功能。下图展示了一个ESB 的功能架构。ESB实际是事件驱动架构的一种具体体现。

• BPEL( Business Process Execution Language) : 可选的，SOA架构会使用BPEL描述企业内部和跨企业的业务流程，它是一种基于 XML 的、面向 Web 服务的业务编排语言。

ESB是SOA架构的核心，它本身是一个事件驱动架构模式，下图展示其技术架构

简单情况下，企业也可以不使用ESB，直接将其API暴漏为WebService，比如使用Apache CXF工具， 通过注解轻松将Java方法变成WebService。

ESB的相关知识，跟上一节介绍的事件驱动架构风格很类似，下表总结了ESB的主要组件。

组件	描述
连接器	用于连接应用程序，数据库，IOT设备，云基础设施等，或者连接知名厂商的ERP，CRM系统
服务注册/查找	各个系统将自己提供的服务提交到服务注册中心，供其他系统调用。SOA架构使用标准的WSDL描述其服务，并注册到注册中心。如今微服务则使用微服务框架特定的协议标准，支持不同的注册中心。如Dubbo支持在服务在Zookeeper上服务注册或者Nacos的注册。
消息通道	服务调用是通过消息通道实现。支持消息的点对点发送和广播发送
消息路由	路由决定了消息如何从一个消息通道转发到其他消息通道。
消息转化	使用可视化或者配置方式，将一种消息格式转化另外一种消息格式，比如把XML转成成字符串
管理功能	提供安全，审计，ESB各个组件配置等功能，也提供消息的管理功能。

支持SOA架构的开源产品有Spring Itegration ，Apache Camel，ESB Mule等，最主要支持的是IBM 和Oracle这样的大厂商，他们提供了SOA商业解决方案和产品，也是SOA主要的推动者

可以阅读上一节的事件驱动架构风格了解ESB功能特性

所有的ESB平台或者企业集成框架参考了《Enterprise Integration Patterns》一书提到的企业系统集成理论和模式，建议读者可以在了解ESB产品前可以先阅读此书。

在上诉金融企业系统更换成SOA架构，拓扑图更换如下，系统之间通过ESB交互，各个系统通过ESB发布自己的服务，ESB提供服务适配，系统需要改动较少就能互相操作。

​

需要注意，SOA架构在实际应用时候，有如下缺点

• SOA架构要求服务注册到注册中心后调用，如果需是集成较少的系统，或者只是个单体系统应用，根本没有系统集成需求。这采用SOA架构显得没有必要。
• 性能瓶颈：ESB承担了系统之间消息的传递，路由和转化，可能在是企业系统的性能瓶颈。作者曾在2007年参加中国电信的下一代电信3G方案验证，在使用用厂商的ESB系统验证集成电信各个核心系统，如计费，CRM，充值系统等，由于这些系统的交互消息量非常庞大，ESB成为了性能瓶颈。同样在2010年为中国移动做各省BBoss系统集成也曾经采用大厂商的ESB作为实现方案之一，同样也出现了性能瓶颈。 如今ESB厂商声称其性能达到每秒支持数百万消息，因此在使用基于ESB的SOA，需要技术架构师需要首先考虑ESB性能
• 上线周期较长：系统集成通常需要ESB系统参与而不是系统之间直接调用，其开发，调试，部署耗时较多

这三个缺点使得SOA架构适合大型企业的松散IT系统集成架构，如金融，电信等。微服务架构衍生的集成技术更适小型系统，或者电商、物联网的内部子系统的集成。至于ERP那种生产和财务结合很紧密的系统，不适合SOA架构。