服务注册与发现¶
基础准备¶
- 使用了什么中间件作为注册中心及其该中间件的优缺点.确保回答“你为什么用某个中间件作为注册中心”的时候,能综合这些优缺点回答
- 注册中心的集群规模(disf?)
- 读写QPS(每秒查询率?是存在本地agent?)
- 机器性能,如CPU和内存
- 最好准备一个注册中心出故障之后你排查和后续优化的案例.
- zookeeper或者etcd了解下?
知道注册中心?¶
-> 回答服务注册与发现基本模型,结合上线,下线解释.+disf支持分组?结合集群或者路由组.
高可用¶
- 服务端崩溃检测
- 注册中心与服务端心跳失败,立即通知客户端服务端不可用
- 注册中心继续心跳避免偶发问题
- 注册中心在心跳失败后,立即重试几次,如果都失败则间隔时间后重试.中间的时间间隔差需要客户端容错
- 客户端容错
- 延迟=注册中心发现服务端崩溃(服务端与注册中心的心跳间隔)+注册中心通知客户端(毫秒级)
- 客户端的组件将节点移除可用列表.等待服务端恢复.如果是与注册中心断开,则客户端考虑整体退出
- 注册中心选型
- 选型考虑AP(服务可用性、分区容错性).
- 选型考虑AP(服务可用性、分区容错性).
负载均衡¶
- 静态负载均衡算法
- 轮询和加权轮询->平滑加权轮询算法(每次选中后,当前权重下降避免加权导致的部分节点负载问题)
- 随机和加权随机(没有轮询算法可控性强)
- 哈希与一致性哈希:哈希的算法选取会严重影响负载均衡效果
- 动态负载均衡算法
- 节点负载评估指标
- 最小连接数
- 最小活跃数
- 最快响应时间
- 大请求带来的服务端节点处理问题
- 解法:业务拆分(做请求限制)和隔离(不同请求不同机房)
- 加权算法都需要成加败减,需要设计好上下限.避免溢出或者永远不可选中.
- 哈希一致性结合本地缓存能提高缓存的命中率,但是服务上线会因为节点变动无法命中.
熔断¶
- 什么是熔断
- 在微服务架构中服务本身出现问题的时候,拒绝新的请求,直到服务恢复
- 为什么需要熔断
- 在服务高负载或者服务不可用/缓存崩溃的时候,给系统恢复的时间
- 服务不再接受新请求,负载降低,线程池减少,防止服务雪崩
- 服务崩溃时情况下恢复服务
- 上游收到下游熔断信息,进行兜底方案处理(业务补偿/请求转发…)
- 在服务高负载或者服务不可用/缓存崩溃的时候,给系统恢复的时间
- 熔断开启
- 判断健康状态
- 选择业务指标
- 微服务的划分依据业务职责和边界来划分,如响应时间的99线,错误率
- 设置合理阈值
- 业务要求指标阈值设置
- 服务整体指标设置
- 多久触发熔断
- 一般不是立即熔断,而是一段时间后熔断
- 防止指标偶发性增长
- 防止服务抖动
- 持续时间的设置依赖经验,比如30s
- 一般不是立即熔断,而是一段时间后熔断
- 选择业务指标
- 判断恢复
- 现状: 大多数是触发熔断后一段时间就认为服务已恢复
- 问题: 服务抖动
- 解法:
- 服务端控制流量:恢复服务后,试探性逐级恢复流量,不要直接100%流量
- 客户端控制流量(相对更优):熔断后节点摘流.,一段时间后尝试请求,如正常处理可恢复流量占比.所有节点熔断,告警.
- 判断健康状态
降级¶
- 降级与熔断的区别
- 熔断: 不提供服务,服务负载立即下降
- 降级: 提供有损服务,服务负载缓慢下降
- 跨服务降级
- 整个服务down
- 停掉服务部分节点
- 停止访问部门资源
- 服务本身降级
- 返回默认值,例如nx中默认返回责任命中911直接返回兜底
- 禁用mertric或者可观察性组件
- 同步转异步,后续通过开启额外线程或者定时任务来处理
- 简化流程
- 在任何故障处理面前都要考虑恢复策略会不会导致抖动
- 读写服务降级写服务,保障读服务更重要的场景.虽然写服务的qps低,但是对性能的压力要远大于读请求
