银行架构ESB_esb架构

一直以来，我们都知道ESB的最大优势在于SOA理念的落地，这实际上是从企业整体系统架构优化的角度出发，实现系统间的松耦合。即将服务系统的服务发布在ESB上提供给最终用户和其他消费者，也因此ESB被认为是纯粹的、具有通用性的技术架构，而它与传统综合前置系统最大的区别在于后者将“业务”和“技术”混杂在一起，这使得银行IT架构复杂、不清晰，牵一处而动全身；系统之间交互缺乏标准；软件复用程度低、运营和沟通成本高。企业服务总线系统的建设涉及银行服务治理，实现“业务”和“技术”的自由组合。

这里主要谈的敏捷的服务集成：

谈到服务集成，很多人可能会想到企业服务总线（ESB）。从单个系统来看，其内部服务之间的访问基本都是网状结构，服务与服务直接进行访问是顺畅有序的，似乎无需服务总线来支持内部服务。也许有人认为这是由于单个系统内部服务数量少，逻辑相对简单，所以网状结构没有问题。

然而，在互联网（INTERNET）上服务同样是网状结构，服务之间也是直接访问，没有人觉得在互联网上需要经过一个服务总线来避免网状结构。既然小到一个系统，大到整个互联网，服务间都是通过端到端的直接访问来实现服务集成，那为什么在企业级的IT架构规划中通过ESB实现服务集成到现在仍然被很多人认为是比较好的解决方案呢？

首先来看看ESB提出的背景。随着银行近二、三十年的发展，其IT建设从最早的一个综合业务系统开始到现在的上百个系统。随着系统数量的增加，系统间的相互访问越来越多、越来越密切，系统的建设难度和改造难度也越来越大。这就是我们经常说的牵一发而动全身，也是我们所“深恶痛绝”的网状架构的由来。

这个时候有人提出应该有个系统来解决系统间服务集成的问题，来屏蔽系统的变化对关联系统的影响，来统一管理系统间的关联关系。于是大前置及ESB就伴随着这个痛点应运而生。但为什么只有企业级架构规划中才会提出ESB的解决方案呢？其根本原因在于企业层面服务标准缺失或者滞后于IT系统建设。单个系统是由一个项目组来进行统一的设计和建设，其服务标准自然是统一的。互联网是伴随着HTTP协议问世的，其服务标准也是统一的。但银行众多IT系统的建设是各自先后完成的。

在很多年以前银行IT建设的初级阶段，银行尚没有考虑到在企业层面制定服务标准的想法。众多IT系统的服务有着各自的标准，从而导致服务间访问的难度和复杂度越来越大。由此很多银行纷纷启动并完成了ESB的建设。但其中不少完成了ESB建设的银行仍然忽视了服务标准的制定和落地，而仅仅关注在ESB的服务转接功能，认为已经从“网状架构”升级到了“总线架构”，服务集成已经不存在问题了。

实际上，如果没有服务标准或者服务标准没有落地，即使有了ESB，仅仅是把问题迁移到了ESB本身，服务集成的复杂度和难度没有真正解决。因此对于企业内部服务集成来说，ESB建设的最终目标应该是“消灭ESB”。通过ESB完成对全行各个应用系统间访问关系的梳理，根据制定的服务标准进行全面的服务治理。

通过服务治理使全行服务能够遵循统一的服务标准后，服务之间实现了便捷规范的直接访问，ESB也就失去了存在的意义。因此ESB是伴随着服务标准滞后于IT系统建设或缺乏服务标准而产生的，是“存量服务治理过程中的过渡方案”，而非银行进行服务治理的必经之路。相对于ESB，分布式微服务架构更适合银行进行服务治理，实现企业级SOA。服务集成的关键在于通过推进服务标准的全面落地，从而实现内部服务的“即插即用”。

总而言之，根据服务标准进行服务管控治理，使服务标准全面落地，实现内部服务的“即插即用”，这就是敏捷的服务集成能力。