网站建设是管理费用的哪项费用,乐天seo培训中心,河源市建设网站,做课件ppt网站这里记录的是学习分享内容#xff0c;文章维护在 Github#xff1a;studeyang/leanrning-share。
我们在上次分享中聊到了领域驱动设计和微服务#xff0c;在 DDD 中有一个术语叫做领域事件#xff0c;例如订单模型中的订单已创建、商品已发货。领域事件会触发下一步的业务…这里记录的是学习分享内容文章维护在 Githubstudeyang/leanrning-share。
我们在上次分享中聊到了领域驱动设计和微服务在 DDD 中有一个术语叫做领域事件例如订单模型中的订单已创建、商品已发货。领域事件会触发下一步的业务操作如果领域事件发生在微服务内可以通过观察者模式很容易实现消息监听并处理。 如果发生在微服务之间则需引入事件总线或者消息中间件。
一、消息队列解决方案
经过技术选型后我们决定使用 Kafka 作为消息中间件此时微服务间的通信示意图如下 不过直接使用消息队列将面临以下问题
开发成本大开发团队成员都需要对消息队列如 Kafka 技术有一定的了解并且还需要关注连接消息队列的一些配置管理难度大各团队都使用一个消息队列其中一个团队使用不当时例如创建了很多个 topic造成资源浪费监控难度大当前只有对 Kafka 集群简单的监控功能运维困难遇到线上消息没有消费时很难排查问题无从下手升级难度大Kafka-Client 需要升级时涉及到服务太多导致升级成本高
我们期望提供的是一种以业务为重心的面向服务的解决方案。
也就是说即使团队中没人了解消息队列技术也能够收发消息。于是对 Kafka SDK 二次封装主要就是为了简化消息的接入无需关注配置。 封装后解决了开发成本大、管理难度大的问题但是离面向服务的解决方案目标还有一定的差距。比如业务方监听到消息后执行一系列的业务逻辑异常了想要做业务补偿我们的“基于 Kafka SDK 二次封装”的方案就没办法满足只能要求消息发送方再发一次消息但这又会影响其他消息监听者。
于是我们决定将消息列队封装成消息服务对业务方提供切实的服务能力。 二、消息服务解决方案
我们熟知计算机中总线在计算机系统中不同的组件和设备需要相互通信以完成各种任务此时计算机总线就发挥了重要作用。类似的微服务系统中微服务就像是计算机系统中的各个组件和设备而消息服务充当的就是计算机总线的角色。消息总线由此而来。 本文中出现的消息总线和消息服务指的是同一个东西。 2.1 架构设计
发送消息和接收消息是消息服务最基本的能力这两项能力分别由消息生产服务、消息消费服务提供。 2.2 消息的流转过程 三、消息服务初体验
微服务架构采用的技术栈是SpringBoot、Kubernetes。
我们将消息总线取名为 CourierCourier 的意思是“快递员”消息的传递类似于快递的收发消息总线正是快递员的角色。下面开始消息服务的初体验。
3.1 零配置接入消息总线
由于我们的微服务使用的是 SpingBoot 来落地的因此我们提供了一个接入消息总线的 spring-boot-starter。
dependencygroupIdcom.casstime.open/groupIdartifactIdcourier-spring-boot-starter/artifactId
/dependency接入消息总线微服务只需要一个EnableMessage注解即可加载所有相关配置
EnableMessage
SpringBootApplication
public class WebApplication {public static void main(String[] args) {SpringApplication.run(WebApplication.class, args);}
}3.2 消息结构定义
下面代码定义了一个消息的基本信息也称为消息 Header包括消息 id分区键 primaryKey来源服务 service消息 topic创建时间 timstamp。
public abstract class Message {private String id;private String primaryKey;private String service;private String topic;private Date timeStamp;
}消息可以分为两类一类是事件另一类是广播。定义如下
// 事件
public abstract class Event extends Message {
}// 广播
public abstract class Event extends Message {
}业务消息内容称为消息 Body例如订单已创建这个消息体的定义
Topic(name order)
public class OrderCreated extends Event {private String orderId;private String orderName;private Date createdAt;
}3.3 使消息收发变得简单
业务方可以在业务执行方法的任一处只需要一行代码即可完成消息的发送。
// 发送消息
EventPublisher.publish(new OrderCreated());对于消息的监听业务方只需关注业务逻辑的执行屏蔽了 Offset 提交、重试等技术实现。
// 接收消息
EventHandler(topic order, consumerGroup consumer-group1)
public class OrderMessageHandler {public void handle(OrderCreated orderCreated) {System.out.println(receive message: orderCreated);}
}3.4 提供 5 种功能类型的消息
我们提供了 5 种不同功能类型的消息满足各类业务场景。
1、事件消息
Topic(name order)
public class OrderCreated extends Event {private String orderId;private String orderName;private Date createdAt;
}public void send() {EventPublisher.publish(new OrderCreated());
}上面消息定义是事件这是使用最多的一种消息。
2、广播消息
广播消息的消费示意图如下 Topic(name order)
public class CacheUpdate extends Broadcast {private String orderId;private String orderName;private Date createdAt;
}public void send() {EventPublisher.publish(new CacheUpdate());
}上面消息定义时继承了Broadcast表示这是一个广播消息消费服务的每个节点都将会收到这个广播。例如更新本地缓存事件就需要用到广播消息。
3、顺序消息
Topic(name order)
public class OrderCreated extends Event {PrimaryKeyprivate String orderId;private String orderName;private Date createdAt;
}public void send() {EventPublisher.publish(new OrderCreated());
}上面消息定义时在orderId上加了PrimaryKey注解表示相同orderId的消息会有序的消费。
4、事务消息
Topic(name order)
public class OrderCreated extends Event {private String orderId;private String orderName;private Date createdAt;
}Transactional
public void send() {EventPublisher.publish(new OrderCreated());
}上面消息发送时在方法上添加了Transactional注解这是 Spring 的注解表示这个方法里的逻辑执行是有事务性的。
5、延迟消息
Topic(name order)
public class OrderCreated extends Event {private String orderId;private String orderName;private Date createdAt;
}Transactional
public void send() {EventPublisher.publish(new OrderCreated(), 2, TimeUnit.SECONDS);
}上面消息发送多了两个参数表示延迟 2 秒接收。
3.5 消息追踪
只要是通过EventPublisher.publish()方法发送的消息都可以追踪到这条消息记录。
消息定义了 5 种状态
发送失败SEND_FAIL通常消息定义不规范消息体过大少数由于网络抖动。已提交COMMITED消息总线已收到消息。推送失败PUSH_FAIL例如服务已下线。处理失败HANDLE_FAIL监听到了消息但是执行业务逻辑抛出了异常。已处理HANDLED 作为消息的发送方关注的是消息是否发送成功可通过下面页面查询。 作为消息的接收方关注的是消息是否正常消费可通过下面页面查询。 3.6 消息高可靠
对于 5 种状态的消息处理策略如下
发送失败SEND_FAIL自动重试手动重试可在消息管理中心手动再发送。已提交COMMITED长期处理已提交状态的消息可能消费方已接收但状态流转异常消息总线会定时重试。推送失败PUSH_FAIL自动重试延迟重试。处理失败HANDLE_FAIL自动重试默认关闭由消费方决定是否开启重试。已处理HANDLED也可手动重试。 封面
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W6OFOpMz-1680000301507)(https://technotes.oss-cn-shenzhen.aliyuncs.com/2023/%E9%9D%A2%E5%90%91%E4%B8%9A%E5%8A%A1%E7%9A%84%E6%B6%88%E6%81%AF%E6%9C%8D%E5%8A%A1%E8%90%BD%E5%9C%B0%E5%AE%9E%E8%B7%B5.png)]
相关文章
也许你对下面文章也感兴趣。
04期领域驱动设计与微服务学习分享第3期你所理解的架构是什么
