@teawithlife 你看完我的 原理应该就会明白了。

我这套设计是 没有注册中心的，在整个微服务中，每个服务都需要向其余的所有服务发送心跳包，所以，在某个时间段，心跳包的消息数量会达到 n*n 条。 一旦微服务的机器扩大变多，这个压力还是需要重视的。

注：网络压力指的是内网压力

首先，你如果问的是把 sql 写在类里面 这种方式可不可取，那我个人认为把 sql 写类里面，和写 xml 里没啥区别， 现在都是 boot 打 jar 包，即使写在 xml 里 也是无法在线上更改的。

无论写哪，只要牵扯到改，都要程序员改完提测 然后重新打包发布，所以写类和写 xml 已经没有本质区别了。

所以，这种写法我个人认为完全没问题，不过肯定会有一些 盲目遵守规范的人 会说不行， 这个就不做争论了。。

其次，如果你问的这你贴出来的这段代码有没有问题，那么其他人已经都告诉你了，你需要让代码分布的更合理一点，然后参数不要拼接，要用占位符。

把 userForm 转成 json 字符串，String userFormStr = JSON.toJSONString(userForm);

然后判断 userFormStr 是否等于{}

@liuhan907 首先呢，我也是发布了这篇文章后才知道 gossip 这个名词的， 后来我专门去大致了解了一下。

发现 gossip 只是将数据传染出去，并没有心跳机制，他比较适合做 [分布式数据存储] 或者 [主从数据存储] 方案，在 redis cluster 里就借鉴了 gossip 的思想。

不过我这个方案 也可以说是借鉴了 gossip 的思想，谁让他比我早呢， 不过你说的不带优化，我是不承认的，我只承认目前这个方案确实不适合大规模的微服务，因为正如 [Sunmxt ] 大神所说， 在某个时间内，整个服务需要发送的消息数量能达到 n*n 。

不过这个并不是没有优化的结果，而是为了心跳机制，我目前能想到方案里，只有这个最稳定，只是有点耗带宽。

我后面的重点，也是想办法解决这个问题，东西嘛，都是慢慢试错试出来的。

@PiersSoCool 获取接口和发送广播的动作是 轮询的，不是一次性的。 数据会被慢慢纠正。

为什么要用轮询，主要是为了 心跳机制， 不然服务下线了 其他节点是不知道的。

不过这个心跳机制，造成了 在某个时间内，集群里要发送的 消息次数能达到 n*n，对网络会造成一定的压力，所以目前不太适合大规模的微服务。

这也是我下一步要 解决的问题。

你说的第 2 个点 我在给你耐心说一次：

你见过 mysql 主从吗？？ 主从连接是不是显式的配置了 ip ？？

你见过 zk 集群吗？ 是不是在配置文件里都配置了 其他节点的 ip ？

还有一点!!!!

这个配置的 ip 和 具体要调用的接口是两码事，两码事，你好好理解一下吧，什么都不懂，就大放厥词。

至于你说的安全性，我就更是哈哈哈哈了，如果黑客都攻击到你服务器上，反编译你的 jar 包去看配置了，还有安全性可言吗？？？ 如果他没攻上去，配置又怎么会暴露？？？

最后在给你说一次，这个 ip 和具体要调用的接口是两码事，两码事。调用接口不需要显式配置，不需要！！

@tikazyq 哈哈哈哈，自嗨模式？？ 我自己花时间做了个东西出来，分享给大家看看，叫自嗨？？？

我还是那句话，你要是真的有脑子，就学学 你口中的 大佬， 好好学学他们， 说点自己的看法，而不是一个劲的嘲笑。

@tikazyq

1. 在这个项目中 httpUtil 的作用是啥，您真的有有了解过吗？ 仅仅看了一眼这个类就下结论了？？ 建议你看清楚他到底是做啥的，我为什么要这么做，了解清楚在说话。

2. 需要显式？？？ 麻烦你再去看一遍好吗？ 看清楚了再下结论。即使你没看过我的文档，至少也看过我现在被你喷的得这篇文章吧，我在文章里介绍的 两种调用方式 有涉及到显式的 URL 吗？？有吗？

3. 这个我不知道你指啥，有则改之吧。

4. 请问 我官网的文档被你吃了吗？？？ 以及我文档里放的 demo 也被你一起吃了吗？？ 基于你说的第 2 个点 我甚至怀疑你连这篇文章都没看，就狂喷了。

我现在怀疑你 去看代码仅仅是为了找茬，你带着这个目的去的，那就算了好吗？我不需要你的鼓励和支持，你可以出门左拐，只要别在这大放厥词就行，谢谢您了。


最后，我只对你大动肝火了，因为你没资格说我，却在这大放厥词，是个人都会反击你的。

最后，不受人待见，和没人用是两码事，请你回小学重新学一遍语文吧。

最后的最后，其他人的回复 比你友好多了， 他们都是在谈自己的看法，而不是像你一样大放厥词只会嘲笑和喷粪。

@woshiaha 对，但这个是延迟到问题， 在 B 的状态 很快就会变成宕机的，只要 N 毫秒内没收到心跳，立刻会被判定为宕机。 不过这个延迟是无法避免的，即使是 zk 通知 也是有延迟的。

而且我的 心跳机制并不是群体互相检测的哦，而是有我告诉大家我还活着，并不是你帮我告诉大家我还活着。

这位大佬 [Sunmxt ] ，对我的意思理解的比较透彻，因为提出的问题比较犀利，也是我一直在想办法解决的问题

@tikazyq 你这种人就是 闲着蛋疼， 看到别人做东西，就过来疯狂嘲笑，我建议你去看看精神科，我认真的建议你。

@tikazyq 有屁可以直接放，2 年只有 200 多个有什么问题吗？ 你别忘了，我做的这个领域可不是蓝海，而是被 spring 统治的红海。

你认知中的那些 随便发发文章就上千 star 的项目

1. 要么是 XX 管理系统，帮人偷懒用的
2. 要么只是依附于 spring 的小工具
3. 要么是某科技巨头发布的
4. 要么是蓝海的东西

请问有可比性吗？

最后，我还是那句话，有屁可以直接放，不用拐弯抹角，给我分享个百科是想干嘛？劝我放弃吗？

我还想说你病的不轻呢，你不感兴趣就滚出去，在这大放厥词干嘛？ 你要真有脑子，就学学你口中的众佬，说说你的看法。

@Sunmxt 是的，所以还有很长的路要走，我需要再好好考虑下细节，不断优化才行。

@Kirsk

可能是我理解的不够透彻吧， 我先说下我的理解，欢迎指正：

1. 注册中心主要做这三件事： 储存接口，服务上线通知, 服务下线通知。

2. 微服务在启动时会从注册中心获取一次接口，然后缓存在本地， 本地缓存的接口在收到 服务上下线通知后会更新。

3. 调用时，都是从本地缓存获取对应的接口，然后按照负载均衡的方式筛选 调用。 所以即使注册中心挂了，也不影响正在运行的微服务。

上面三个点整理出几个关键词：获取接口，本地缓存，上下线通知。 这几个关键词，目前我都是满足的。

其他跟注册中心无关的东西，比如负载均衡，熔断等，都不受影响

-----------------------------------------------------------------------------

不过肯定还有很多我没想到的细节，欢迎指正与指教

@myCupOfTea 其实你楼上说的 比较符合我的想法。

先来说说 有注册中心的时候：

1. 启动时会从注册中心获取一套接口，缓存在本地。
2. 定时给注册中心发送心跳告诉他 自己还活着。
3. 注册中心会给其他服务发送通知，告诉他们那些服务已经下线了，然后收到通知的服务会从本地删除相应的接口。

而我现在这套思路：

1. 上面第一条 依然保留，只不过他不是从 zk，nacos 获取一套接口，而是从配置文件中配置的的那个服务上获取
2. 上面第二点依然保留，只不过他不是心跳给 zk，nacos，而是心跳给其他服务。
3. 如果自己挂了，他是无法通知别人的，但是每个微服务本地的缓存 都有失效时间的，只要没按时收到心跳就会删除本地缓存

所以整个考虑下来，其实并没有多做什么事。

至于负载均衡，熔断啥的，本身也跟注册中心没啥关系吧， 负载均衡目前我是提供了的， 熔断 还在开发中。

@xuanbg 对啊，但是这个写死的地址，只在服务启动时 用一下，后面都用不到了。所以 问题不大，哈哈哈。

@xuanbg 首先第一次部署，就是项目从 0-1 的上线，这个时候，肯定是需要规划 有几台服务器，哪个服务器部署哪个服务吧？

那就好办了啊，你开发的每个微服务，只需要配置一个这批服务器中的任意 ip:port 即可。

其他的，框架会自己解决。

然后如果想新加一个服务，只需要把新加的服务 连接到 正在运行的 任意一个服务即可。

@xupefei 如果有 N 个微服务，那么相对于任意一个微服务来说，他最多将自己的接口传染 N 次。 而且是在内网传播，纯内存操作。 传染出去的接口，仅仅是自己的接口，数量相对有限。

什么时候会传染别人的接口呢？

别人主动找他要的时候，才会给。 这样算的话，在一整个微服务中，不可能所有人都找这一个机器要接口吧？ 只要稍微设置合理一点就好了

@xuanbg 再补充一下，写死指的是，告诉 A，B 在哪里， 并不是把 B 的接口在 A 里写死， 千万别误解哦

@fatedier 嗯~ 可能我没理解你说的意思，也可能是你没理解我说的意思。

这么说吧，即使是现在流行的 分布式架构模式， 每个微服务本地也是缓存了一套接口的。 而我现在只是改变了，服务与服务之间 互相发现的 机制。 其他并没什么变化。