在微服务化建设中,应该考虑到 ESB ,也必须考虑到 ESB 。 那么同样是面向服务的架构, ESB 与微服务相比差别在哪儿? 微服务化的建设应该如何安置 ESB ? 在新型架构终将取代腐化传统架构的背景下,如何迁移、替代,保证业务的可用性? 接下来的内容里,将给大家做一个详细的分析。 SOA与ESB
技术架构的发展有其规律可循,从单体到垂直拆分、再到面向服务、最后到分布式微服务,从技术架构上来看是化整为零的,从服务管理角度来看是从单一的管理到集中式的管理。在服务化以后,也就是提出面向服务的架构以后,除了微服务以外, SOA 和 ESB 也是 大家熟知的架构:
微服务的特点
看着上面 SOA 的描述,是不是感觉跟微服务架构也差不多?或者说微服务是 SOA 的升华。那么微服务与 SOA、ESB 有什么不同呢? 我们先来看看微服务优势介绍:
1、 独立、专注、自治
2、 分布式,高可用,扩缩容,资源分配
微服务化以后,服务的业务能力,不只是该系统可以使用,其他有需要的部门或者系统也可以通过接口调用该微服务,提供给其业务处理能力。
ESB对比微服务 1、 独立而不自由。 相对于微服务,SOA架构可以独立部署业务服务,但是不够自由,不能像微服务那样自由互通,只能通过 ESB 做服务通信,所有服务通信都需要 ESB 转发,在 ESB 处集中管理,配置权限、配置策略。 2、 非分布式解决方案 ,服务的高可用无法通过框架整体解决,只能通过传统方式解决。所以,更无法实现横向动态的扩缩容。 3、 ESB 尽管也是面向服务的框架,但是却无法真正 的 实现服务化。 服务化,应该是自消费的模式 ,微服务的服务能力提供以后,使用者可以实现订阅使用。但是 ESB 中,服务能力提供出来只是给特定场景的某几个服务使用,其他服务如果想使用,需要通过定制化的增加。 4、 与自消费的道理相同,服务提供者不能实现自动化的服务提供,ESB中需要增加对应的接口以便于服务提供相应的业务能力。所以在ESB建设中, 会提前制定好需要暴露的指定接口 ,如果有新增的需求,需要针对性的定制化。而微服务提供的则是一个微服务平台,只要遵循特定的协议,无论是服务的提供还是使用,都可以自由 的 上下线 和增减。 5、 微服务架构是新型的服务化架构,而 ESB 架构很容易腐化,且维护困难,技术核心非开源,受厂商绑定。微服务基本上都是基于开源的新型的技术, 不存在腐化,且可以自主掌握核心技术 。 6、 ESB 是集中化的服务管理模式, ESB 的性能将决定集团整体的通信性能 ,且由于过于“集中”导致一旦总线出现问题,整个集团的信息化系统将面临“瘫痪”的风险。而微服务则不同,微服务采用去中心化方案, 任何一个组件出现问题都不会影响全局的业务 。 ESB终将被替代 业务持续增长,所以需要技术不断革新,促进技术框架也不断进步。一切变化的源头都在业务的变化,业务消费量成几何倍增长,所以要求服务可以自由的扩缩容; 新型业务 的不断增加,要求服务支持动态的运营和管理。而 ESB 的架构过于死板,已经完全不适合云原生理念下的服务治理 。 老旧的系统架构逐渐力不能支,新型的微服务架构应运而生 ,在这个趋势的指引下,我们开始做微服务化的建设,但是在微服务化建设期间 ESB 如何安置,是一个比较大的问题。企业中多数系统的互联互通都依赖于 ESB 的服务总线,但同时改造所有 ESB 接入的系统,工程量会很巨大,容错率会很低,危险性也极高。因此 ESB 的替代尽管势在必行,却也需要慎重的规划 。 通常 ESB 的改造需要采用逐步改造加逐步迁移的方式,根据不同的系统现状,做相应的方式处理:
在微服务建设的初期,ESB 因在企业中起到的关键作用,并不能完全替换或取代,因此需要有个过渡期 :通过微服务管理台,兼容纳管 ESB 的服务;通过API 网关转换报文,路由转发 ESB 的接口,以保证存量的系统与增量或改造的系统兼容管理、互联互通。
其实 ESB 的功能,路由、转发,与 API 网关的功能极其相似。 接下来,我们将会重点分析 API 网关在微服务中的作用与 ESB 的区别和优劣,敬请期待。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论