中间件-服务框架

中间件不是最上层的应用也不是最底层的支撑，是解决特定问题域的一系列组件，是应用和应用之间的桥梁，解决特定场景问题的组件，让开发人员专注与自己的开发。

三类中间件：远程过程调用和对象访问中间件：主要解决分布式环境下应用的相互访问问题，是应用服务化的基础

消息中间件：解决应用中间的消息传递、解耦、异步问题

数据访问中间件：访问数据库的共性问题的组件

分布式系统中的java中间件

支持搜索，缓存，分布式存储的消息中间件

在应用web和中心服务之间的服务框架

数据管理的分布式数据层

用于数据迁移的数据复制迁移层，在数据库底层

软负载中心和持久配置管理是不太直接被业务系统使用但是起到很好支撑作用的系统

1、服务框架的设计与实现

把单层的web应用改成多层的、有服务层的结构时，有些人不会直接做一个通用的服务框架，而是为当前的服务做一个rpc，为用户提供相应的客户端，事实上，当所提供服务的集群大于一个的时候，通用服务框架就非常重要了

将单机实现的程序改写成远程调用模式

重写接口

int add(int a, int b)

{

获取可用服务地址列表

确定要调用服务的目标机器

建立连接

请求序列化

发送请求

接受结果

解析结果

}

一般按照接口名称，版本号和组名称来寻址

如果使用lvs或硬件负载均衡方案，地址就是lvs或负载均衡器的地址，

如果使用名称服务的方式，那么获取可用服务列表就返回当前可用服务的地址，直接和服务器连接，服务命名要注意粒度，一般是完整类名和版本号

对于规则服务器方式，一般运用在有状态场景如数据和缓存用规则服务器寻址，在无状态的服务场景中则不太用规则服务器

服务框架面临两个问题：1、自身部署问题，2、实现自身框架所用的jar和应用自身的jar冲突

问题1解决：方案1把服务框架作为容器的一部分，web应用一般用jboss，tomcat，tetty等作为容器，针对不同的容器有不同的操作可以把服务框架内嵌到容器里

方案2：把服务框架和web应用统一起来作为web应用的依赖包。

jar冲突是指应用依赖的包和框架依赖的包有可能是同一个包的不同版本，造成冲突

clssloader技术是jiava中的一项关键技术，能实现类的隔离，不同的user-defined class loader相互隔离。在web应用中osgi对于不同对的bundle的处理都采用了类似方法

2、远程调用的远程通信问题

一种是lvs或负载均衡器方案，一种是与规则服务器和名称服务器的方式类似，在外面设置一个服务注册查找中心，实现负载均衡

负载均衡的方式一般是随机，轮询和权重（外面熟知的响应时间负载均衡就是权重，按照活动请求的数量做负载均衡）

值得注意的是负载均衡的粒度不只是服务器，还可以是基于接口的，基于方法的，基于参数的。基于参数的方法用的比较少，一般对少数用户采用不同策略的时候会使用

多机房场景也是值得注意的，避免跨机房的调用，可以基于host的负载均衡

流量控制

序列化与反序列化，java自身有调用，如果用其它语言，比如选择http的通信协议，那么可以选xml或json或二进制的序列化方式

网络通信实现的选择，bio，nio，aio

nio下的服务调用方式：

1、oneway：不可靠的连接，只发送不确认

2、callback：回调，通过收到服务提供者的返回后才能实现回调

3、future：先在原线程中执行后相应，是主动调用方式

4、可靠异步：一般是通过消息中间件

oneway是单项通知，callback是被动回调，future主动获取结果，异步能保证异步请求在远程被执行

3、服务提供端的设计

1、如何注册服务

用spring的bean方式注册服务，之后bean把服务注册到服务注册查找中心

2、请求处理流程

服务框架监听端口之后，nio接受请求，协议解析反序列化得到信息，根据其中的服务名称版本号找到提供服务的本地对象，将参数传递到相关方法，实现流程处理

主要不同服务的工作线程池 要隔离，

流量控制：不同来源的服务调用者，01开关和限制具体数值的ops方法。在不同场景，框架有可能面临不同的挑战，因此服务框架必须是模块化的，可修改可扩展

服务升级：如果借口不变，内部改变那么比较方便，用灰度发布的方式验证然后发布就可以了，如果是接口改变那么比较复杂，可以在服务端升级的时候整体改变，可以通过版本号解决，老方法调用老的版本号，新系统使用新的版本号服务，当只有接口的参数列表改变的时候可以考虑参数可扩展，使用map的方式传递参数，但是不是很直观

实战中的优化：

1、服务拆分，服务粒度的划分

2、优雅和实用的平衡，比如破坏原本的结构在客户端设置缓存，提高读写速度

3、分布式环境的请求合并，注意在负载均衡的时候实现一定侧率，使得相近服务能合并