一、从技术角度,为什么采用ESB的数据中台不适合互联网场景?

      1、ESB的数据交换总线成了整个系统的核心瓶颈。

ESB 原理 esb的缺点_服务调用

      2、去中心化的服务架构提供直连方式。

ESB 原理 esb的缺点_服务调用_02

      综上,像电商系统,一个“结算”、“下单”按钮,后台将调用超200次服务,如果用ESB的方式,收到信息的回应将超过几秒钟,客户体验不好,而且ESB中间件的压力也非常大。另外,如果ESB出现故障,将直接造成所有的业务系统down机。

 

      二、如果对ESB进行扩展,能否满足互联网应用需要?

      如果我们估计业务量需要5台ESB服务器同时以集群方式提供服务,并考虑了20%的冗余。如果此时故障了一台服务器,另外4台服务器处于100%的负载状态,业务量只需增加1%将直接导致雪崩效应,所有的服务器全部中断。

      而当业务故障恢复时,也不能仅恢复1、2台就开始承载业务,必须将所有的5台ESB服务器全部恢复后(此时业务处于完全中断状态),才能放开业务。否则雪崩效应将再次发生。

      而去中心化的架构,业务的高峰拥堵只会发生在某些高负载的模块,不会影响其它业务模块,我们也可以针对高负载的模块进行针对性的扩容。

      越来越多的企业、互联网公司已抛弃ESB型的中心化架构。

 

      三、采用去中心化的结构,如何保障高可用?

      各位一定会联想到,采用云中心化的结构,服务调用者、服务提供者采用直连方式,而当某服务节点中断时,备用的服务节点如何接替服务?

      在正常工作状态,服务调用者通过注册中心服务提供者的地址,当服务者提供者故障时,注册中心将备用的服务节点地址发送给服务调用者,以保障高可用。

      同时注册中心还可以根据服务提供者的工作负载,提供服务路由权重等功能。