kratos
kratos copied to clipboard
go-kratos
[Feature] Discussion on the definition and usage of event interface
背景
在实际业务场景中，框架需要接入消息队列，消息队列的接入方式有很多种，框架中应提供抽象接口，并提供一些默认实现，如 kafka 等
相关资料
- #1159
- https://github.com/openmessaging/openmessaging-go
- https://github.com/cloudevents/sdk-go/blob/main/v2/client/client.go
- https://docs.dapr.io/reference/api/pubsub_api/
type Message interface {
Key() string
Value() []byte
Header() map[string]string
Ack() error
Nack() error
}
type Handler func(context.Context, Message) error
type Event interface {
Send(ctx context.Context, key string, value []byte]) error
Receive(ctx context.Context, handler Handler) error
Close() error
}
可以通过 ctx 结合 metadata 进行传递调用信息
type Sender interface {
Send(ctx context.Context, msg Message) error
}
type Receiver interface {
Get(ctx context.Context) (Message, error)
Ack(msg Message) error
Nack(msg Message) error
}
可以参考一下 bindings 和 pubsub 的接口设计
- https://github.com/dapr/components-contrib/tree/master/bindings
- https://github.com/dapr/components-contrib/tree/master/pubsub
用单个请求拼成batch，和直接调batch，性能是有差别的
可不可以有BatchSend和BatchGet
@Windfarer 接口应该不包含把，实现的时候自己加上。接口保证最小粒度。
事件接口的方法中的 Receive 语义上应该是有返回结构的，这里应该是 publish - subscribe / send - receive 互相匹配
用单个请求拼成batch，和直接调batch，性能是有差别的
可不可以有BatchSend和BatchGet
@Windfarer 接口应该不包含把，实现的时候自己加上。接口保证最小粒度。
提醒一下，大多数MQ实现不能保证Batch的原子性，即可能会出现batch中部分成功，部分失败的后果。
event接口可以考虑支持async API： https://www.asyncapi.com/
CloudEvent这种标准，对serverless场景做了太多倾斜。相比较下，AsyncAPI更符合实际工业场景。
type Sender interface { Send(ctx context.Context, msg Message) error }type Receiver interface { Get(ctx context.Context) (Message, error) Ack(msg Message) error Nack(msg Message) error }
type Receiver interface {
Receive(ctx context.Context) (Message, error)
Ack(msg Message) error
Nack(msg Message) error
}
