Create index.md (#1166)

bianbian-yf · zhenjunMa · web-flow · commit edac70293a96 · 2023-05-22T11:38:53.000+08:00
Co-authored-by: Marco &lt;lingfenglangshao@gmail.com&gt;
diff --git a/content/zh/blog/origins｜ant's-practical-path-to-application-level-service-discovery/index.md b/content/zh/blog/origins｜ant's-practical-path-to-application-level-service-discovery/index.md
@@ -0,0 +1,316 @@
+---
+title: "缘起｜蚂蚁应用级服务发现的实践之路"
+authorlink: "https://github.com/sofastack"
+description: "缘起｜蚂蚁应用级服务发现的实践之路"
+categories: "SOFAStack"
+tags: ["SOFAStack"]
+date: 2023-04-11T15:00:00+08:00
+cover:"https://mdn.alipayobjects.com/huamei_soxoym/afts/img/A*MqBZTo4wB7IAAAAAAAAAAAAADrGAAQ/original"
+
+---
+![图片](https://mmbiz.qpic.cn/mmbiz_gif/nibOZpaQKw09ARcsGuzib3ttcN4LZpdAC0n9KTQp7uibF8ia0ibk3Olf3sib50ExibicicOrzCOVrOyUD2dFib84f0fTx5uA/640?wx_fmt=gif&wxfrom=5&wx_lazy=1)
+
+文｜肖健（花名：昱恒）
+
+蚂蚁集团技术专家、SOFARegistry Maintainer
+
+*专注于服务发现领域，目前主要从事蚂蚁注册中心 SOFARegistry 的设计和研发工作。*
+
+**本文 8339 字  阅读 15 分钟**
+
+**PART. 1**
+
+**前言**
+
+**什么是服务发现？**
+
+我们今天主要聊的话题是“应用级服务发现”的实践，聊这个话题之前，我们先简单介绍一下什么是“服务发现”，然后再聊聊，为什么需要“应用级服务发现”。
+
+在微服务的体系中，多个应用程序之间将以 RPC 方式进行相互通信，而这些应用程序的服务实例是动态变化的，我们需要知道这些实例的准确列表，才能让应用程序之间按预期进行 RPC 通信。这就是服务发现在微服务体系中的核心作用。
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOhEqTIaQqyMfZdoOBMCZwGtnsic2cvouRrVNDUrDW89LFS5KCe9dcUAw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
+
+图 1（点击图片查看大图）
+
+SOFARegistry 是蚂蚁集团在生产大规模使用的服务注册中心，经历了多年大促的考验，支撑了蚂蚁庞大的服务集群，具有分布式可支撑海量数据、可云原生部署、推送延迟低、高可用等特点。
+
+**PART. 2**
+
+**应用级服务发现的设想**
+
+介绍完什么是服务发现之后，我们来看看什么是“**接口级服务发现**”，以及与之相对应的“**应用级服务发现**”。
+
+**从 RPC 框架说起**
+
+根据上述描述，我们先看看业界常用的 RPC 框架，是如何进行服务的发布和订阅的。以 [SOFARPC 编程界面](*https://www.sofastack.tech/projects/sofa-rpc/programing-sofa-boot-xml/*)为例：
+
+**｜服务发布**
+
+```bash
+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;
+    }
+}
+```
+
+**｜服务使用**
+
+```bash
+@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 的服务发现场景进一步展开，此时的工作原理如下图：
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOD5TPYoCibtFBxDibVQ0Iicr9yiaUmzSD8YOqxDSffbXGaQxFfG1kyA04ew/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=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 协议默认的端口。
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOT8bCv3ia3r5zMibEPcTfezl1SdA8HD9ULiatGRcNQEsSvFs3NHIjzX2Rg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
+
+服务订阅者：集群内部署了 100 个 pod，IP 分别为：2.1.1.1 ~ 2.1.1.100。
+
+基于上述的集群部署情况，我们来看看微服务的场景面临的挑战。
+
+**｜挑战 1：注册中心 publisher 存储的挑战**
+
+在上面的集群部署中，可以看到注册中心的数据存储模型，集群内部署了 100 个 provider pod，每个 provider 发布了 2 个服务，即每个 pod 有 2 个 publisher，以 provider1 为例：
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOghqyu8GiaFibXkz7quAFZI1jnSHNR4eNsEa5EGb8j5HR7DrG2wLIblMg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
+
+如果在每个 provider 提供更多服务的情况下呢？比如每个 provider 提供了 50 个服务，这样的量级在微服务场景中并不少见，那么此时注册中心对于 provider1，就需要存储 50 个 publisher，分别是：
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOGMDwSiboq8x6T4vwxl5rUYsEW0Er7vJc2Z7myI7YFgQ46vr8D7IicRbw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
+
+可以看到，随着 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 如下：
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOV2GLtEWyh423Mgd5oE7Y5vgpZKND0o5tPdsRnmibuJR7Qf4gaxfnBNg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
+
+随着 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：
+
+```bash
+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 中存储的数据，简化来看是如下的数据：
+
+```bash
+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 数据如下：
+
+```bash
+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 份？这是应用级服务发布最初的想法。
+
+按照这个模型我们继续推演，可以得到如下演进模型：
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOAknnQ0sVUaztbGcZGIpxNY38icoVpabKD4w2nFU0rh2BOefFGuStribQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=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 发起服务订阅后，注册中心进行数据推送，此时注册中心推送的数据为：
+
+```bash
+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：
+
+```bash
+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 进行“应用级路由”的信息封装，如下图：
+
+![图片](https://mmbiz.qpic.cn/mmbiz_png/nibOZpaQKw09p07piaRGTPsret1D2jf9kOeibyHayyIJZZLUZ6H7jY3mhMPr54tMYxDLAHRyS41eP5pSCOq14ctWQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)
+
+图 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/*](https://lexburner.github.io/dubbo-app-pubsub/)
+
+ **了解更多...**
+
+**SOFARegistry Star 一下✨：**
+[*https://github.com/sofastack/sofa-registry/*](https://github.com/sofastack/sofa-registry/)
