内容简介:经过了 几个月的琢磨,最终还是决定 将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,还原心跳机制》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Spring in Action
Craig Walls / Manning Publications / 2011-6-29 / USD 49.99
Spring in Action, Third Edition has been completely revised to reflect the latest features, tools, practices Spring offers to java developers. It begins by introducing the core concepts of Spring and......一起来看看 《Spring in Action》 这本书的介绍吧!