内容简介：经过了 几个月的琢磨，最终还是决定 将Martian-cloud的 心跳机制还原，去除投票机制。 因为经过一些简单地计算 发现，心跳机制带来的内网压力并不是很大， 原因如下 我们以一个10个模块的项目为例子，假如每个模块...
经过了 几个月的琢磨，最终还是决定 将Martian-cloud的 心跳机制还原，去除投票机制。 因为经过一些简单地计算 发现，心跳机制带来的内网压力并不是很大，
原因如下
我们以一个10个模块的项目为例子，假如每个模块部署3个服务，那就是30个服务，在最极端的情况下 这30个服务会同时发送心跳给其余的29个服务，也就是说会产生 30*29=870个 心跳包，在内网传输这么多消息 其实压力真的不大，也就1-3秒钟左右的时间吧， 而且这是最极端的情况。
现实中，这10个模块不会同时启动，所以触发心跳的 定时任务 不会在同一时刻 都一起执行，并且每个服务的负载情况也不相同，所以定时任务执行的效率也不同，这就导致了执行周期的参差不齐， 综合考虑到这些因素后不难看出，很难出现 同时发送870个心跳包的情况，
心跳机制是3秒一次，并不频繁，不会出现自我DDoS的情况
假如模块不止10个，又或者每个模块不止部署3个服务呢
到目前为止，Martian-cloud的设计 都是针对中小型项目的，并非大型项目，在这个场景下 30个服务已经很够用了。
除了上面原因，还有投票本身带来的一些劣势
投票机制只能顾到自己，不能顾到整体，所以会出现短暂的数据不一致的情况，虽然最终一致性可以保证，但是我们可以举个例子：比如A服务挂了，B服务调用A服务失败了一定次数 就会将它下掉，但是C服务 还没调满次数，所以还在，这个时候会出现C服务上调用A服务报错的情况， 也就是说 一个服务挂了，会导致很多服务出现短暂的异常，影响全局。
投票机制增加了一定的程序复杂性，更消耗内存和CPU，因为需要记录票数 以及 判断票数，并且在达到票数之前 还会出现因为接口调用不通而出现异常的情况。
考虑到这些问题后，就做出了今天的这个决定，将心跳机制还原。
如果您之前没有了解过Martian-cloud，看到这肯定一头雾水，但是没关系，可以看一下这个详细原理介绍：https://my.oschina.net/yuyenews/blog/4723747
更多信息可以查看官网：http://mars-framework.com
以上所述就是小编给大家介绍的《Martian-cloud 发布 4.1.0，还原心跳机制》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
