Martian-cloud 4.0,跟注册中心拜拜了,基于传染机制的分布式组件诞生

2020-11-10 19:18:15 +08:00
 Joker123456789

基于传染机制的分布式组件

项目简介

Martian-cloud 是 Martian 的官方分布式组件,基于传染机制,不再需要注册中心

  1. 完全丢弃了注册中心,且不依赖任何注册中心,采用传染机制实现服务的发现与治理
  2. 服务间通话采用 rest 风格
  3. 对 Martian 的侵入非常小

什么是传染机制

比如我们现在有三个服务

http://mars-framework.com/img/ws-blank.png
这些服务之间是相互独立的,他们无法发现对方,所以我们需要做一些事

可以将他们连接起来

比如像这个样子 [图 1 ]

http://mars-framework.com/img/ws-one.png

也可以是这样子 [图 2 ]

http://mars-framework.com/img/ws-two.png
连接方式随意,只要别让任何服务落单即可

当这些服务连接后,会发生什么

我们用图 1 来举例

  1. 当 A 启动时,此时只有一台服务,所以相安无事,完全独立
  2. 当 B 启动时,由于 A 连接的是 B,所以 A,B 之间产生了关系,他们的接口会互相传染,此时 A 中有 B 的接口,B 中有 A 的接口
  3. 当 C 启动时,由于 B 连接的是 C,所以 B,C 之间产生了关系,而 B 和 A 又存在关系,所以三台服务器都产生了关系,他们的接口再一次相互传染了,此时 A,B,C 都有对方的完整接口列表
  4. 如果三台服务中任意一个宕机了,也没关系,因为他们的接口已经传染开了,所有服务都产生了联系,可以跳过一开始的传染途径,直接进行感染
  5. 宕机的这个服务的接口会从其他的服务上自动消失

使用起来也很简单

一、 仅需一个依赖

<dependency>
    <groupId>com.github.yuyenews</groupId>
    <artifactId>mars-cloud-starter</artifactId>
    <version>最新版,具体看《组件介绍》</version>
</dependency>

二、 支持 Feign 调用

/* 
这个注解的 serverName 跟你要调用的那个服务的 name 一致(配置类里 cloud 配置的 name ) 
beanName 不写的话,默认为类名首字母小写
*/
@MarsFeign(serverName="mars-demo",beanName="demoFeign")
public interface DemoFeign {
    /* 
        这里面的所有方法,跟你要调用的那个 API 中的方法名一致
    */
    返回类型 insert(DemoEntity entity);

    /*
        可以用 @MarsContentType 注解 来指定本次请求的 ContentType
    */
    @MarsContentType(ContentType = ContentType.JSON)
    返回类型 selectList(DemoEntity entity);
}

三、 也支持 RestTemplate

返回类型 result = MarsRestTemplate.request(服务 name,MarsApi 接口的方法名,new Object[]{参数对象 1,参数对象 2},返回类型.class, ContentType.FORM);

官方网站

http://mars-framework.com/

3660 次点击
所在节点    Java
53 条回复
tikazyq
2020-11-11 16:41:33 +08:00
另外阐述一下自己的不成熟的观点,真正的大佬不是做了多么牛逼的框架,而是这个框架提高了多少生产力,真正帮助了多少人,产生了多少真实价值。我深深感觉楼主深深陷入了自嗨的模式而不可自拔,所以推荐你去读一下堂吉柯德,如果你还是停留在自我欣赏自己的框架多有前景,自己的技术能力多么 nb,那么可能你只是现代版的堂吉柯德。以上
Joker123456789
2020-11-11 16:49:29 +08:00
@tikazyq

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

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

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

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

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


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

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

最后的最后,其他人的回复 比你友好多了, 他们都是在谈自己的看法,而不是像你一样大放厥词只会嘲笑和喷粪。
Joker123456789
2020-11-11 16:51:40 +08:00
@tikazyq 哈哈哈哈,自嗨模式?? 我自己花时间做了个东西出来,分享给大家看看,叫自嗨???

我还是那句话,你要是真的有脑子,就学学 你口中的 大佬, 好好学学他们, 说点自己的看法,而不是一个劲的嘲笑。
Joker123456789
2020-11-11 17:04:49 +08:00
你说的第 2 个点 我在给你耐心说一次:

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

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

还有一点!!!!

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

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

最后在给你说一次,这个 ip 和具体要调用的接口是两码事,两码事。调用接口不需要显式配置,不需要!!
cominghome
2020-11-11 17:05:26 +08:00
感觉“不稳定”因素太多了,相比之下多维护一个注册中心简直香爆
myCupOfTea
2020-11-11 17:16:29 +08:00
其实显示的 url 也不是问题,url 写成 xxx-service.com 然后用 k8s 路由来映射到对应的 ip 上
PiersSoCool
2020-11-11 17:37:35 +08:00
就是 gossip 吧

提个问题,假设只有两个节点,A 和 B,启动的时候网络断了,启动之后连接上了,A 和 B 都觉得自己的信息正确,怎么破?
Joker123456789
2020-11-11 17:52:31 +08:00
@PiersSoCool 获取接口和发送广播的动作是 轮询的,不是一次性的。 数据会被慢慢纠正。

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

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

这也是我下一步要 解决的问题。
rrfeng
2020-11-11 18:06:39 +08:00
ES 集群支持类似机制。
liuhan907
2020-11-12 00:19:32 +08:00
所以说到底,这不就是最原始的 gossip 么,不带优化的那种…
Joker123456789
2020-11-12 09:31:54 +08:00
@liuhan907 首先呢,我也是发布了这篇文章后才知道 gossip 这个名词的, 后来我专门去大致了解了一下。

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

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

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

我后面的重点,也是想办法解决这个问题,东西嘛,都是慢慢试错试出来的。
liuhan907
2020-11-13 00:00:49 +08:00
@Joker123456789 思路有些奇怪。集群成员维护和服务列表维护应该分为两个部分,杂糅在一起不便于扩展和维护。如果你喜欢去中心的协议,建议参考或者使用 consul 开源的 swimming 协议库,名字就叫 memberships 貌似。而服务列表维护可以参考微软开源的 Orleans 如何维护 actor 接口信息的。
另,我说没有优化一是说协议的发包数量,二是指数据同步的收敛速度。
jeesk
2022-12-24 03:08:13 +08:00
dubbo 早就有了,多播。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/723703

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX