服务框架:解决应用服务化问题
- 代码臃肿复杂
- 拆分后,数据库连接还在,存在重复代码
服务化框架设计与实现:
- 规则器
- 软硬负载均衡
- 名称服务
- 调用者实现
- 服务端实现
服务框架俩重要问题:
- 自身部署问题
- 方案一:服务框架作为应用依赖jar 包一起打包
- 方案二:服务框架作为容器一部分
- 方案三:服务框架作为容器来部署应用
- 自身的jar 包和应用的jar 包冲突问题
- 服务框架和应用各自独立的ClassLoader,这样jar 包被隔离
- 远程通信
- 集群方案
- 中间代理来解决远程服务调用
- 控制器的方式解决远程服务调用
- 基于接口、方法、参数的路由
- 路由规则集中管理,将不同的接口路由到不同的服务器
- 可以在细分,基于具体方法路由
- 同城机房
- java 本身的序列化
- 存在性能问题和跨语言问题
- 可以考虑使用json、xml、二进制流序列化
网络通信实现选择
- IO线程专门负责和socket 打交道
- 请求线程把数据放入数据队列后,产生通信对象放入通信队列,并且在队列上等待
- 通信对象在超时前有返回对象会唤醒请求线程
- 定时任务负责处理超时请求
支持多种异步服务调用方式
- oneway方式异步调用
- 单向通知
- 不关心是否返回数据
- callback 方式异步调用
- callback 的执行不在原请求线程中
- 请求发送后继续执行自己的程序,设置回调
- Future 模式异步调用
- 请求执行结果仍在原线程中
- 可靠方式异步调用
- 需要保证异步请求在远端被执行,一般通过消息中间件保证
一个请求调用多个远程服务
- 变成并行服务(Future 模式)
服务提供端
- 服务端工作包括
- 对本地服务的注册管理
- 根据进来的请求定位服务并执行
- 执行不同服务的线程池隔离
服务升级
- 接口中增加方法
- 接口中某些方法修改调用参数列表
- 应对方式:
- 对使用原来方法代码都进行修改,然后和服务端一起发布
- 不太可行
- 通过版本号解决
- 比较常用,调取根据版本号,互不影响
- 设计方法上考虑方法的扩展性
- 会使得参数校验过于复杂
- 对使用原来方法代码都进行修改,然后和服务端一起发布
- 应对方式:
- 有了服务框架,集中式系统很容易变成分布式框架
- 分布式环境请求合并
- 引入分布式需要解决新的问题
服务治理
- 管理服务
- 管理需要去操纵、控制整个分布式系统中的服务
- 查看服务
- 看运行时的状态,或一些具体信息、历史数据等
ESB 和服务框架区别
- 服务框架是点对点模型;ESB是总线模型
- 服务框架基本上面对的都是同构的系统,不需要考虑整合
- ESB更多考虑不同厂商提供服务的整合
总结:::