服务框架

为什么使用服务框架：应用直接访问底层的服务（数据库，缓存，分布式文件系统，搜索引擎等）足够解决问题，比如商品模块访问底层服务，交易模块访问底层服务，它们都会用到用户相关的功能，会有很多代码冗余且不利于管理。在应用和底层间添加服务，可以使结构更为清晰，提高稳定性，避免代码冗余。

服务框架的设计和实现：
本地调用变为远程调用：服务框架客户端从上到下依次为：接口调用，寻址路由，编码，通信，服务端从下到上依次为：通信，解码，实例定位，服务调用。
客户端实现过程：
获取可用服务地址列表和确定要调用的目标机器：这可以借助控制器实现。
构造请求数据包，也就是将对象变为二进制数据，也就是常说的序列化。
利用Socket通信，把序列化后的数据发送过去。等待远程服务的调用以及结果的返回。
反序列化，得到执行结果。
服务端实现过程：
持续接受请求并处理：
对于接收到的数据，首先进行反序列化得到请求对象，从而得到服务名称，服务版本号，需要调用的方法以及参数，以及调用的连接。
定位服务，根据服务注册表得到具体的实例，进行服务调用，通过反射实现。
序列化后返回。

服务调用端的具体设计和实现：
确定服务框架的使用方式：通过Spring配置客户端Bean，因为JAVA有动态代理的支持，因此可以使用一个通用的对象。在具体调用发起时，其实时调用了Bean为具体接口产生的一个动态代理对象。该动态代理对象在被调用后会进行如同服务请求方的处理，完成寻址等工作。
存在问题：
服务框架的部署问题：一是把服务框架作为应用的一个依赖包，如果升级服务框架需要更新应用。二是把服务框架作为容器的一部分，例如针对JBOSS，可以通过MBean实现服务框架的启动，将其部署为一个sar包来为应用提供服务。
jar包冲突问题：将服务框架自身用到的类和应用用到的类都控制在User-Defined ClassLoader级别，这样就实现了相互间的隔离。
服务调用者和提供者间通信方式的选择：控制器的实现。
序列化反序列化的实现：可以使用java序列化，也可以使用XML作为序列化方式。
网络通信实现选择：
同步方式调用NIO，
异步服务调用方式：
OneWay：只管发送请求不关心结果；
CallBack：请求方发送请求后会继续执行自己的操作，等对方有响应时进行回调；
Future：跟CallBack差不多，但是能主动控制超时，获取结果。
可靠异步：保证异步请求能在远程被执行，一般通过消息中间件来完成。

服务提供端的设计和实现：
通过Spring暴露为远程服务。