微服务架构设计模式-（11）查询

两种模式

• API组合模式
  • 调用多个服务获取数据，再组合成想要的
  • 实现
    • API组合由前端完成
      • 前端直接调用多个服务，查询信息
      • 前端太重了
    • API组合由网关完成
    • API组合作为一个独立的服务
  • 好处
    • 简单直观
  • 弊端
    • 增加额外开销
    • 可用性降低
      • 因为要调用多个服务，每个服务的可用性为99.5%，那么如果要聚合4个服务的数据，组合器的服务可用性就变成了97.5%了（0.995^5，它自己也是一个服务）
      • 如果想要提高可用性，那么就是把某些服务变成非阻塞的了
        • 就是有一个服务不可用了，就不管了，返回不完整的数据。这样用户页面上还可以显示其他有用的信息，不至于直接报错。
          • 当然，这个服务不可用的情况可以通过监控报警通知到维护人员
    • 缺乏事务数据的一致性
      • 事务执行过程中，查询，有的部分已经更新，有的还没更新
• CORS模式
  • 命令查询职责分离
  • 使用事件维护从多个数据库复制过来的只读视图，用于查询
  • 好处
    • 高效
      • 不用像API组合那样消耗内存、网络
    • 不同类型的查询实现
      • 比如说有个服务使用了nosql的数据库，不能很好的支持查询。那么这时候用CQRS建一个专用查询数据库，就能很好的解决这问题
        • 还比如，把mysql的json数据解析到查询数据库的字段中。
    • 事件溯源查询
      • 事件中存放的信息是放在event_data的json中的，不利于查询，职能查询事件ID或聚合ID。使用CQRS构造一个或多个最新的视图，可以很好的查询
    • 隔离
      • 将命令和查询隔离
  • 弊端
    • 复杂架构
    • 需要处理数据复制导致的延迟
      • 如何解决
        • 让客户端记录下最新的事件ID标记
        • 然后查询的时候带上，如果查询视图还没有更新，就查不到这个ID，那么报错
        • 因为职能保证数据最终一致。