Ask Questions

[dajitui]

Your question

1. 我在看服务发布源码的时候，发现是刷新到data-server内存中，并没有进行落库，但是数据表里面又有app_revision表，以及监听最大id进行兜底更新

我的问题：是不是在哪个方法会将内存数据刷到数据库？目前我是没有找到

2. 框架里面大量taskmap进行解耦，存在节点宕机之后任务丢失的问题，有没有对应的处理方案

[nocvalight]

1.app_revision表主要存储的是应用级服务发现的元数据信息，这个应用级服务发现的client目前还没来得及开源，所以你目前看不到client进行应用级元数据注册的client代码，这部分相关原理详见：https://mp.weixin.qq.com/s/-oVOeakwefgvlFyi6yYgKA
2.sofa registry的数据一致性，是靠session和data之间相互的watch ant list实现数据一致性的，详见：https://www.sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/

[dajitui]

1.app_revision表主要存储的是应用级服务发现的元数据信息，这个应用级服务发现的client目前还没来得及开源，所以你目前看不到client进行应用级元数据注册的client代码，这部分相关原理详见：https://mp.weixin.qq.com/s/-oVOeakwefgvlFyi6yYgKA 2.sofa registry的数据一致性，是靠session和data之间相互的watch ant list实现数据一致性的，详见：https://www.sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/

1. 能否这么理解，server的元数据信息是保存在data-server的内存中，client会保存在app_revision表中的。因为我从源码里面没有找到对应的服务端元数据储存数据库的步骤，只看到slot map里面

还有一个问题就是没有明白为啥保存客户端的元数据，即使nacos的话也是服务端的元数据比较重要的，client拉取serverList，然后根据服务端元数据去处理，比如灰度、版本 等等，这个客户端的元数据主要是做什么功能？

[NickNYU]

1.app_revision表主要存储的是应用级服务发现的元数据信息，这个应用级服务发现的client目前还没来得及开源，所以你目前看不到client进行应用级元数据注册的client代码，这部分相关原理详见：https://mp.weixin.qq.com/s/-oVOeakwefgvlFyi6yYgKA 2.sofa registry的数据一致性，是靠session和data之间相互的watch ant list实现数据一致性的，详见：https://www.sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/

1. 能否这么理解，server的元数据信息是保存在data-server的内存中，client会保存在app_revision表中的。因为我从源码里面没有找到对应的服务端元数据储存数据库的步骤，只看到slot map里面

还有一个问题就是没有明白为啥保存客户端的元数据，即使nacos的话也是服务端的元数据比较重要的，client拉取serverList，然后根据服务端元数据去处理，比如灰度、版本 等等，这个客户端的元数据主要是做什么功能？

首先，还是一个应用级服务发现的问题，详细可以参考上文中给出的微信文档。这里简述一下：应用级服务发现是把应用和service接口的关系，存储在DB中，这样，data中存储的信息可以简化为应用和IP的关系。

然后，这里回答你的两个问题：

1. 能否这么理解，server的元数据信息是保存在data-server的内存中，client会保存在app_revision表中的。因为我从源码里面没有找到对应的服务端元数据储存数据库的步骤，只看到slot map里面

[回答] 这里的client其实是SOFARegistry的client，也就是服务提供方的client，它会携带服务的应用名等元信息，这样就可以籍由session节点将信息同步给DB（蚂蚁内部使用的是OceanBase，OB目前也是开源的，欢迎使用）
然后，这块儿逻辑你可以搜一下app revision，也可以从storage的模块中，找到相关抽象，逆向去看代码。

第二个问题，

还有一个问题就是没有明白为啥保存客户端的元数据，即使nacos的话也是服务端的元数据比较重要的，client拉取serverList，然后根据服务端元数据去处理，比如灰度、版本 等等，这个客户端的元数据主要是做什么功能？

首先，灰度、版本这些属于service自己携带的信息，是不会存储在服务和应用的meta中，而是通过registry client上报时候，携带的类似于tag的东西，存储在IP连接串中（data去存这部分数据）
保留的也是registry client的元信息，如上文所说，并不是广义上理解客户端和服务端的概念。

Nacos的应用级服务发现有一个好处是没有历史负担，所以，可以制定相对简洁明了的应用、服务模型，但是SOFARegistry是蚂蚁线上在用的产品，在应用级服务发现最难的地方在于兼容之前基于接口级服务发现的各种用法，比如，你所说的灰度等（当前业界的best practice，例如istio，是把服务发现和服务治理拆开来的，对应CDS/EDS，以及RDS），因为存量应用会把路由标签也携带在服务发现的上报连接中，所以，这一块儿是SOFARegistry的应用级服务发现处理的重点。

普通用户可以忽略，SOFARegistry在蚂蚁内部是超过了40W的注册量，需要应用级服务发现来“减负”，一般用户没有这么大量，不需要应用级服务发现。

[dajitui]

ok，第二个问题是概念上的问题，确实不是广义上服务端、客户端，相当于server是服务发现，其他应用都作为服务发现client

Nacos的应用级服务发现有一个好处是没有历史负担，所以，可以制定相对简洁明了的应用、服务模型，但是SOFARegistry是蚂蚁线上在用的产品，在应用级服务发现最难的地方在于兼容之前基于接口级服务发现的各种用法

这个我不太懂，因为nacos也是支持像dubbo接口级别的服务发现，所以本质上应该没有区别的