一、从技术角度，为什么采用ESB的数据中台不适合互联网场景？
1、ESB的数据交换总线成了整个系统的核心瓶颈。
2、去中心化的服务架构提供直连方式。
综上，像电商系统，一个“结算”、“下单”按钮，后台将调用超200次服务，如果用ESB的方式，收到信息的回应将超过几秒钟，客户体验不好，而且ESB中间件的压力也非常大。另外，如果ESB出现故障，将直接造成所有的业务系统down机。
二、如果对ESB进行扩展，能否满足互联网应用需要？
如果我们估计业务量需要5台ESB服务器同时以集群方式提供服务，并考虑了20%的冗余。如果此时故障了一台服务器，另外4台服务器处于100%的负载状态，业务量只需增加1%将直接导致雪崩效应，所有的服务器全部中断。
而当业务故障恢复时，也不能仅恢复1、2台就开始承载业务，必须将所有的5台ESB服务器全部恢复后（此时业务处于完全中断状态），才能放开业务。否则雪崩效应将再次发生。
而去中心化的架构，业务的高峰拥堵只会发生在某些高负载的模块，不会影响其它业务模块，我们也可以针对高负载的模块进行针对性的扩容。
越来越多的企业、互联网公司已抛弃ESB型的中心化架构。
三、采用去中心化的结构，如何保障高可用？
各位一定会联想到，采用云中心化的结构，服务调用者、服务提供者采用直连方式，而当某服务节点中断时，备用的服务节点如何接替服务？
在正常工作状态，服务调用者通过注册中心服务提供者的地址，当服务者提供者故障时，注册中心将备用的服务节点地址发送给服务调用者，以保障高可用。
同时注册中心还可以根据服务提供者的工作负载，提供服务路由权重等功能。
