• 注册
  • 后端开发博客 后端开发博客 关注:0 内容:2417

    BoCloud博云:ESB老旧力不能支,微服务独立自治强势替代

  • 查看作者
  • 打赏作者
  • 当前位置: 职业司 > 后端开发 > 后端开发博客 > 正文
    • 后端开发博客
    • **在微服务化建设中,应该考虑到 ESB ,也必须考虑到 ESB 。**那么同样是面向服务的架构, ESB 与微服务相比差别在哪儿?微服务化的建设应该如何安置 ESB ?在新型架构终将取代腐化传统架构的背景下,如何迁移、替代,保证业务的可用性?接下来的内容里,将给大家做一个详细的分析。

      SOA与ESB

      技术架构的发展有其规律可循,从单体到垂直拆分、再到面向服务、最后到分布式微服务,从技术架构上来看是化整为零的,从服务管理角度来看是从单一的管理到集中式的管理。在服务化以后,也就是提出面向服务的架构以后,除了微服务以外,SOA 和 ESB 也是大家熟知的架构:

      • SOA架构:其实是一种设计理念,没有架构和技术的依赖,只是多个服务以独立的形式部署运行,服务间通过网络调用,最终提供一系列完整的功能。

      BoCloud博云:ESB老旧力不能支,微服务独立自治强势替代

      • ESB:企业服务总线,用来连接各个服务节点,服务间通信都通过 ESB 做路由和转发。最主要的是,不同应用可能有不同的协议和报文,ESB 最大的功能是解决不同的服务间互联互通。所以,ESB 其实也算是 SOA 的一种实现形式

      BoCloud博云:ESB老旧力不能支,微服务独立自治强势替代

      微服务的特点

      看着上面 SOA 的描述,是不是感觉跟微服务架构也差不多?或者说微服务是 SOA 的升华。那么微服务与 SOA、ESB 有什么不同呢?

      我们先来看看微服务优势介绍:

      1、 独立、专注、自治

      • 可以独立的部署、独立的运行,使用单独的数据库,甚至使用单独的前端。这样可以将故障影响面降低,不会出现牵一发动全身的事情。

      • 专注于自身的业务,比如报表服务,只关注于报表,也就能聚焦于报表业务,不需要考虑监控、告警和日志,只需要输入数据,生成报表。

      • 研发团队自治,可以拉起一个三五人的小团队,只做报表相关功能和业务,效率高、专业程度高、产生质量和价值高。

      2、 分布式,高可用,扩缩容,资源分配

      • 微服务框架,支持分布式的部署和运行方式,解决了服务的高可用问题。

      • 通过注册中心的服务发现,实现服务的动态扩缩容,可根据业务并发量,自动调整横向的扩缩容量。

      • 根据不同的业务模块,调整服务的资源配比。例如在财务系统中,用户管理模块(用户增删改)使用频率较低,可以部署一个资源少、单副本的用户服务;但是账务模块使用极其频繁,每天达到上百单,可能分配一个资源多、多副本的账务服务。但是如果非微服务架构的话,就需要做系统的整体扩容,以满足最大业务量的模块,会造成其他模块的资源浪费。

      3、 服务解耦、服务化

      • 拆分了微服务以后,服务间的依赖都会通过网络传输的方式提供。也就是说一个服务只需要提供所需的功能接口,就可以满足整体的业务实现。因此,微服务使用什么编程语言,如何实现业务逻辑都可以不用考虑,只需要提供该有的功能接口(只关注于结果)。这样服务在开发、管理、使用的时候,可以实现真正的解耦,不会受到开发框架、开发模式的制约。

      • 微服务化以后,服务的业务能力,不只是该系统可以使用,其他有需要的部门或者系统也可以通过接口调用该微服务,提供给其业务处理能力。

      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 的改造需要采用逐步改造加逐步迁移的方式,根据不同的系统现状,做相应的方式处理:

      • 接受深度改造的系统,通过拆分改造成微服务系统,那么之前的调用方式可以直接修改成微服务的调用方式,这部分在我们的微服务化建设当中,需根据实际情况做好相应的建设规划;

      • 支持轻度改造的系统,不做微服务化拆分,但是可以改造调用或访问的方式和地址。这部分系统可以将调用地址直接换成 API 网关的地址,通过 API 网关提供原 ESB 的如协议转换、路由转发、认证控制等功能,替换掉 ESB 的代理;

      • 完全不接受改造的系统,或者对 ESB 依赖极强的系统,在做深度改造之前,ESB 不能被取代,那么仍需要保留 ESB 。但是需要考虑新改造的,或者增量的微服务系统,与 ESB、与老旧系统之间的通信,因此需要对运行中的 ESB 做兼容和纳管。

      在微服务建设的初期,ESB 因在企业中起到的关键作用,并不能完全替换或取代,因此需要有个过渡期:通过微服务管理台,兼容纳管 ESB 的服务;通过API 网关转换报文,路由转发 ESB 的接口,以保证存量的系统与增量或改造的系统兼容管理、互联互通。

      其实 ESB 的功能,路由、转发,与 API 网关的功能极其相似。接下来,我们将会重点分析 API 网关在微服务中的作用与 ESB 的区别和优劣,敬请期待。

      请登录之后再进行评论

      登录

      手机阅读天地(APP)

      • 微信公众号
      • 微信小程序
      • 安卓APP
      手机浏览,惊喜多多
      匿名树洞,说我想说!
      问答悬赏,VIP可见!
      密码可见,回复可见!
      即时聊天、群聊互动!
      宠物孵化,赠送礼物!
      动态像框,专属头衔!
      挑战/抽奖,金币送不停!
      赶紧体会下,不会让你失望!
    • 实时动态
    • 签到
    • 做任务
    • 发表内容
    • 偏好设置
    • 到底部
    • 帖子间隔 侧栏位置:
    • 还没有账号?点这里立即注册