文|肖健(花名:昱恒)
蚂蚁集团技术专家、SOFARegistry Maintainer
专注于服务发现领域,目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。
本文 8339 字 阅读 15 分钟
PART. 1
前言
什么是服务发现?
我们今天主要聊的话题是“应用级服务发现”的实践,聊这个话题之前,我们先简单介绍一下什么是“服务发现”,然后再聊聊,为什么需要“应用级服务发现”。
在微服务的体系中,多个应用程序之间将以 RPC 方式进行相互通信,而这些应用程序的服务实例是动态变化的,我们需要知道这些实例的准确列表,才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。
图 1(点击图片查看大图)
SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心,经历了多年大促的考验,支撑了蚂蚁庞大的服务集群,具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。
PART. 2
应用级服务发现的设想
介绍完什么是服务发现之后,我们来看看什么是“接口级服务发现”,以及与之相对应的“应用级服务发现”。
从 RPC 框架说起
根据上述描述,我们先看看业界常用的 RPC 框架,是如何进行服务的发布和订阅的。以 SOFARPC 编程界面为例:
|服务发布
package com.alipay.rpc.sample;
@SofaService(interfaceType = FooService.class, bindings = { @SofaServiceBinding(bindingType = "bolt") })
@Service
public class FooServiceImpl implements FooService {
@Override
public String foo(String string) {
return string;
}
}
@SofaService(interfaceType = BarService.class, bindings = { @SofaServiceBinding(bindingType = "bolt") })
@Service
public class BarServiceImpl implements BarService {
@Override
public String bar(String string) {
return string;
}
}
|服务使用
@Service
public class SampleClientImpl {
@SofaReference(interfaceType = FooService.class, jvmFirst = false,
binding = @SofaReferenceBinding(bindingType = "bolt"))
private FooService fooService;
@SofaReference(interfaceType = BarService.class, jvmFirst = false,
binding = @SofaReferenceBinding(bindingType = "bolt"))
private BarService barService;
public String foo(String str) {
return fooService.foo(str);
}
public String bar(String str) {
return barService.bar(str);
}
}
上述两个编程界面,完成了两个服务 FooService 和 BarService 的发布、订阅、调用。
微服务面临的挑战
上述的服务发布、订阅、调用功能,离不开注册中心的服务发现提供准确的服务地址。将图 1 的服务发现场景进一步展开,此时的工作原理如下图:
图 2(点击图片查看大图)
服务发布者
- 集群内部署了 100 个 pod,IP 分别为:1.1.1.1 ~ 1.1.1.100;
- 服务发布者的 URL:1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0,12200 端口为 sofarpc-bolt 协议默认的端口。
服务订阅者:集群内部署了 100 个 pod,IP 分别为:2.1.1.1 ~ 2.1.1.100。
基于上述的集群部署情况,我们来看看微服务的场景面临的挑战。
|挑战 1:注册中心 publisher 存储的挑战
在上面的集群部署中,可以看到注册中心的数据存储模型,集群内部署了 100 个 provider pod,每个 provider 发布了 2 个服务,即每个 pod 有 2 个 publisher,以 provider1 为例:
如果在每个 provider 提供更多服务的情况下呢?比如每个 provider 提供了 50 个服务,这样的量级在微服务场景中并不少见,那么此时注册中心对于 provider1,就需要存储 50 个 publisher,分别是:
可以看到,随着 provider 的扩容,注册中心存储的 publisher 数据量是以 50 倍于 provider 的速度在增长。
如果您对 SOFARegistry 有过了解,就会知道 SOFARegistry 是支持数据存储分片,可以存储海量数据的。
但是数据量上涨带来的是 SOFARegistry 本身的服务器数量增涨,如果我们有办法可以降低 SOFARegistry 的数据存储量,那么就能节约 SOFARegistry 本身的服务器成本,同时 SOFARegistry 整个集群的稳定性也会得到提升。
|挑战 2:注册中心 subscriber 存储的挑战
在上述的集群部署中,集群内部署了 100 个 consumer pod,每个 consumer 订阅了 2 个服务,即每个 pod 有 2 个 subscriber,同理于 publisher 的存储挑战,随着 consumer 订阅的接口持续增加,例如 consumer 订阅了 provider 的 10 个 service,此时注册中心存储 consumer1 的 10 个 subscriber 如下:
随着 consumer 的扩容,注册中心内的 subscriber 存储同样面临着挑战。
|挑战 3:服务变更通知的挑战
随着 publisher 和 subscriber 数量增长,除了对存储的挑战以外,对于数据变更通知同样面临着极大的挑战,让我们来看看如下的场景:provider 下线了 1 台,从 100 台减少到了 99 台,次数集群内发生了哪些变化呢?
1、首先是在注册中心存储方面,需要将 provide 50 个 service 中的 publishers 列表都减少 1 个,每个 service 剩余 99 个 publisher;
2、然后注册中心需要将这 50 个 service 的变更,都通知给相应的 subscriber;我们上述假设是 consumer 订阅了 10 个 service,分别是:[“com.alipay.sample.FooService”, “com.alipay.sample.BarService”, “com.alipay.sample.Service00”, …, “com.alipay.sample.Service07”];
3、那么对于 consumer1,我们需要将如下的数据推送给 consumer1:
com.alipay.sample.FooService:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.99:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
com.alipay.sample.BarService:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.99:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
//...中间省略
com.alipay.sample.Service07:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.99:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
可以看到一台 provider 的扩缩容,就需要对 consumer1 进行如此大量的数据推送,如果 com.alipay.sample.FooService 的 publisher 的数量更大,达到 1 千个、1 万个呢?此时注册中心的服务变更通知,也面临着网络通信数据量大的挑战。
是否有方式在 provider 的变更时,降低需要通知的数据量呢?
|挑战 4:consumer 的内存挑战
介绍完注册中心面临的挑战后,我们再从图 1 来看看 consumer 存储服务列表时,内存面临的挑战,对于注册中心推送下来的数据,consumer 也需要进行存储,然后再发起 RPC 服务调用的时候,就可以直接从 consumer 内存中获取到服务地址进行调用,consumer 中存储的数据,简化来看是如下的数据:
com.alipay.sample.FooService:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.99:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
com.alipay.sample.BarService:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.99:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
//...中间省略
com.alipay.sample.Service07:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.99:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
此时 privoder 只有 99 个 IP,但是因为订阅了 10 个 service,所以在 consumer 中存储了 99 * 10 = 990 个 publisher 列表;如果订阅的 service 更多,provider 的数量更大呢*(比如达到 10 万)*?此时 consumer 内存中存储了近 100 万个 publisher,内存将面临着极大的挑战。
微光:应用级服务发现的提出
|应用级服务发布
经过上一个章节的描述,对于一次简单的 RPC 调用背后,服务发现面临的挑战相信各位读者已经有所感受,那么可能得突破方向到底在哪里呢?
初步看,我们不难发现的是,对于一个 provider1,在注册中心存储的 publisher 数据如下:
com.alipay.sample.FooService:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
com.alipay.sample.BarService:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
//...中间省略
com.alipay.sample.Service100:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
每个 publisher 中,除了 serviceName 不相同,url 存储了相同的 100 份,这里是否可以简化为存储 1 份?这是应用级服务发布最初的想法。
按照这个模型我们继续推演,可以得到如下演进模型:
图 3(点击图片查看大图)
对比图 2 和图 3,我们设想:
1、prodiver 不再以 service=com.alipay.sample.FooService 向注册中心发布服务,而是以 service=applicationB 进行服务发布,那么注册中心对于 provide1,此时 publisher 存储的数据量从 50 个下降到 1 个,注册中心的整个集群的 publisher 存数量,也将下降 50 倍,这将使得注册中心 SOFARegistry 的服务器成本极大降低,同时注册中心的稳定性也将得到大幅度提升。
2、对于 prodiver 发布了哪些服务,这个关系维护在 metadataMap 中,供后续的应用级服务订阅使用。
|应用级服务订阅
在上一节中我们将服务发现,演进到了应用级服务发布,那么此时的服务订阅与服务调用,应该怎样进行呢?我们继续从图 3 中展开:
1、对于 comsumer1,启动时先根据接口进行一次 metadata fetch 的元数据获取,根据 metadataMap 中的数据,可以知道此时 service=com.alipay.sample.FooService 映射的 app=applicationB;同理其他 9 个 service 映射的 app 也是 applicationB;
2、然后以 applicationB 为 dataid,向注册中心发起订阅,注册中心此时不再是存储 consumer1 的 10 个 subscriber,而是存储一个 dataid=applicationB 的 subscriber;注册中心的 subscriber 数量也降低了 10 倍;
3、consumer1 发起服务订阅后,注册中心进行数据推送,此时注册中心推送的数据为:
applicationB:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.100:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
4、可以看到,此时注册中心给 consumer1 的数据推送量,相比于【Part.2 挑战 3】中推送的数据,网络的数据量交互也下降了 10 倍。
|应用级路由
经过上述的“应用级服务发布”和“应用级服务订阅”,我们解决了注册中心的数据量存储瓶颈,注册中心的变更通知网络瓶颈,最后我们来看看 consumer1 中的内存瓶颈如何解决。
通过上面的步骤,consumer1 中拿到了一些数据,分别是:metadataMap 和 publishMap:
applicationB:
- com.alipay.sample.FooService
- com.alipay.sample.BarService
- ...
- com.alipay.sample.Service50
applicationB:
- 1.1.1.1:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
- ...
- 1.1.1.100:12200?app=applicationB&_SERIALIZETYPE=hessian2&_TIMEOUT=3000&zone=zone1&version=1&_WARMUPTIME=0
此时我们可以在 consumer1 进行“应用级路由”的信息封装,如下图:
图 4(点击图片查看大图)
如图 4 所示,此时 consumer 中只需要保存 applicationB 的 100 个 publisher,而不再是保存 10(假设订阅了 10 个 service)* 100 = 1000 个 publisher,consumer1 中的服务路由表的内存使用,也降低了 10 倍。
PART. 3
长路漫漫
在上述的微服务模型中,经过上面的应用级服务发现方案推演,我们做到了:
- 注册中心存储的 publisher 数据量下降了 50 倍;
- 注册中心存储的 subscriber 数据量下降了 10 倍;
- 注册中心服务变更通知,网络通信数据量下降了 10 倍;
- 服务订阅端 consumer 中,服务路由表的内存 insue 使用降低了 10 倍;
这个推演结果是令人激动的,然而实际的场景要比上述这个数据更复杂。这个推演模型,要进行真正线上实施,并且进行大规模落地,仍然是长路漫漫。这里先抛出几个问题:
1、如果不同的接口之间,参数并不是完全相同的,我们要如何处理?例如 FooService 的 _TIMEOUT=3000,BarService的_TIMEOUT=1000,Service100的_TIMEOUT=5000;
2、provider 的不同 pod 之间,发布的服务列表有差异,要如何处理?例如 provider1 发布的服务列表是 [“com.alipay.sample.FooService”,“com.alipay.sample.BarService”, …, “com.alipay.sample.Service50”];provider2 发布的服务列表是 [“com.alipay.sample.FooService”,“com.alipay.sample.BarService”, …, “com.alipay.sample.Service51”];
3、无论是上述的 provider 还是 consumer,都需要进行 SDK 的代码改造,如何保证线上从“接口级服务发现”,平滑过渡到“应用级服务发现”;
4、如果部分应用无法升级 SDK,方案如何继续演进,拿到期望的效果收益;
5、两个方案过度期间,如何确保注册中心服务的一致性。
这些问题,我们将在下一篇文章《技术内幕|蚂蚁的应用级服务发现实践之路》中详细解答,敬请期待。
|参考链接|
Dubbo 迈向云原生的里程碑 | 应用级服务发现:https://lexburner.github.io/dubbo-app-pubsub/
了解更多…
SOFARegistry Star 一下✨: https://github.com/sofastack/sofa-registry/