微服务架构下如何解耦,对于已经紧耦合下如何重构?( 二 )


文章插图
 

消息中间件(message oriented middleware)是指支持与保障分布式应用程序之间同步/异步收发消息的中间件 。消息是分布式应用之间进行数据交换的基本信息单位,分布式应用程序之间的通信接口由消息中间件提供 。其中,异步方式指消息发送方在发送消息时不必知道接收方的状态,更无需等待接收方的回复,而接收方在收到消息时也不必知道发送方的目前状态,更无需进行同步的消息处理,它们之间的连接完全是松耦合的,通信是非阻塞的,这种异步通信方式是由消息中间件中的消息队列及其服务机制保障的 。
消息中间件实现了发布者和订阅者在时间、空间和流程三个方面的解耦:
  • 时间解耦—-发布方和订阅方无需同时在线就能够进行消息传输,消息中间件通过存储转发提供了这种异步传输的能力;
  • 空间解耦——发布方和订阅方都无需知道对方的物理地址、端口,甚至无需知道对方的逻辑名字和个数;
  • 流程解耦——发布方和订阅方在发送和接收数据时并不阻塞各自的控制流程 。
从消息中间件的基本功能来看,无论是点对点消息中间件还是消息代理,其体系结构都是非常清晰简单的 。但由于分布式应用及其环境的多样性和复杂性,导致了消息中间件的复杂性 。
当前的消息中间件仍然分为两类,一类是基于AMQP高级消息协议的,一类是基于JMS消息协议的 。对于互联网使用较多的RabbitMQ,Kafka等基本都基于AMQP高级消息协议 。而对于Weblogic JMS,IBM MQ则是基于JMS消息协议的消息中间件产品 。
【微服务架构下如何解耦,对于已经紧耦合下如何重构?】对于Weblogic而言是一个企业级的应用服务器中间件,同时Weblogic JMS也是企业级的消息中间件产品,该产品是一个企业级消息中间件产品,具备了高可靠,高可用,高扩展,高性能基础特性 。支持主流的各种消息模型,消息发布订阅,消息持久化,事务处理,集群等核心特性 。
消息中间件的使用场景,具体包括了如下几个方面:
  • 1.消息通知:单据状态变化后的事件通知,数据传输完成后的事件通知
  • 2.异步集成:服务消费方只需要将数据送到OSB即实时返回,通过异步集成实现彻底解耦
  • 3.目标系统削峰:大并发数据导入而目标系统处理性能受限的场景
  • 4.消息发布订阅:基础主数据通过JMS实现1对多的实时数据分发
  • 5.高可靠性场景:确保在数据集成中不出现任何丢失的情况
对于采用Weblogic JMS来实现消息集成,具体过程如下图:
微服务架构下如何解耦,对于已经紧耦合下如何重构?

文章插图
 
基于事件驱动的业务分析
而要做到同步转异步,我们必须从业务需求分析开始就转变思维,即从传统的业务流程需求分析方法转到事件驱动分析方法,这个在我很早的EDA事件驱动架构内容整理的时候专门谈到过,今天摘录部分内容供大家参考 。
事件驱动框架(EDA)里事件可传输于松散耦合的组件和服务之间 。一个事件驱动系统典型地由事件消费者和事件产生者组成 。事件消费者向事件管理器订阅事件,事件产生者向事件管理器发布事件 。当事件管理器从事件产生者那接收到一个事件时,事件管理把这个事件转送给相应的事件消费者 。如果这个事件消费者是不可用的,事件管理者将保留这个事件,一段间隔之后再次转送该事件消费者 。
EDA架构往往具备如下特征:
  • 广播通信:参与通信的系统将事件广播给任何对该事件感兴趣的参与者 。
  • 实时性:在业务事件发生时候,EDA架构下可以实时的发送事件给消费方,而无需等待
  • 异步:事件发布系统不用等待事件接收系统来处理事件,发送到EDA模块即可返回 。
  • 细粒度:只要具备独立的业务价值,即可以发布为细粒度的事件,而不是传统服务下的粗粒度 。
  • 复杂事件处理:根据业务流程需求,事件间可以聚合和组装,形成事件链满足复杂事件处理 。
  • 并行运行:多个事件可以同时运行,单个事件可以同时分发给多个订阅方 。
  • 非阻塞:EDA本身提供MQ等消息持久化机制,不会在事件大并发下出现事件阻塞情况 。
简单来讲,消息集成,异步,彻底解耦,消息发布订阅,事件链是EDA整个架构的核心 。但是在EDA包括CEP复杂事件处理,在使用的时候首先还是应该了解清楚其和传统流程驱动在业务分析方法上的区别 。简单来说,流程驱动和事件驱动的一个简单比较可以用下图描述:


推荐阅读