微服务拆分

这是一篇关于微服务拆分的思维导图，从故障隔离、优化与测试、微服务化、服务监控、缓存等方面进行了分析和概述。

jingang.wu的开发总结

• 故障隔离
  • 系统或资源，故障发生时，限定传播范围和影响范围
  • 种类
    • 线程隔离
      • 请求分类，不同的线程池处理
    • 进程隔离
      • 拆分多个子系统进行物理隔离，系统之间互不影响
    • 读写分离
• 优化与测试
  • 代码优化
    • for是否合理，不要在循环里调RPC，分布式缓存，执行sql等
      • 先调批量接口组装好数据，再循环处理
    • 数据库优化
      • mysql尽量使用NotNull类型，Mysql手册允许为Null的类型需要额外的空间去处理Null，且不易优化
  • 压测
    • 工具
      • Jmeter
      • Apache ab
• 微服务化
  • 单体架构
    • 特点
      • 交付缓慢
        • 程序难以理解、维护和测试，开发效率低
      • 充满故障的交付
        • 经常出错
      • 可扩展性差
  • 微服务架构
    • 特点
      • 可维护性
      • 可测试性
      • 可部署性
      • 可扩展性
      • 故障隔离
      • 加速开发
  • 微服务化
    • 绞杀单体应用
      • 重构而非推导重来，风险极高
    • 模式
      • 绞杀者应用模式（Martin Fowler） https://microservices.io/patterns/refactoring/strangler-application.html
    • 策略
      • 新功能实现为服务
      • 隔离表现层和后端
      • 提取功能到服务中来分解单体
• 服务监控
  • 问题
    • 业务服务假死，但心跳还在？
      • zk发现不了，服务熔断（单独线程统计 错误量+超时量/总量>30%认为错误，干桌连接）
• 缓存
  • 模式
    • Cache Aside
      • 缓存未命中时，从db中获取填充缓存
      • db更新时，缓存先失效（双失效保证）
    • Cache-As-SoR(System of Record, 数据源)
      • Read-Through
      • Write-Through
        • 穿透写模式/直写模式
      • Write-Behind
  • 缓存粒度
    • 因素
      • 数据更新频率
      • 数据访问频率
      • 时效性
        • 要求不高的很适合缓存
        • 要求很高的只能从数据库里获取
          • 如商品服务对商品进行缓存，但db的更新与缓存的更新不是同一个事务，交易时，只能从db里获取商品信息
    • 如何设置缓存
      • 单实例（优先）
      • 集合类（看场景）
        • 几乎不变的小集合可以缓存
      • 跨表（禁止）
        • 分拆几部分缓存，更灵活
    • 场景
      • 1 用户权限
        • user-resource: permissions粒度比较合适
        • 权限的时效性
          • 用户更新了权限后没有立即反应，算不算
      • 2 项目成员列表
        • 不适合缓存
          • for each(cache)禁止：极端的情况的全员获取，性能极差
          • 项目成员的变化高频
  • 缓存清理（最终一致性保证）
    • 同步清理
      • 双失效保证（最终一致性）
    • 异步清理
      • 本地事务表
      • db数据更新事件定阅
    • 定时清理