高可用设计之逻辑层

逻辑层职责
整个系统中的业务逻辑处理


逻辑层整体架构
逻辑层业务多
业务逻辑复杂
逻辑层如何设计
All in one 方式
所有业务一个整体
一个文件里
一个类里

All in one 方式有什么问题
文件太复杂
耦合性严重
开发代价高
维护代价高
牵一发动全身
适用场合
创业期
业务不复杂

All in one (业务垂直划分)方式
业务垂直划分
一个单独业务一个组件
优点
业务独立
耦合性降低
业务之间开发互不影响
开发效率高
运维相对简单
缺点
物理上一个模块
编译成本高
一个业务修改 重新上线
重启影响所有业务
使用场景
互联网公司使用较多
58
百度

业务间物理垂直划分方式
每个业务一个独立的业务模块
优点
业务完全解耦
业务互补影响
业务模块独立
单独开发 上线 运维
效率高

什么是无状态
系统不存储业务的上下文信息
仅根据每次请求携带数据进行相应的业务逻辑处理
多个模块(子系统)之间完全对称
请求提交到任何服务器 处理结果都是完全一样

关键因素
业务逻辑层不保存请求状态
业务逻辑层不保存数据
所有业务逻辑层服务器完全对称
当一台或多台宕机
请求提交到集群中的任意可用服务器
业务逻辑层高可用
实现高可用关键因素是什么?
负载均衡
服务器状态实时监测机制
自动转移失败任务(机器)机制
请求量和数据量较高,将流量和数据分摊到集群中多台服务器的能力
通过心跳机制发现下游服务器不可用 剔除掉
一旦服务器不可用 可以自动重连恢复


纯异步调用
什么是同步
发出一个请求调用时,在没有得到结果之前,该调用就不返回
调用者(线程)阻塞模式
什么是异步
异步调用发出后,调用者立即返回.结果完成后,通过状态、通知
和回调通知调用者
调用者(线程)非阻塞模式

优点
线程非阻塞,一直Running,CPU利用率高,系统性能高
系统吞吐量高

缺点
实现成本稍高

如何异步调用
消息队列方案一
通过消息队列(缓冲、持久化、解决异步)实现异步调用


异步调用场景
I/O
特别是网路I/O
轮询非阻塞I/O模型
I/O复用模型

高性能纯异步网络调用设计
server端连接池 server端收发队列;
client端连接池 client端收发队列;
超时队列与超时管理器
上下文管理器+状态机

业务逻辑层如何分级管理?
硬件分级层面
核心系统使用好的机器
-CPU、内存、磁盘、网卡
边缘系统使用差的机器

部署层面
服务部署隔离
避免故障带来的连锁反应
核心系统部署在物理机上
核心系统部署在不同的机房
边缘系统部署在虚拟机
边缘系统公用机器

分级管理
监控分级层面
核心服务更多类型的监控
-进程
-语义
-错误日志

监控粒度更细致

邮件和短信发送通知

响应分级层面
核心服务开发响应速度
核心服务上线响应速度
核心服务运维响应速度
核心服务上线问题处理速度

设置合理超时
业务逻辑层和下游模块交互次数多
设置合理超时非常重要
下游服务宕机、线程死锁等,请求得不到响应
请求占用资源
调用方得不到响应,用户体验糟糕

业务逻辑层服务降级设计
网站高峰期,并发量大
服务能力有限
性能下降
服务跌宕
系统雪崩情况
怎么办?
服务降级

业务逻辑层服务降级设计
保证核心服务可用
非核心服务弱可用,甚至不可用
降级设计方案
拒绝部分请求
关闭请求

业务逻辑层如何做到幂等设计?
请求失败后会继续重试
保证服务重复调用和一次调用结果相等(幂等性)

服务器幂等设计
天然幂等
例如离线消息设置已读
非幂等>幂等
支付
转账