用到的技术以及第三方框架jar

spring 的自定义复杂bean

guava.jar

ioc ,aop ,动态代理  反射，多线程

netty

知识点

spring 自定义复杂bean 

1.ClassPathXmlApplicationContext 

2.自定义xsd

3.配置spring.handlers和spring.schemal

4.在spring.handlers找到相应的NettyNameHandler,进行初始化

5.调相应的方法NettyServicePaser,NettyRegisterPaser和NettyRefence

6.通过初始化把相关的bean通过反射和动态代理实现Netty的通讯

7.通讯时把相关类的信息，方法，参数，参数值通过encode，传到服务端，服务端调解码

得到相应的结果进行交互

客户端定义复杂bean实现接口FactoryBean

8.guava

反射方法： Reflection.newProxy(PersonManage.class, new MessageSendProxy<T>());

  ExecutorCompletionService<Boolean> completionService = new ExecutorCompletionService<Boolean>(executor);
                            completionService.submit(new ApiEchoResolver(host, echoApiPort));

guava线程池.submit 会掉里面的call方法

  private static ListeningExecutorService threadPoolExecutor = MoreExecutors.listeningDecorator((ThreadPoolExecutor) RpcThreadPool.getExecutor(threadNums, queueNums));

10，有多少秒过期，重连机制

ListenableFuture的说明 

　　并发编程是一个难题，但是一个强大而简单的抽象可以显著的简化并发的编写。出于这样的考虑，Guava 定义了 ListenableFuture接口并继承了JDK concurrent包下的Future 接口，ListenableFuture 允许你注册回调方法(callbacks)，在运算（多线程执行）完成的时候进行调用,  或者在运算（多线程执行）完成后立即执行。这样简单的改进，使得可以明显的支持更多的操作，这样的功能在JDK concurrent中的Future是不支持的。 在高并发并且需要大量Future对象的情况下，推荐尽量使用ListenableFuture来代替..

　　ListenableFuture 中的基础方法是addListener(Runnable, Executor), 该方法会在多线程运算完的时候，在Executor中执行指定的Runnable。

ListenableFuture的创建和使用

　　对应JDK中的 ExecutorService.submit(Callable) 提交多线程异步运算的方式，Guava 提供了ListeningExecutorService 接口, 该接口返回 ListenableFuture， 而相应的ExecutorService 返回普通的 Future。将 ExecutorService 转为 ListeningExecutorService，可以使用MoreExecutors.listeningDecorator(ExecutorService)进行装饰。举例说明：

    static CountDownLatch Latch =null; //线程计数器 

   //开始计时
        StopWatch sw = new StopWatch();

倒计时可以算执行多少秒

netty 对accpet的channel进行多个预处理直接通过。addLast().addLast

1、定义RPC请求消息、应答消息结构，里面要包括RPC的接口定义模块、包括远程调用的类名、方法名称、参数结构、参数值等信息。

　　2、服务端初始化的时候通过容器加载RPC接口定义和RPC接口实现类对象的映射关系，然后等待客户端发起调用请求。

　　3、客户端发起的RPC消息里面包含，远程调用的类名、方法名称、参数结构、参数值等信息，通过网络，以字节流的方式送给RPC服务端，RPC服务端接收到字节流的请求之后，去对应的容器里面，查找客户端接口映射的具体实现对象。

　　4、RPC服务端找到实现对象的参数信息，通过反射机制创建该对象的实例，并返回调用处理结果，最后封装成RPC应答消息通知到客户端。

　　5、客户端通过网络，收到字节流形式的RPC应答消息，进行拆包、解析之后，显示远程调用结果。

　　上面说的是很简单，但是实现的时候，我们还要考虑如下的问题：

　　1、RPC服务器的传输层是基于TCP协议的，出现粘包咋办？这样客户端的请求，服务端不是会解析失败？好在Netty里面已经提供了解决TCP粘包问题的解码器：LengthFieldBasedFrameDecoder，可以靠它轻松搞定TCP粘包问题。

　　2、Netty服务端的线程模型是单线程、多线程（一个线程负责客户端连接，连接成功之后，丢给后端IO的线程池处理）、还是主从模式（客户端连接、后端IO处理都是基于线程池的实现）。当然在这里，我出于性能考虑，使用了Netty主从线程池模型。

　　3、Netty的IO处理线程池，如果遇到非常耗时的业务，出现阻塞了咋办？这样不是很容易把后端的NIO线程给挂死、阻塞？本文的处理方式是，对于复杂的后端业务，分派到专门的业务线程池里面，进行异步回调处理。

　　4、RPC消息的传输是通过字节流在NIO的通道（Channel）之间传输，那具体如何实现呢？本文，是通过基于Java原生对象序列化机制的编码、解码器（ObjectEncoder、ObjectDecoder）进行实现的。当然出于性能考虑，这个可能不是最优的方案。更优的方案是把消息的编码、解码器，搞成可以配置实现的。具体比如可以通过：protobuf、JBoss Marshalling方式进行解码和编码，以提高网络消息的传输效率。

　　5、RPC服务器要考虑多线程、高并发的使用场景，所以线程安全是必须的。此外尽量不要使用synchronized进行加锁，改用轻量级的ReentrantLock方式进行代码块的条件加锁。比如本文中的RPC消息处理回调，就有这方面的使用。

　　6、RPC服务端的服务接口对象和服务接口实现对象要能轻易的配置，轻松进行加载、卸载。在这里，本文是通过Spring容器进行统一的对象管理。

总体流程

Netty 流程