@bthulu 生产环境客户不会让这么搞的，只能压测了~

@Dganzh 官方启动脚本内存默认单机模式给了 512 M ，集群模式默认设置了 2G

@leeqingshui 看错了，上面那个是 dubbo 2.7.8 集成 Nacos 的 bug
nacos 配置列表中出现很多以接口名为 dataid 的 dubbo 的配置文件，这个可以关闭，但不知影响如何
https://github.com/apache/dubbo/issues/7598
dubbo:
registry:
address: nacos://127.0.0.1:8848?username=nacos&password=nacos
# 增加以下配置
use-as-metadata-center: false
use-as-config-center: false

@damai0419
@Rumble66 https://github.com/apache/dubbo/issues/6988
Nacos 集成 Dubbo 多了巨多 dubbo 的配置文件，我查了下，这个应该是 dubbo 的 bug
https://github.com/alibaba/nacos/issues/4491
https://github.com/apache/dubbo/issues/6988

dubbo 社区已经有人发现了这个 bug （ https://github.com/apache/dubbo/issues/6988 ）并且提交了 pr 。目前已经被合并到了 master 分支（ dubbo 2.7.9 ）。

@damai0419
将 Nacos 作为注册中心遇到过其他问题嘛？
后面你们是不是又换回了 zk😂
zk 存储是树形结构，看着是会舒服点
nacos 一启动，日志文件也多一堆😂

@Kaiv2 好的，我会试下~

@bthulu 用 Nacos 主要是它的某些功能特性刚好符合实际业务场景需要，能解决一些问题，和应用规模没关系吧。。。

数据字典这个功能应该放到一个基础模块当中，其他组件引用就好。
多产品的不同参数含义一样，名称不同，那么应该抽离一个专门的模块做字段映射，比如说公司内部的产品三方调用各种外部接口，最终接口的参数经映射统一后落到公司内的数据库，后续看日志想知道外部传递了哪些参数过来，以你映射后的参数为基准即可。
对于你司内部产品应该也是互相调用吧？那经过这个中转映射模块就好。

@wolfie 这块国庆抽时间弄了下~
视频地址：aHR0cHM6Ly9zcGFjZS5iaWxpYmlsaS5jb20vMjAzNTE2NzkzL3ZpZGVv
代码地址：aHR0cHM6Ly9naXRodWIuY29tL0Nocmlzc3NXb25nL2ludm9rZS1jb21wZW5zYXRpb24=

后面的优化下周会弄下~

@wolfie 嗯呢，我看到了，我这边也写了 80%，这周有空完善下，国庆我会把代码放出来，B 站再录个视频说明下~

@lmshl 嗷，会考虑一部分逻辑使用这种实现~

@msg7086 😂

@zmal 嗯嗯，好哒~

@xiang0818 是的，这种对接方我遇到过，对接方只提供一个 url ，内部通过请求体的某个字段去调自己内部的方法
比如说，客户只对外提供一个 url： http://v2ex.com/testService
申请接口的请求报文用：
```json
{
"request": {
"head": {
"funcode": "apply"
},
"body": {
}
}
}
```
上传文件接口的请求报文则用：
```json
{
"request": {
"head": {
"funcode": "upload"
},
"body": {
}
}
}
```
即用 funcode 进行判断自己内部调用哪个方法 doge ~

@matzoh 是的，双方做好幂等处理，重复补偿其实无所谓，只是数据库会存多条数据而已，问题也不大~
@xuanbg
这边应当不会使用队列，因为补偿数据部分情况会涉及到需要修改值的情况，也就是需要人工介入，所以这边补偿方案会设计考虑兼容自动处理和人工处理两种类型，其实也好处理~

@dzdh 没有，有的话就好搞了 doge~

@wolfie 会有异步三方文件调用的接口（这边业务代码设计的不合理 doge~），文件的 Base 64 串会很长哒

@Jooooooooo 嗯嗯，好的好的，有时候想思考的全面一点，有点完美主义了......

@Gmzx emmm ，但碰撞可能性还是存在的，看网上很多方案都是准备用这些参数生成一个摘要值，认为这个摘要值是唯一的，B 站上有视频也是按照这种方案处理的，这严格意义上来讲是错的，所以对此抱有怀疑态度(dog)