前言为了让中间件开发者们将更多的精力投入到产品的功能特性上,而不是重复的写通信层框架,蚂蚁中间件团队设计并实现了 SOFABolt。 Bolt 名字取自迪士尼动画-闪电狗,是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。蚂蚁中间件的同学这些年在微服务和消息中间件上解决了很多网络通信的问题,积累了很多经验,并将这些经验、解决方案沉淀到了 SOFABolt 这个项目中,希望能让更多需要使用网络通信的团队、开发者受益。目前 SOFABolt 已经运行在满意中间件的微服务 (SOFARPC)、消息中心、分布式事务、分布式开关、以及配置中心等众多产品上。 主要特性SOFABolt 核心功能包括三大块:
网络通信能力
协议框架 私有协议实现 协议框架协议框架整体如下:
3.1 请求的处理流程一个请求处理流程大致如下:
CommandFactory 是一个工厂类,比较简单,不展开介绍。编解码相关内容见《SOFABolt编解码机制》。下面介绍一下CommandHandler 对请求的分发和处理。 上面是 SOFABolt 中 RpcHandler 的代码片段,这段代码是命令处理的入口:
上面的处理逻辑中透露出一个信息:SOFABolt 支持同时运行多个版本的协议,通过 ProtocolCode 来区分协议。这一点可以使得系统在做升级或重构时,需要同时支持新老系统不同协议时变得简单。 上面是 CommandHandler 的代码片段,透露出的信息是 SOFABolt 支持批量提交请求,这在《SOFABolt 编解码机制》一文中也有部分介绍。而具体的 process流程如下: 通过 Command 对象获取 CommandCode,根据 CommandCode 获取对应的RemotingProcessor 进行处理。 再往下看一层,请求会被提交到RemotingProcessor中处理。上面是RpcRequestProcessor 处理请求的代码片段,处理流程中会通过cmd.getRequestClass()来获取请求的对象的 Class 名称,再获取对应的UserProcess进行处理(具体处理不再上面的代码片段中)。 3.2 协议框架的拓展机制通过对请求处理流程的分析可以感受到 SOFABolt 的协议框架是支持多协议版本运行,能直接使用,也支持进行拓展来实现更丰富和定制化的功能。下面具体介绍SOFABolt 的拓展机制。 上图是 RemotingCommand 在处理过程中的路由示意图。第一层路由根据 ProtocolCode 进行,第二层路由根据 CmdCode 进行,第三层路由则根据 RequestClass 进行。用户可以在每一层进行扩展来实现自己的处理。 这种设计具有很好的拓展性和灵活性,ProtocolCode 用于区分“大版本”的协议,适用于协议发生较大的变化的场景。CmdCode 则标识请求类型,比如在RPC场景中 CmdCode 可能就两个:RPC_REQUEST、RPC_RESPONSE,而在消息场景中CmdCode 可能会更丰富一些,比如有发送消息、批量发送消息、投递消息等等。RequestClass 是 Command上承载的数据的类型,用户根据不同的类名进行不同的业务逻辑的实行。 实际应用中,以 RPC 的场景为例,用户更多的是去实现 UserProcessor 来完成不同的业务逻辑的处理。而在消息的场景中,因为消息承载的是二进制的数据,所以请求的数据类型是固定的,系统更多的是拓展 CmdCode 来执行不同类型的请求的处理,比如心跳请求的处理、写入消息的处理、批量写入消息的处理等等。SOFABolt 协议框架的设计和实现,具备较好的可拓展性,使其能应用于蚂蚁的 RPC框架、消息中心、分布式开关、配置中心等多个中间件。 3.3 使用 SOFABolt 自定义协议在了解了SOFABolt协议框架的基础结构、请求处理流程、拓展机制后,我们来尝试分析如何使用SOFABolt以更深入的理解它的协议框架。 下面以应用到 RPC 框架中为例进行分析。使用 SOFABolt 的第一步就是实现自己需要的 Command。因为 SOFABolt 中已经包含了默认的 RPC 协议的实现,所以在RPC 的场景中,并不需要拓展 Command 类。 SOFABolt 中也提供了CommandFactory 的默认实现:RpcCommandFactory,所以这块也不需要进行拓展。 同样的,SOFABolt中也包含了CommandEncoder和CommandDecoder 的实现,所以对于一个 RPC 应用而言,唯一需要拓展实现的就是在服务端注册自己的UserProcessor:RpcServer#registerUserProcessor(UserProcessor)。 上面是 UserProcessor 相关的类图,主要分两类:注册到单一数据类型上的 UserProcessor 和支持注册到多个类型的 MultiInterestUserProcessor。 用户只需要根据自己的需求,选择是否使用 MultiInterestUserProcessor。再进一步根据是否需要同步处理来选择继承 Sync 或者 Async 的 UserProcessor 子类即可。那么对于一个RPC的使用场景来说,实现 UserProcessor 并注册到 RpcServer 和RpcClient即是所有的开发工作。 总结本文首先对 SOFABolt 做了简要的介绍,之后介绍了 SOFABolt 协议框架的整体结构、Command 的处理流程、拓展机制,之后通过分析如何使用 SOFABolt 来加深对 SOFABolt 协议框架及其拓展性的理解。 本文没有展开说明 SOFABolt 中协议的细节,这个可以在《 SOFABolt 编解码机制》中找到对应的解析。 |
|
来自: airen89 > 《sofabolt》