阅读 46

Martian-cloud 发布4.1.0,还原心跳机制

经过了 几个月的琢磨,最终还是决定 将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,看到这肯定一头雾水,但是没关系,可以看一下这个详细原理介绍:my.oschina.net/yuyenews/bl…

更多信息可以查看官网:mars-framework.com

文章分类
后端
文章标签