远程服务化的思路整理

这里客户端和远程服务都是具体和业务相关的，比如说会员服务需要独立部署。远程服务框架是要做的工作就是屏蔽具体和远程接口交互的细节，方便调用方进行调用，比如说配上接口名，服务器IP就能实现通信。实际应用中也不会太关心具体的机器IP。假如说会员服务是一个集群服务，那么对于客户端而言并不需要关心具体的IP，它所关心的只有服务，具体路由到哪台机器去处理也将是目标服务需要做的事情。并非客户端去做的事情。
         1.注册中心，注射中心相当于一个管理者，或者说是一些基本的通信信息，比如说接口名，调用方法机器IP，目标机器IP，或者还有端口之类的一些最基本的可以完成通信的一些信息。
         2. 客户 端 （ 代理类 ），其实如果用过Spring的都知道，Spring是可以注入具体的实现类，但是指的是本地方法，如果是远程方法是没有办法直接进行注册的。这里就需要用远程框架进行中转，框架会提供一个本地方法注册到Spring，它屏蔽了和服务机交互的细节，中间用TCP/IP协议是毫无疑问的。

         3.服务端，前面也说了根据TCP/IP协议进行通信是最基本的。既然前面有发送请求的客户端，那么就一定有接收请求的服务端，服务端是和具体服务是在同一台机器。服务端接收到客户端发来的请求（一般是类名，方法名和参数等一些信息）然后调用具体的方法。再回传。这样就完成了一次完整的远程通信。
         4.通信协议， 这里说TCP基本没意义，因为可靠的网络传输协议都是通过这个。但是就像HTTP协议一样是在TCP协议之上封装了一层，我这里所说的意思也就是相当于一个HTTP协议。Java对象传输都需要进行序列化操作，一般不会采用Java自带的序列化，除去序列化的速度慢之外，数据量大小也是一个因素。序列化的速度毫无疑问会影响机器性能。数据量大小对于需要网络传输的服务而言，在一定的带宽下数据量越大肯定会影响影响具体的传输时间。