其他
类型化消息的一种设计模式
The following article is from QMQ开源消息队列 Author 余昭辉
使用消息的时候，我们经常会碰到一种场景：Producer 将消息格式升级了，如果没有通知到 Consumer 方，Consumer 就会获取到不兼容格式的消息，导致应用报错。
Kafka 的 Schema registry 必须提前去注册，这个过程有一点点繁琐，然后很多人就不愿意提前去配置，然后干脆不用这种方式，这真是遗憾。所以公共组件一定要做到 API 简洁，使用一定要简单，千万不要繁琐，这些开发人员懒得要命。 Kafka 的检查是运行时发送的时候检查的，这个时候检查虽然能够避免将不兼容的消息发送出去，但是还是有点晚了。
import io.micronaut.http.annotation.Get;import io.micronaut.http.client.Client;import io.reactivex.Single;
@Client("/hello")public interface HelloClient {
@Get("/") Single hello();}//发送消息，定义API，这个接口是自动实现的，不需要y用户实现@QMQProducerpublic interface Producer {
@QMQTopic(topic="order.changed") void orderChagned(OrderEvent event);}
//使用发送消息的API@Resourceprivate Producer producer;
public void pay(Order order){ OrderEvent e = buildEvent(order); producer.orderChanged(e);}
//消费消息@QMQConsumer(topic = "order.changed")public void onMessage(Message<OrderEvent> msg){ OrderEvent e = msg.Data(); //process}在编译时我们就可以提取 OrderEvent 这个类型，将其自动的转换成 schema，然后注册到 schema registry 编译时，我们就可以将 OrderEvent 与 schema registry 里的进行兼容性对比，然后编译时就可以确定是否兼容，不兼容编译时报错，而不是等到发送消息的时候再报错，然后紧急修复。
Go 新版泛型使用：80余行代码构建一个哈希表 哔哩哔哩「会员购」在流量回放上的探索 为什么我放弃使用 Kotlin 中的协程？ 基准测试表明, Async Python 远不如同步方式 谈谈PHP8新特性Attributes
本文授权转载自公众号 QMQ 开源消息队列，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
长按二维码 关注「高可用架构」公众号