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

Nepxion Thunder （QQ 1394997）发布在淘宝代码基地 http://code.taobao.org/p/Thunder/

 

1. 概要

• 1.1 Thunder是基于Netty + Hessian + Kafka + ActiveMQ + Tibco + Zookeeper(Curator Framework) + Redis + FST + Spring + Spring Web MVC分布式RPC调用框架。架构思想主要是来自阿里巴巴的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)实现的Java快速对象序列化的开发包。序列化速度更快(2-10倍)、体积更小，而且兼容 JDK 原生的序列化
• 1.10 Spring是轻量级的Java开发框架。Thunder利用Spring AOP技术实现面向切面的动态代理，通过命名空间的自定义标签解析FactoryBean
• 1.11 Spring Web MVC，Thunder利用它实现和Hessian的整合
• 1.12 Apache Core，Thunder利用它的异步NIO实现服务治理的数据传送
• 1.13 Ebay Jetstream，Thunder利用它实现Web版的服务治理
• 1.14 Google Guava EventBus，Thunder利用它实现事件驱动发布框架内部事件，解除耦合
• 1.15 Splunk或Storm，Thunder利用它实现日志云管理
• 1.16 Nepxion Swing Repository，Thunder利用它实现Java Desktop版的服务治理
• 1.17 Java SPI，Thunder利用它实现服务发现

2. 功能

• 2.1 Thunder进程又是服务方，也是调用方，互为Server和Client模式，只要在注册中心注册，无论是客户端还是服务端都将是负载均衡的节点
• 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 支持远程配置和调优，管理者可以通过远程配置工具，配置和调优众多分布式的服务提供方和调用方，当然它们既可以使用本地的配置，也可以使用远程配置
• 2.15 支持统计中心的服务依赖情况(SOA治理)。查看服务方接口所在的地址和端口，所走的协议，所属应用，所属组，以及它暴露的接口方法列表，查看其是否启动，可动态刷新；查看调用方的所调用的接口，接入的地址，所走的协议，所属应用，所属组，查看其是否接入，可动态刷新
• 2.16 支持监控中心监控所有的方法调用(耗时、次数、异常等)信息，结合Splunk做动态日志监控，也可以通过第三方WebService分布式接入，做数据统计，通过广播方式，所有接入进来的WebService都将获得统计数据
• 2.17 提供界面化的服务治理，包括分布式的服务方和调用的分布情况，上下线动态刷新，以及令牌控制，密钥控制，版本控制等功能
• 2.18 提供图形化的网络拓扑部署展现
• 2.19 提供图形化的调用链跟踪和异常分析
• 2.20 支持五大通信中间件的性能优化，通过独立的配置文件实现，采用局部配置和全局配置的方式，局部配置优先于全局配置
• 2.21 支持MQ(消息队列)在同一个进程中为服务/调用指定不同的MQ服务器
• 2.22 支持MQ(消息队列)指定三种Connection或Session的缓存方式(SingleConnectionFactory，CachingConnectionFactory，PooledConnectionFactory)
• 2.23 支持MQ(消息队列)指定两种初始化方式(JNDI和非JNDI)
• 2.24 支持MQ(消息队列，主要是Kafka)的异步事件驱动发布框架内部事件

3. 压测

• 3.1 基于Netty的通讯，用Apache JMeter工具测试单机版，150并发，可以达到吞吐量28000/sec
• 3.2 基于Hessian的通信，用Apache JMeter工具测试单机版，150并发，可以达到吞吐量6800/sec
• 3.3 基于Kafka的通信，用Apache JMeter工具测试单机版，150并发，可以达到吞吐量13000/sec

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受限于其本身技术，不支持后台监控