互联网银行(2)-ESB与互联网网关比对

ESB与互联网网关比对

先不讨论ESB与互联网网关这两类型系统放到一起比，是否合适。
功能，以及系统未来的发展方向，有不少的交集。全程参与从SOA架构往微服务（SOA2.0）的演进过程，抽空来对这两种架构进行对比。

ESB

发展及现状

企业服务总线（EnterpriseServiceBus，ESB）从面向服务体系架构（Service-OrientedArchitecture，SOA）发展而来，是传统中间件技术与XML等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通，是一种在松散耦合的服务和应用之间标准的集成方式。

• 它可以作用于：
  • 面向服务的架构—分布式的应用由可重用的服务组成。
  • 面向消息的架构—应用之间通过ESB发送和接受消息。
  • 事件驱动的架构—应用之间异步地产生和接收消息。

ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为低廉的解决方案，同时它还可以消除异构系统之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。
传统的ESB架构与大三层的网络架构，构建了国内大部分银行当前的系统架构，如下图。

互联网业务域架构

ESB功能

一、 业务接口治理（重要）

1.1 应用系统接入规范:

       1. 服务治理宣贯   
       2. 提亝项目接入计划   
       3. 系统接入申请   
       4. 服务治理资料采集   

1.2 服务标准定义规范:

       1. 服务层次划分原则
       2. 服务编码原则
       3. 服务接口定义原则
       4. 元数据定义原则
       5. 公共代码管理原则
       6. 服务规范定义方法

1.3 服务版本发布规范:

       1. 版本号编码规则
       2. 版本命名规则
       3. 版本制作规范
       4. 版本収布规范

1.4 服务治理模板:

       1. 接入申请
       2. 接口文档
       3. MBSD（服务定义流程）
       4. 元数据字典
       5. 公共代码管理
       6. 字段映射
       7. 服务水平协议
       8. 服务调用注册申请

二、流控

支持目前主流的多种流控方案，具体方案请参考文档。

三、服务组合

服务编排功能-服务组合功能，这也就是目前火热的大中台概念，服务组合拼装底层原子接口，组合成一个对外的服务接口，比如登入接口，整合了用户的登入，风险的策略，运营的通知等，其中比较知名的有Netflix的conduct和Amazon 的swf。在大型企业中，中台是发展的必然，能省却很多的重复开发，业务系统，这条线只要关注自己的业务功能，基础功能全部由中台提供变频，组合。小企业业务域的区分相对比较难，以及很难抽出一个独立的部门专门来负责这件事，所以就变成中台也是各条线自己负责，效果不明显。

四、安全性

授权，签名，证书等，这块内容非常重要，有些银行会把ESB上的功能对外互联网访问，这块就显得特别重要，对于2018年开始大力宣传的开发银行概念，几乎每家银行都或多或少的参与其中，接口安全，数据安全是银行的立行之本，底线不能丢。

五、消息转换

支持多类型报文格式转换，例如soap,XML,定长,json等，新添加一种只要开发一个模板即可。这块在银行系统中特比的适用。银行系统有其特殊性，因为系统组成非常复杂，系统成熟度高，专业性非常高。例如决策引擎，大总账等系统，都是供应商几十年演化的产品。某些领域供应商具有垄断优势，银行无法要求对方修改，所以异构系统适配在银行内部是必然的存在。

六、监控

接口调用次数，调用渠道，调用方，提供方等，全景视图查询。
这块内容对于银行的运维，以及资源配置非常的重要，能够实时的看到全行的瓶颈，热点在哪里，同时也能安排最优化的资源给与该部门。视图画的全景监控，是现代软件标配，否者只是一个简单的功能。

七、其它

ESB经历几十年的发展，全球范围内，国外有IBM,ORACLE,国内有神码等，发展的都特别完善，每家都形成自己的特色，成熟度非常高，如果银行没有自己的核心开发能力，对于网络架构，IAAS,PAAS,应用架构很好把控的架构师，还是推荐ESB的全局网关，或者类似于百信银行的金融网关。如果行方能力强，有自己独特的发展理念，未来期望往服务化，容器化方面发展的话，ESB不是一个最佳选择。

缺点

1. 成本是一个不小的问题。
2. 全局集中式节点，在整体微服务架构体系下，显得笨重。
3. 南北向网络流量压力，对核心交换机要求高，设备成本高。
4. 不利于企业往SDN架构的容器化网络发展。

ESC（神州数码）

ESC和ESB的本质差异，解决异构系统也能享受微服务红利，类似service mesh。如下图

互联网网关

优点

优点就不细说，网络上有非常多的介绍，包括目前使用量非常大的spring cloud 套件，Netflix家族产品，这些都能提供对应的类似ESB的产品功能。

在银行业使用缺点

一、 成熟度
银行上线的第一天开始就有几十个系统在运行，上千到万的api量，所以如何梳理，治理出这么系统间关系是一个极富的挑战性的工作。
导致互联网应用所向披靡的网关，在银行的架构里就略显的单薄。
下图是某银行治理的接口数量，供参考。
二、 时机成本？
业务的发展VS系统建设成本和周期。
要想获得和ESB具有同样效果的功能需求，银行比如需要投入不少的人力进行调研，开发，测试，银行在初期本来资源就非常有限，所以是很大的挑战。
三、机遇
据我所知，目前大多数股份制银行和国有银行都在重构其核心系统，或者单独一套新的瘦核心系统，主要功能是服务于互联网应用最为普及的二，三类账户服务功能。在这类型的系统中，股份制行头部企业目前已知道有两家走的是容器化与虚拟化并行的线路，网络架构就不放了，大家脑补。所以系统往互联网微服务化发展是未来的大概率事件，互联网网关就成为系统的标配。个人预测，未来会把很多原来集中在ESB中的功能，分散到各个小网关上。

---

总结比对

参考资料：

• 神州数码ESB简介。