DreamMesh抛砖引玉(10)-多集群

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

这个问题和前面列出的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. 服务治理的信息不统一：有各自的配置方式，或者设置方法

讨论和反馈

TBD：等收集后整理更新

后记

Dream Mesh抛砖引玉系列的文章到此完结，后续将展开Dream Mesh的概要设计，和针对各个功能子模块的详细设计。

鸣谢在此期间参与讨论，给出意见和反馈的朋友们，感谢你们的支持和帮忙。