之前提过，我目前在做一个企业级的消息中间件平台应用，将各个消息中间件整合入这个平台，实现所有消息中间件的集中监控，统一运维，在线申请，一键安装等能力。
由于产品的差异性，我们内部出现了两个声音，一个是将所有相同的功能提炼合并，比如统一API，统一用户校验；另一个是不做统一的功能，而是在各消息中间件上根据其特点开发功能，使用原生API。从消息中间件的角度来说，后者更灵活，但需要对不同的消息中间件的相同的功能研究学习。而从产品的角度来说，前者更靠近用户，且能减少自己和用户的学习成本。
我当然选择前者。
言归正传，不管是ActiveMQ、Kafka、RabbitMQ，其实都包含了一个用户权限认证的模块，我们要做的前置其实就是要实现用户权限认证的功能。其实前置能做的事不止于此，我琢磨了下，应该有以下几个功能：
- 用户接入权限校验
- 用户对TOPIC/QUEUE的读写权限校验（进而实现服务降级）
- 异常时，熔断客户端连接
- 客户端监控告警
- 消息中间件集群路由
前置功能
这个设计借鉴了RocketMQ的NameServer，在RMQ的设计中，NameServer作为一个无状态，集群间无数据交互，可快速横向扩展的节点，保存了所有Broker和Topic的状态信息，当客户端连接到NameServer时，可以快速告知客户端其所需要的连接。客户端会与前置保持长连接，持续更新路由信息。我认为相比使用zookeeper（半数以上节点故障集群就宕），NameServer的架构更适用于前置。
但作为一个只提供校验的节点，并不需要与客户端保持长连接，只需要在客户端启动时，访问一次前置获取校验结果即可。如果要实现熔断，也可以通过客户端定时访问前置再次校验来实现（准实时熔断）。
前置的设计需要考虑以下几个方面：
- 处理大量并发请求的能力——>使用Netty框架，Protobuf格式
- 分布式架构下的数据同步——>统一数据源，使用Redis缓存
- 服务高可用保证——————>节点无状态，集群间无数据交互
- 快速扩展—————————>使用docker
- 数据高可用保证——————>在Redis异常时，使用其他数据源
当然配套就需要封装一个统一API来实现一致化的数据校验。
这系列的文章只会提供一些简单的demo，其实任何功能最核心的还是核心逻辑的设计。希望能对大家带来一些启发，当然，如果有任何建议，也欢迎交流。
网友评论