DreamMesh服务注册(2)-多集群的难点
如果有多集群/多机房的支持需求,该如何解决?
这个问题和前面列出的service mesh体系和非service mesh的并存问题,可能叠加:如何在多集群/多机房要求下实现service mesh体系和非service mesh的并存。
需求
首先看看需求来自哪里:
-
Service Mesh体系和非Service Mesh体系并存/过渡的需要
-
多机房部署
- 有些是考虑容灾,异地双活以备不时之需
- 大多数没有这么高要求,只是地域差异,应用部署在不同地域
- 有些是部门/组织/系统不同,各自部署独立系统
-
技术栈差异
不同时期使用的技术栈不同,可能造成有多套集群,比如原有dubbo,现在要转向spring cloud,这样在过渡期间会有两套系统。前面列的第一条可以视为是本条的特例。
如果公司较大,也会出现不同组织采用不同的技术栈导致出现多个集群。
-
测试运维需要
可能希望在生产环境之外搭建stagging,test等集群,通常是独立运作,但是偶尔会有想法,希望开个口子以便打通若干个服务或者某个实例,来做测试和验证。
场景
我们要打通的多个微服务集群,情况很复杂,可能是以下多种场景混杂:
-
集群可能是Service Mesh体系和非Service Mesh体系
- 如果是Service Mesh,可能是Istio/Conduit
- 如果是非Service Mesh体系,可能是SpringCloud/Dubbo/Motan等
-
集群可能有不同的部署方式
- 不同地域
- 不同机房
- 网络不同,可能在虚拟网络中如k8s
-
集群可能使用不同的技术栈,包括:
- 服务注册机制
- 远程通讯机制
-
集群可能用于不同的产品部署阶段
- prod
- stagging
- test
难点
需求告诉我们:这个事情有做的价值;而场景则提醒我们:这个事情不简单。
我们来罗列一下实现中的难点所在:
服务注册与服务发现
备注1:由于篇幅所限,下面列出的只是提纲,详细内容会在后续文章中阐述 备注2:实际上是内容展开之后发现篇幅收不住,内容太长不适合阅读,决定拆开
要调用服务,自然需要知道服务在哪里,这涉及到服务注册与服务发现。本集群内只需要知道目标服务实例的IP地址和端口即可,而要跨集群调用服务,事情要变的复杂的多:
- 目标服务在哪个集群?
- 单服务多集群的部署的动机
- 服务集群切换的判断机制
- 是否需要维持目标服务实例的详细列表
- 要不要支持跨集群的负载均衡?
最后,最关键的一点:各个集群的服务注册模型必须一致或者可以转换为一致,这样才能在一个集群中"理解"另一个集群的服务注册信息。
SDK必须有能力转发跨集群的请求
在获取目标服务的地址之后,如果发现是远程集群,那就需要解决如何将请求转发到另一个集群的问题。
- 如果网络互通,直接连接就好了
- 如果网络不通,那么需要引入特殊机制,来跨集群转发请求,类似反向代理/API Gateway
- SDK要能识别服务实例所在的zone,以及获取配置,看是否需要执行"就近访问"
- 如果服务跨多个集群部署+需要跨集群负载均衡,SDK的实现要复杂的多
- 如果一个服务在两个集群中采用不同的通讯协议,则还有一个协议转换的过程
服务治理必须跨集群通用
在服务注册机制+SDK的配合之下,现在我们可以做到:
- 跨集群的获取目标服务的地址信息
- 能够跨集群的转发请求到目标服务
也就是端到端的路通了,然后就要继续考虑:如何进行更精细的控制,即各种服务治理。
要在各个集群中贯彻一致的服务治理意图,需要解决两个难题:
- 服务治理的实现不同:有各自的SDK实现
- 服务治理的信息不统一:有各自的配置方式,或者设置方法