经过了 几个月的琢磨，最终还是决定 将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
