Kafka调研(3):多点通信方案的设计-2
1. 星形拓扑的通信模型
星形的意思是说,有一个消息接收和转发中心,应用两两之间并不直接通信。所有的应用层消息都通过Kafka集群进行中转。但是对Kafka来说,消息的机制是推拉机制。如果需要接收消息,需要应用层连接到集群,订阅感兴趣的topic,然后poll消息。
为了实现这种模型,
1. 我们利用Kafka本身的ACL控制机制来对topic权限进行控制。
- 对每一个应用分配唯一的Consumer Group。
- 对每一个接入的应用分配唯一的账户和密码。
- 对每一个接入的应用分配SSL证书
- 对每一个topic按照应用进行配置读写权限。
- 对每一个接入的应用分配一个唯一的秘钥(该秘钥通过安全方式传递)。
2. 同时我们在应用包装一层API进行消息分派机制
- 应用层的消息需要进行加密。
- 应用层需要校验消息的来源和完整性。
- 判断该消息是否应该被处理,比如消息的接收方是否包含了自己。
- 应用层需要按照消息的业务ID(或者其他机制)分派合适的处理函数。
3. 星形拓扑通信模型:
2. 应用层框架能力分析
Kafka Client API[1]提供了功能丰富的接口, 同时通过Properties进行不同的配置。 Consumer API不是线程安全的。但是实际在应用过程中,一般来说会固定一套配置,同时希望应用层只需要配置topic行,其他的细节不需要关心。
经过考虑,该框架需要支持的能力如下:
应用层:
- 提供一套简化的API支持Kafka消息的发送和接收。
- 和Spring进行集成,服务通过@Service的API进行暴露给应用层。
- 提供Request-Reply语义的接口(其中请求消息和响应的消息的匹配规则可以自定义)。
- 自动编译protobuf IDL定义并生成相应的JAR包。
- 支持消息接收注册和自定义分发机制
包装层:
- 支持默认的数据序列化和反序列化(POJO对象、protobuf、FastJSON)。
- 底层框架API支持自定义序列化框架注入。
- 提供了底层多线程的能力。
- 提供Offset commit的高级控制机制
2. 应用层消息框架设计
总体设计如下:
模块划分:
于是,经过设计可以初步划分为5个模块:
kafka-message-service-api
kafka-message-service-impl
kafka-protobuf-model-generator
kafka-api-wrapper-api
kafka-api-wrapper-impl
具体模块设计图如下:
详细类图设计:
后面再补充
API设计:
对应用层来说,只需要熟悉和理解这几个API就可以完全的收发消息。至于底层的多线层、偏移量的控制、异常的处理、Kafka的配置等都不需要直接处理。
Message Sender Service API:
1 | public interface IMessageReceiverService { |
Message Receiver Service API:
1 | public interface IMessageSenderService { |
MessageReceiver
1 | /** |
3. 消息协议制定
1 | message MessageEnvelope { |
- 1.https://kafka.apache.org/10/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html ↩