(一) Nepxion-Thunder分布式RPC集成框架 - 介绍

Nepxion-Thunder（QQ 群 471164539）发布在https://github.com/Nepxion/

 

1. 概要

• 1.1 Thunder是基于Netty + Hessian + Kafka + ActiveMQ + Tibco + Zookeeper(Curator Framework) + Redis + FST + Spring + Spring Web MVC + Spring Boot + Docker分布式RPC调用框架。架构思想主要是来自阿里巴巴的Dubbo框架，但比它更轻量级，零配置式实现部署
  跟Dubbo相比，Thunder的增强功能包括
  1）支持Message Queue（消息队列中间件），Dubbo只支持Netty等内存堆积消息的方式，Thunder不仅支持内存堆积，也支持MQ的硬盘文件堆积
  2）支持本地链式调用，全程无阻塞的调用方式，可省去业务端写Callback的步骤
  3）支持跨进程的调用链，服务端和调用端都支持软负载均衡
  4）支持远程配置和调优，业务端所有集群下的应用可共享一个配置文件，并且通过远程配置方式修改，也支持业务系统自身已经存在的参数化平台的配置方式接入
  5）支持丰富的监控手段，默认支持Redis，Splunk，自定义第三方WebService做监控
  6）支付丰富的服务治理手段，图形化，上下线宕机邮件或者短信通知，异常事件自定义捕捉
  7）支持序列化在网络传输层面的压缩（QuickLz），在大数据量传输，通过压缩，对提高吞吐量（TPS）尤其有效
  8）支持Spring的简化配置，支持全局配置和局部配置的结合
  9）支持对微服务框架的整合（例如：Spring Boot）
  10）支持对Docker的整合
  跟Dubbo相比，Thunder的未支持功能包括
  1）软负载均衡的算法，Thunder支持三种（轮询，随机，一致性哈希），Dubbo还支持最少活跃度，还支持预热和权重计算
  2）访问规则，Thunder支持限流，密钥匹配，版本匹配，Dubbo相对更丰富，例如黑白名单，服务降级，网段隔离
• 1.2 Netty是由JBOSS提供的一个Java开源框架，提供异步的、事件驱动的网络应用程序框架和工具，它是基于TCP，UDP协议的传输方式的NIO框架。在Thunder，实现异步/同步/广播的调用方式，多线程实现调用
• 1.3 Hessian是轻量级的Remoting HTTP框架，提供同步的调用方式。它是基于二进制RPC协议。在Thunder，实现异步/同步/广播的调用方式，多线程实现调用
• 1.4 Kafka是一种高吞吐量的分布式发布订阅消息系统，非JMS标准，是MQ里面性能最优化的。在Thunder，实现异步/同步/广播的调用方式，多线程实现调用
• 1.5 ActiveMQ是由Apache出品，最流行的，能力强劲的开源消息总线。它支持JMS1.1和J2EE 1.4规范的 JMS Provider，支持二进制协议(openwire，amqp)，文本协议(stomp)，物联网协议(mqtt)，WebSocket(ws)五种协议，Spring无缝整合它到框架里面。在Thunder，实现异步/同步/广播的调用方式，多线程实现调用
• 1.6 TIBCO(NASDAQ:TIBX)是一家有着20年历史的老牌中间件公司，致力于EAI企业应用集成产品和解决方案的领域。在Thunder，实现异步/同步/广播的调用方式，多线程实现调用。由于是商业软件，不提供开发包，请到该公司主页获取免费版开发包
• 1.7 Zookeeper是分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和HBase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。Thunder利用Apache Curator Framework的衍生组件，实现对Zookeeper的调用
• 1.8 Redis是一个Key-Value存储系统，异常快速的数据持久化，支持丰富的数据类型，良好的操作原子性，多实用的工具，可以在多个用例如缓存，消息，队列使用(Redis原生支持发布/订阅)，任何短暂的数据，应用程序，如Web应用程序会话，网页命中计数。Thunder利用它做发布/订阅功能，该功能是对Netty和Hessian的增强
• 1.9 FST(Fast Serialization)和Kryo是实现Java快速对象序列化的开发包。序列化速度更快(2-10倍)、体积更小，而且兼容 JDK 原生的序列化，使用者可以任选1个，推荐FST
• 1.10 Faster Jackson和Alibaba fastjson是实现的Json对对象和字符串的高速转换。使用者可以任选1个，推荐Faster Jackson
• 1.11 Spring是轻量级的Java开发框架。Thunder利用Spring AOP技术实现面向切面的动态代理，通过命名空间的自定义标签解析FactoryBean
• 1.12 Spring Web MVC，Thunder利用它实现和Hessian的整合
• 1.13 Apache Core，Thunder利用它的异步NIO实现服务治理的数据传送
• 1.14 Ebay Jetstream，Thunder利用它实现Web版的服务治理
• 1.15 Google Guava EventBus，Thunder利用它实现事件驱动发布框架内部事件，解除耦合；发布外部事件，进行重试补偿，异常通知(邮件或短信通知)
• 1.16 Splunk或Redis，Thunder利用它实现日志云管理
• 1.17 Nepxion Swing Repository，Thunder利用它实现Java Desktop版的服务治理
• 1.18 Java SPI，Thunder利用它实现相关扩展
• 1.19 Jdeferred Promise，Thunder利用它实现链式调用
• 1.20 Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口，Thunder利用它做容器

2. 功能

• 2.1 框架进程可以既是服务方，又是调用方，两者为一体，互为Server和Client模式，只要在注册中心注册，无论是客户端还是服务端都将是负载均衡的节点。基于上述设计，支持多级以上的调用链方式：纯异步多级调用，纯同步多级调用，先异步后同步多级调用，先同步后异步多级调用，异步多层Callback调用
• 2.2 支持TCP NIO框架(Netty)，TCP MQ消息队列框架(Kafka，ActiveMQ，Tibco)，HTTP(Hessian)的传输方式，支持多线程调用
• 2.3 支持同步调用，异步调用Callback，广播通知方式(点对点的发布订阅模式)，同步调用和异步调用的超时机制
• 2.4 支持基于Spring的简单本地调用方式(显式调用)，达到远程调用的目的，RPC调用
• 2.5 支持服务方应用上下线调用方和服务的自动发现，不用重启调用方应用
• 2.6 支持心跳和自动重连机制
• 2.7 支持应用与注册中心Zookeeper重连机制
• 2.8 支持注册中心的负载均衡的时候，切换到不健康服务方的时候，继续切换功能，并提供尝试切换次数的设定
• 2.9 支持注册中心的负载均衡，一致性Hash(Consistent Hash)算法，权重轮循算法(Round Robin)，随机轮循算法(Random)
• 2.10 支持授权，基于密钥的服务安全访问，跟Hessian自带的安全认证结合在一起，采用双向密钥匹配方式
• 2.11 支持接口调用的版本Version控制，版本不匹配拒绝调用，采用双向版本匹配方式
• 2.12 支持限流，通过令牌刷新方式，可控制单位时间内接口被调用的次数
• 2.13 支持升级后，服务中心持久化对象不一致，版本判断，并重新创建
• 2.14 支持远程配置和调优，管理者可以通过远程配置工具，配置和调优众多分布式的服务提供方和调用方，当然它们既可以使用本地的配置，也可以使用远程配置。业务端可以通过SPI方式自定义远程存储，比如通过外部参数化平台接入的方式，进行存储
• 2.15 支持统计中心的服务依赖情况(SOA治理)。查看服务方接口所在的地址和端口，所走的协议，所属应用，所属组，以及它暴露的接口方法列表，查看其是否启动，可动态刷新；查看调用方的所调用的接口，接入的地址，所走的协议，所属应用，所属组，查看其是否接入，可动态刷新
• 2.16 支持监控中心监控所有的方法调用(耗时、次数、异常等)信息，结合Redis(哨兵模式和集群模式)或者Splunk做动态日志监控，也可以通过第三方WebService分布式接入，做数据统计，通过广播方式，所有接入进来的WebService都将获得统计数据
• 2.17 提供界面化的服务治理，包括分布式的服务方和调用的分布情况，上下线动态刷新，以及令牌控制，密钥控制，版本控制等功能
• 2.18 提供图形化的网络拓扑部署展现
• 2.19 提供图形化的调用链跟踪和异常分析，可基于集成式的Log文件，Redis缓存等数据源
• 2.20 支持五大通信中间件的性能优化，通过独立的配置文件实现，采用局部配置和全局配置的方式，局部配置优先于全局配置
• 2.21 支持MQ(消息队列)在同一个进程中为服务/调用指定不同的MQ服务器
• 2.22 支持MQ(消息队列)指定三种Connection或Session的缓存方式(SingleConnectionFactory，CachingConnectionFactory，PooledConnectionFactory)
• 2.23 支持MQ(消息队列)指定两种初始化方式(JNDI和非JNDI)
• 2.24 支持异步事件驱动发布框架发布事件，进行业务系统的重试补偿，接入框架的所有异常通知(邮件或短信通知)
• 2.25 支持链式调用
• 2.26 支持不同线程池选用的队列类型配置，线程池Reject五大模式的配置。采用多线程池隔离技术，当多个服务部署在同一个JVM，一个服务调用忙，不会影响其它服务调用，业务端可以视具体场景，决定是否要开启线程隔离

3. 压测

压力测试是采用Apache JMeter 2.13，采用Linux服务器作为服务端，Windows7作为压测客户端，采用单机服务器和单机客户机极限压测的方式。相关硬件配置如下：
Linux服务器8核CPU 8G内存

Windows7客户机4核2GHz 8G内存


 压力测试结果

• 3.1 基于Netty的压力测试
  350字节（请求和响应体都有350字节，实际上Thunder内置对象也有将近200字节，所以准确的讲，应该是500字节左右，下同），300个并发，吞吐量每秒23237.4（TPS）
  
  
  
  
  
  
  2K字节（请求和响应体都有2K字节），300个并发，吞吐量每秒15327.2（TPS）
  
  
  16K字节（请求和响应体都有16K字节），300个并发，吞吐量每秒2747.3（TPS）
  
  
  但是如果我们把消息体用Facebook的QuickLz压缩后传送，吞吐量则变成4565.1（TPS），提升还是很大的。一般几十KB到几百KB容量的消息体适合用压缩算法
  
  
  60K字节（请求和响应体都有60K字节），300个并发，吞吐量每秒1560.3（TPS），同上，进行过压缩
  
  
  260K字节（请求和响应体都有260K字节），300个并发，吞吐量每秒334.5（TPS），同上，进行过压缩
  
   
  
• 3.2 基于Kafka的的压力测试，350字节，300个并发，吞吐量每秒18466.6（TPS），考虑到响应值只存储在一个分区里，故性能损耗很大，其它未作详细测试
• 3.3 基于Hessian的压力测试，350字节，300个并发，吞吐量每秒7016.0（TPS），其它未作详细测试
• 3.4 基于Tibco的压力测试，350字节，300个并发，10消费线程，吞吐量每秒8685.0（TPS），50消费线程，吞吐量每秒11353.6（TPS），其它未作详细测试
• 3.5 基于ActiveMQ的压力测试，350字节，300个并发，10消费线程，吞吐量每秒6860.3（TPS），50消费线程，吞吐量每秒7801.8（TPS），其它未作详细测试
• 3.6 跟上述同样的环境，同样的调用接口和数据量的前提下，测试了Dubbo 2.5.3的Netty 3.10.5.Final协议的吞吐量，为11915.5（TPS）
  
   
  

4. 注意

• 4.1 Thunder的部署
  4.1.1 Thunder进程同时只能支持一种通信方式，在Netty，Hessian，Kafka，ActiveMQ，Tibco任选一
  4.1.2 对于Netty，Kafka，ActiveMQ，Tibco，可以独立运行，也可以运行在Web容器里
  4.1.3 对于Hessian，必须运行在Web容器里，需要配置web.xml，把配置文件指向要hessian-servlet.xml。部署的时候，需要把Web Module的名字配置成thunder，如果这样则不需要<thunder:protocol id="protocol" type="hessian" path="/thunder"/>配置path了。如果不想这样，必须在xml配置成对应的Web Module名字
• 4.2 Thunder的负载均衡
  4.2.1 Netty和Hessian属于点对点模式，Thunder提供集群的负载均衡
  4.2.2 Kafka，ActiveMQ和Tibco属于消息队列模式，由MQ服务器自身提供集群的负载均衡
• 4.3 Thunder的服务地址
  4.3.1 五个中间件都需要配置port端口(host一般缺省为localhost)，配置在xml的<thunder:application>节点
  4.3.2 Netty端口任意配置，但当本地运行多个客户端，端口必须不冲突
  4.3.3 Hessian端口必须指向Web容器的端口，比如8080
  4.3.4 Kafka，ActiveMQ和Tibco的地址和端口配置thunder-ext.properties，即ActiveMQ服务器地址。在xml里面仍需配置端口，但任意配置，端口的作用是当本地运行多个客户端，端口作为唯一消息队列的区别码，端口必须不冲突
• 4.4 Thunder发布/订阅功能(广播功能)
  4.4.1 Netty，Hessian是点对点的调用，Thunder采用Redis做发布/订阅功能(广播功能)。如果没配置Redis，Thunder将取注册中心的服务列表，采用循环(Round)方式进行广播
  4.4.2 Kakfa，ActivMQ和Tibco本身具有发布/订阅功能(广播功能)
• 4.5 Thunder调用方法的超时
  4.5.1 Netty，Kafka，ActivMQ和Tibco支持每个调用方法的超时支持，如果在<thunder:reference timeout="xxx">里面没配置，那么会调用thunder.properties获取默认配置，也可以自定义thunder-ext.properties覆盖掉默认的配置
  4.5.2 Hessian受限于其本身技术，不支持每个调用方法的超时，但支持全局的超时机制
• 4.6 Thunder监控
  4.6.1 Netty，Kafka，ActivMQ和Tibco支持后台监控
  4.6.2 Hessian受限于其本身技术，不支持后台监控

评论

5 楼 至尊宝_唯一 2017-03-02  

要是搞个列表能直接跳转到相应的章节就更完美了

4 楼 nepxion 2016-04-02  

birdhur 写道

很不错的框架，值得好好学习，赞

谢谢！最近有增加了一篇链式调用框架，有兴趣可以阅读一下

3 楼 nepxion 2016-04-02  

johnwoocxl 写道

kafka和ActivMQ功能类似，为啥Thunder中都用到了？

不同的应用场景吧，Kafka以高效吞吐量著称，但安全和稳定性似乎还不够，适用于订单，消息推送和日志传输等业务场景，ActiveMQ是基于JMS标准，符合JSM标准的一般非常稳定，API也很友好，但是此类的MQ在吞吐量上会有点折扣。这就印证了一个道理，世界上并没有完美的东西，在技术上也不存在一招鲜，吃遍天的情况。所以同时支持Kafka和ActiveMQ，就是基于这个考虑的。用户换协议很简单，只要在Spring XML的Protocol节点，把type="Kafka"改成type="ActiveMQ"即可，不影响任何业务代码，部署方式，Spring其它逻辑的任何定义

2 楼 johnwoocxl 2016-03-20  

kafka和ActivMQ功能类似，为啥Thunder中都用到了？

1 楼 birdhur 2016-03-13  

很不错的框架，值得好好学习，赞