服务可靠性

• 网络的可靠性

  • 机器之间通过物理连接传输信息，容易出现一些异常状况

    • 数据丢失
      • 一个数据包 可能到达一个 缓冲区被塞满的 路由器，被丢弃
    • 顺序出错
      • 一组数据包 可能途径 多个路由器，出现不同程度的延迟，最后到达顺序会和出发时不一致

  • 早期，这些状况需要在 应用层 去解决

  • 后来，这部分工作下沉到了 网络层

    • 由 TCP/IP 等标准网络协议 来保证 数据传输的可靠性

• 微服务的可靠性

  • 网络协议提供的保障，对于小型的多机互联够用了，但大规模的分布式场景，还需要引入更多机制，保障整体的可靠性

  • 例如

    • 服务发现机制: 通过多个服务的注册，实现故障转移
    • 熔断机制: 防止某个服务产生级联故障

  • 早期，这些状况也是由 微服务 去解决

  • 后来，出现了一些开源类库，可以集成到微服务中

    • 由专门的类库来完成，而不必在每个服务中重写相同的控制逻辑
    • 比如: Finagle、Proxygen等
    • 但缺点也很明显
      • 胶水部分的资源投入：需要将第三方库与系统其余部分连接起
      • 类库限制了微服务的技术选型：这些类库通常是特定于平台的，仅支持特定运行时或编程语言
      • 类库的维护成本：类库本身也需要持续维护升级

  • 再后来，出现了sidecar，作为辅助进程，随应用程序运行

    • 通过搭建代理来实现这些保障
    • 比如Synapse + Nerve、Prana等
    • 但缺点也有
      • 方案都建立在特定的基础组件上，不够灵活
        • 比如 Synapse + Nerve 基于zookeeper
        • Prana 基于 Eureka

  • 再后来，出现了Service Mesh

    • 给每个服务配套一个代理sidecar作为基础设施层，服务间仅通过代理通信，最终得到一个代理之间的网状网格，称之为Service Mesh
    • 紧接着，它与掌握Service的部署平台擦出火花，进而衍生出 控制层+数据层 的上下结构
      • 管理实例间网络流量的部分，称为 数据层(Data Plane)
      • 数据层的行为由 控制层(Control Plane) 生成的配置项来控制