DreamMesh服务注册(2)-多集群的难点

如果有多集群/多机房的支持需求,该如何解决?

这个问题和前面列出的service mesh体系和非service mesh的并存问题,可能叠加:如何在多集群/多机房要求下实现service mesh体系和非service mesh的并存。

需求

首先看看需求来自哪里:

  1. Service Mesh体系和非Service Mesh体系并存/过渡的需要

    见前文 DreamMesh抛砖引玉(3)-艰难的过渡

  2. 多机房部署

    • 有些是考虑容灾,异地双活以备不时之需
    • 大多数没有这么高要求,只是地域差异,应用部署在不同地域
    • 有些是部门/组织/系统不同,各自部署独立系统
  3. 技术栈差异

    不同时期使用的技术栈不同,可能造成有多套集群,比如原有dubbo,现在要转向spring cloud,这样在过渡期间会有两套系统。前面列的第一条可以视为是本条的特例。

    如果公司较大,也会出现不同组织采用不同的技术栈导致出现多个集群。

  4. 测试运维需要

    可能希望在生产环境之外搭建stagging,test等集群,通常是独立运作,但是偶尔会有想法,希望开个口子以便打通若干个服务或者某个实例,来做测试和验证。

场景

我们要打通的多个微服务集群,情况很复杂,可能是以下多种场景混杂:

  1. 集群可能是Service Mesh体系和非Service Mesh体系

    • 如果是Service Mesh,可能是Istio/Conduit
    • 如果是非Service Mesh体系,可能是SpringCloud/Dubbo/Motan等
  2. 集群可能有不同的部署方式

    • 不同地域
    • 不同机房
    • 网络不同,可能在虚拟网络中如k8s
  3. 集群可能使用不同的技术栈,包括:

    • 服务注册机制
    • 远程通讯机制
  4. 集群可能用于不同的产品部署阶段

    • prod
    • stagging
    • test

难点

需求告诉我们:这个事情有做的价值;而场景则提醒我们:这个事情不简单。

我们来罗列一下实现中的难点所在:

服务注册与服务发现

备注1:由于篇幅所限,下面列出的只是提纲,详细内容会在后续文章中阐述 备注2:实际上是内容展开之后发现篇幅收不住,内容太长不适合阅读,决定拆开

要调用服务,自然需要知道服务在哪里,这涉及到服务注册与服务发现。本集群内只需要知道目标服务实例的IP地址和端口即可,而要跨集群调用服务,事情要变的复杂的多:

  • 目标服务在哪个集群?
  • 单服务多集群的部署的动机
  • 服务集群切换的判断机制
  • 是否需要维持目标服务实例的详细列表
    • 要不要支持跨集群的负载均衡?

最后,最关键的一点:各个集群的服务注册模型必须一致或者可以转换为一致,这样才能在一个集群中"理解"另一个集群的服务注册信息。

SDK必须有能力转发跨集群的请求

在获取目标服务的地址之后,如果发现是远程集群,那就需要解决如何将请求转发到另一个集群的问题。

  • 如果网络互通,直接连接就好了
  • 如果网络不通,那么需要引入特殊机制,来跨集群转发请求,类似反向代理/API Gateway
  • SDK要能识别服务实例所在的zone,以及获取配置,看是否需要执行"就近访问"
  • 如果服务跨多个集群部署+需要跨集群负载均衡,SDK的实现要复杂的多
  • 如果一个服务在两个集群中采用不同的通讯协议,则还有一个协议转换的过程

服务治理必须跨集群通用

在服务注册机制+SDK的配合之下,现在我们可以做到:

  • 跨集群的获取目标服务的地址信息
  • 能够跨集群的转发请求到目标服务

也就是端到端的路通了,然后就要继续考虑:如何进行更精细的控制,即各种服务治理。

要在各个集群中贯彻一致的服务治理意图,需要解决两个难题:

  1. 服务治理的实现不同:有各自的SDK实现
  2. 服务治理的信息不统一:有各自的配置方式,或者设置方法
敖小剑
敖小剑
新时代农民工 * 中年码农

我目前研究的方向主要在Microservice、Servicemesh、Serverless等Cloud Native相关的领域,全职从事Dapr开发,欢迎交流和指导。