服务框架

服务框架：解决应用服务化问题

• 代码臃肿复杂

• 拆分后，数据库链接还在，存在重复代码

服务化框架设计与实现：

• 规则器
• 软硬负载均衡
• 名称服务

• 调用者实现

• 服务端实现

服务框架俩重要问题：

1. 自身部署问题
   • 方案一：服务框架做为应用依赖jar 包一块儿打包
   • 方案二：服务框架做为容器一部分  
   • 方案三：服务框架做为容器来部署应用
2. 自身的jar 包和应用的jar 包冲突问题
   • 服务框架和应用各自独立的ClassLoader，这样jar 包被隔离

• 远程通讯

• 集群方案

• 中间代理来解决远程服务调用

• 控制器的方式解决远程服务调用

• 基于接口、方法、参数的路由

• 路由规则集中管理，将不一样的接口路由到不一样的服务器
  • 能够在细分，基于具体方法路由

• 同城机房

• java 自己的序列化
  • 存在性能问题和跨语言问题
• 能够考虑使用json、xml、二进制流序列化

网络通讯实现选择

• IO线程专门负责和socket 打交道
• 请求线程把数据放入数据队列后，产生通讯对象放入通讯队列，而且在队列上等待
• 通讯对象在超时前有返回对象会唤醒请求线程
• 定时任务负责处理超时请求

支持多种异步服务调用方式

• oneway方式异步调用
  • 单向通知
• 不关心是否返回数据

• callback 方式异步调用
  • callback 的执行不在原请求线程中
• 请求发送后继续执行本身的程序，设置回调

• Future 模式异步调用
  • 请求执行结果仍在原线程中

• 可靠方式异步调用
  • 须要保证异步请求在远端被执行，通常经过消息中间件保证

一个请求调用多个远程服务

• 变成并行服务（Future 模式）

服务提供端

• 服务端工做包括
  • 对本地服务的注册管理
  • 根据进来的请求定位服务并执行

•  

• 执行不一样服务的线程池隔离

服务升级

• 接口中增长方法
• 接口中某些方法修改调用参数列表
  • 应对方式：
    1. 对使用原来方法代码都进行修改，而后和服务端一块儿发布
       • 不太可行
    2. 经过版本号解决
       • 比较经常使用，调取根据版本号，互不影响
    3. 设计方法上考虑方法的扩展性
       • 会使得参数校验过于复杂
• 有了服务框架，集中式系统很容易变成分布式框架

• 分布式环境请求合并

• 引入分布式须要解决新的问题

服务治理

• 管理服务
  • 管理须要去操纵、控制整个分布式系统中的服务
• 查看服务
  • 看运行时的状态，或一些具体信息、历史数据等

ESB 和服务框架区别

1. 服务框架是点对点模型；ESB是总线模型
2. 服务框架基本上面对的都是同构的系统，不须要考虑整合
   • ESB更多考虑不一样厂商提供服务的整合

总结：：：