Java分布式开发

　　分布式概念的引入是基于性能的提升，应用的可靠性而提出的。所谓Java分布式，即是在使用Java语言进行企业级应用开发的过程中，采用分布式技术解决业务逻辑的高并发、高可用性的一些架构设计方案。

1. RPC技术介绍

　　  我们知道Web Servie实现了服务器端如何向客户端提供服务。常见的三种方法：RPC 所谓的远程过程调用(面向方法)；SOA所谓的面向服务的架构(面向消息)；REST所谓的Representational state transfer(面向资源)。如果说RPC是基于方法调用，那么SOA则是基于消息,基于方法调用通常会与特定的程序语言耦合起来,而后者则与具体的实现语言无关,所以在一定程度上得到大公司的支持。

　　RPC（Remote Procedure Call Protocol),远程过程调用协议。它是一种协议，程序可使用这种协议向网络中的另一台计算机上的程序请求服务，由于使用RPC的程序不必了解支持通信的网络协议的情况，因此RPC提高了程序的互操作性。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。通俗的说，使用了RPC服务之后，就可以像调用一个本地方法一样去调用一个运行于网络中的其他计算机的方法。

上图是windows中的RPC服务调用，可以在windows系统中的服务选项中查看到。当前使用RPC协议的技术有很多，如阿里巴巴的hsf、dubbo（开源）、Facebook的thrift（开源）、Google grpc（开源）、Twitter的finagle（开源）等。在大型互联网公司，公司的系统都由成千上万大大小小的服务组成，各服务部署在不同的机器上，由不同的团队负责。我们在开发一个服务的时候面临两个问题：1）要搭建一个新服务，免不了需要依赖他人的服务，而现在他人的服务都在远端，怎么调用？2）其它团队要使用我们的新服务，我们的服务该怎么发布以便他人调用？

上图所示是RPC调用的详细流程图

1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。
　　RPC的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。

在RPC中，怎么做到透明化远程服务调用？怎么封装通信细节才能让用户像以本地调用方式调用远程服务呢？对java来说就是使用代理！java代理有两种方式：1） jdk 动态代理；2）字节码生成。尽管字节码生成方式实现的代理更为强大和高效，但代码维护不易，大部分公司实现RPC框架时还是选择动态代理方式。

/**
* 服务提供方
**/
public interface SMSService {
     String sendSMS(String msg);
}

public class SMSServiceImpl implements SMSService {
     @Override
     public String sendSMS(String msg) {
         String result = “您好，” + msg + "测试短信，勿回复。 " ;
         System.out.println(result);
         return result;
     }
}

/**
* 服务消费方
**/
public class Test {
2     public static void main(String[] args) {
3         SMSService smsService = new SMSServiceImpl ();
4         smsService.sendSMS("Sucre");
5     }
6 }

下面简单介绍下动态代理怎么实现我们的需求。我们需要实现RPCProxyClient代理类，代理类的invoke方法中封装了与远端服务通信的细节，消费方首先从RPCProxyClient获得服务提供方的接口，当执行smsService.sendSMS("Sucre")方法时就会调用invoke方法。

public class RPCProxyClient implements java.lang.reflect.InvocationHandler{
     private Object obj;
 
     public RPCProxyClient(Object obj){
         this.obj=obj;
     }
 
     /**
      * 得到被代理对象;
      */
     public static Object getProxy(Object obj){
         return java.lang.reflect.Proxy.newProxyInstance(obj.getClass().getClassLoader(),
                 obj.getClass().getInterfaces(), new RPCProxyClient(obj));
     }
 
     /**
      * 调用此方法执行
      */
     public Object invoke(Object proxy, Method method, Object[] args)
             throws Throwable {
         //结果参数;
         Object result = new Object();
         // ...执行通信相关逻辑
         // ...
         return result;
     }
}

 public class Test {
    public static void main(String[] args) {
        SMSService smsService = (SMSService)RPCProxyClient.getProxy(SMSService.class);
        smsService.sendSMS("Sucre");
    }
}

　　在invoke方法中，需要封装通信细节，而通信的第一步就是要确定客户端和服务端相互通信的消息结构。客户端的请求消息结构一般需要包括以下内容：接口名称，在我们的例子里接口名是“SMSService”，如果不传，服务端就不知道调用哪个接口了；方法名，一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法；参数类型&参数值，参数类型有很多，比如有bool、int、long、double、string、map、list，甚至如结构体；以及相应的参数值；超时时间；requestID。同理服务端返回的消息结构一般包括以下内容：返回值、状态code、requestID。

　　一旦确定了消息的数据结构后，下一步就是要考虑序列化与反序列化了。什么是序列化？序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程。什么是反序列化？将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程。为什么需要序列化？转换为二进制串后才好进行网络传输嘛！为什么需要反序列化？将二进制转换为对象才好进行后续处理！现如今序列化的方案越来越多，每种序列化方案都有优点和缺点，它们在设计之初有自己独特的应用场景，那到底选择哪种呢？从RPC的角度上看，主要看三点：1）通用性，比如是否能支持Map等复杂的数据结构；2）性能，包括时间复杂度和空间复杂度，由于RPC框架将会被公司几乎所有服务使用，如果序列化上能节约一点时间，对整个公司的收益都将非常可观，同理如果序列化上能节约一点内存，网络带宽也能省下不少；3）可扩展性，对互联网公司而言，业务变化飞快，如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提供系统的灵活度。目前互联网公司广泛使用Protobuf、Thrift、Avro等成熟的序列化解决方案来搭建RPC框架，这些都是久经考验的解决方案。

　　消息数据结构被序列化为二进制串后，下一步就要进行网络通信了。目前有两种常用IO通信模型：1）BIO；2）NIO。一般RPC框架需要支持这两种IO模型。如何实现RPC的IO通信框架呢？1）使用java nio方式自研，这种方式较为复杂，而且很有可能出现隐藏bug，但也见过一些互联网公司使用这种方式；2）基于mina，mina在早几年比较火热，不过这些年版本更新缓慢；3）基于netty，现在很多RPC框架都直接基于netty这一IO通信框架，省力又省心，比如阿里巴巴的HSF、dubbo，Twitter的finagle等。

　　如何发布自己的服务：如何让别人使用我们的服务呢？有同学说很简单嘛，告诉使用者服务的IP以及端口就可以了啊。确实是这样，这里问题的关键在于是自动告知还是人肉告知。人肉告知的方式：如果你发现你的服务一台机器不够，要再添加一台，这个时候就要告诉调用者我现在有两个ip了，你们要轮询调用来实现负载均衡；调用者咬咬牙改了，结果某天一台机器挂了，调用者发现服务有一半不可用，他又只能手动修改代码来删除挂掉那台机器的ip。现实生产环境当然不会使用人肉方式。有没有一种方法能实现自动告知，即机器的增添、剔除对调用方透明，调用者不再需要写死服务提供方地址？当然可以，现如今zookeeper被广泛用于实现服务自动注册与发现功能。简单来讲，zookeeper可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者。

具体来说，zookeeper就是个分布式文件系统，每当一个服务提供者部署后都要将自己的服务注册到zookeeper的某一路径上:

 /{service}/{version}/{ip:port}

比如我们的SMSService部署到两台机器，那么zookeeper上就会创建两条目录：分别为

/SMSService/1.0.0/100.19.20.01:16888
/SMSService/1.0.0/100.19.20.02:16888

zookeeper提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 Socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除，比如100.19.20.02这台机器如果宕机了，那么zookeeper上的路径就会只剩

/HelloWorldService/1.0.0/100.19.20.01:16888

服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方服务提供者地址列表已经发生改变，从而进行更新。更为重要的是zookeeper与生俱来的容错容灾能力（比如leader选举），可以确保服务注册表的高可用性。

2. RMI技术介绍

3. Restful API方式

4. Filter是基于回调函数，而拦截器是基于动态代理

博文参考：

[1] http://www.cnblogs.com/LBSer