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/

3571 次点击
所在节点    Java
53 条回复
xuanbg
2020-11-10 19:39:21 +08:00
没明白的是:A 是怎么连接 B 的?就是 A 使用 Feign 调用了 B 的接口吗?
NCE
2020-11-10 19:42:00 +08:00
接口多了会成为内部 DDOS 攻击么?😂
fatedier
2020-11-10 19:51:56 +08:00
一旦机器变多,服务变多,感觉是一场灾难,和 gossip 协议一样,小规模用用还可以,但是小规模的场景下,又没必要这么复杂。
xiaofan2
2020-11-10 20:04:37 +08:00
有啥好处?
Joker123456789
2020-11-10 20:07:02 +08:00
@xuanbg 第一次连接 是通过配置写死的,但是服务启动后,这个写死的东西就用不到了。 也就是说 在 A 里面先用配置写死连接到 B,一旦 A 启动以后,B 挂了也没事,因为 B 身上的病毒(接口) 已经传染给 A 了。 此时 A 想跟其他服务产生关系,可以通过传染过来的病毒(接口)进行关联
Joker123456789
2020-11-10 20:07:56 +08:00
@xiaofan2 好处不是写出来了吗? 不需要 注册中心啊,少维护了了一套 zk 或者 nacos 集群,就是好处。
Joker123456789
2020-11-10 20:08:37 +08:00
@NCE 你就算用 zk,你的每个微服务本地 也是缓存了一套接口的。我只是改变了 这些服务之间发现的方式而已。

所以你说的问题不存在
Joker123456789
2020-11-10 20:10:57 +08:00
@fatedier 嗯~ 可能我没理解你说的意思,也可能是你没理解我说的意思。

这么说吧,即使是现在流行的 分布式架构模式, 每个微服务本地也是缓存了一套接口的。 而我现在只是改变了,服务与服务之间 互相发现的 机制。 其他并没什么变化。
Joker123456789
2020-11-10 20:12:10 +08:00
@xuanbg 再补充一下,写死指的是,告诉 A,B 在哪里, 并不是把 B 的接口在 A 里写死, 千万别误解哦
xupefei
2020-11-10 20:24:16 +08:00
我没理解错的话,一个用户进来,传染的计算量是指数级的?
ManjusakaL
2020-11-10 20:26:04 +08:00
又重新实现了一套类 etcd 。。。
而且很多问题没法自恰。。
Joker123456789
2020-11-10 20:44:31 +08:00
@xupefei 如果有 N 个微服务,那么相对于任意一个微服务来说,他最多将自己的接口传染 N 次。 而且是在内网传播,纯内存操作。 传染出去的接口,仅仅是自己的接口,数量相对有限。

什么时候会传染别人的接口呢?

别人主动找他要的时候,才会给。 这样算的话,在一整个微服务中,不可能所有人都找这一个机器要接口吧? 只要稍微设置合理一点就好了
EminemW
2020-11-10 21:31:12 +08:00
怎么有点像路由表的原理
xuanbg
2020-11-10 21:52:46 +08:00
@Joker123456789 我倒是没误解,就是没想到 A 的配置文件里面写 B 的地址……扶额
xuanbg
2020-11-10 21:56:37 +08:00
这太糙了吧……注册中心地址是固定的,而服务的地址是一般是动态的。我们如果玩你这一套,我一下子都不知道怎么玩了都。
@Joker123456789
Joker123456789
2020-11-10 22:11:30 +08:00
@xuanbg 首先第一次部署,就是项目从 0-1 的上线,这个时候,肯定是需要规划 有几台服务器,哪个服务器部署哪个服务吧?

那就好办了啊,你开发的每个微服务,只需要配置一个这批服务器中的任意 ip:port 即可。

其他的,框架会自己解决。

然后如果想新加一个服务,只需要把新加的服务 连接到 正在运行的 任意一个服务即可。
Joker123456789
2020-11-10 22:12:16 +08:00
@xuanbg 对啊,但是这个写死的地址,只在服务启动时 用一下,后面都用不到了。所以 问题不大,哈哈哈。
Kirsk
2020-11-10 22:53:04 +08:00
你这个只适合集群 那问题来了 对比注册中心优点在哪 注册中心用来干嘛的? 问题实在太多了 楼主多想想
lix7
2020-11-10 23:16:10 +08:00
就是 gossip 的思想吧,但这么搞怎么实现之前可以通过注册中心去做的那些路由调度、熔断、权重、灰度....
xuanbg
2020-11-11 08:05:13 +08:00
@Kirsk 其实楼主是把每个服务都当做了注册中心……其实我还是宁愿有个独立的注册中心。

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

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

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

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

© 2021 V2EX