服务框架

2019独角兽企业重金招聘Python工程师标准>>>

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

• 代码臃肿复杂

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

服务化框架设计与实现：

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

• 调用者实现

• 服务端实现

服务框架俩重要问题：

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更多考虑不同厂商提供服务的整合

总结：：：

 

转载于:https://my.oschina.net/u/3847203/blog/2870122