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

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

项目简介

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

完全丢弃了注册中心，且不依赖任何注册中心，采用传染机制实现服务的发现与治理
服务间通话采用 rest 风格
对 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 来举例

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

使用起来也很简单

一、仅需一个依赖

<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/

Joker123456789

2020-11-11 09:57:10 +08:00

@myCupOfTea 其实你楼上说的比较符合我的想法。

先来说说有注册中心的时候：

1. 启动时会从注册中心获取一套接口，缓存在本地。
2. 定时给注册中心发送心跳告诉他自己还活着。
3. 注册中心会给其他服务发送通知，告诉他们那些服务已经下线了，然后收到通知的服务会从本地删除相应的接口。

而我现在这套思路：

1. 上面第一条依然保留，只不过他不是从 zk，nacos 获取一套接口，而是从配置文件中配置的的那个服务上获取
2. 上面第二点依然保留，只不过他不是心跳给 zk，nacos，而是心跳给其他服务。
3. 如果自己挂了，他是无法通知别人的，但是每个微服务本地的缓存都有失效时间的，只要没按时收到心跳就会删除本地缓存

所以整个考虑下来，其实并没有多做什么事。

至于负载均衡，熔断啥的，本身也跟注册中心没啥关系吧，负载均衡目前我是提供了的，熔断还在开发中。

Joker123456789

2020-11-11 10:23:57 +08:00

@Kirsk

可能是我理解的不够透彻吧，我先说下我的理解，欢迎指正：

1. 注册中心主要做这三件事：储存接口，服务上线通知, 服务下线通知。

2. 微服务在启动时会从注册中心获取一次接口，然后缓存在本地，本地缓存的接口在收到服务上下线通知后会更新。

3. 调用时，都是从本地缓存获取对应的接口，然后按照负载均衡的方式筛选调用。所以即使注册中心挂了，也不影响正在运行的微服务。

上面三个点整理出几个关键词：获取接口，本地缓存，上下线通知。这几个关键词，目前我都是满足的。

其他跟注册中心无关的东西，比如负载均衡，熔断等，都不受影响

-----------------------------------------------------------------------------

不过肯定还有很多我没想到的细节，欢迎指正与指教

tikazyq

2020-11-11 16:22:24 +08:00

古人云：“不因言废人，不因人废言”

因为楼主恼羞成怒，我有些担心自己的言辞有偏见，就专门看了一下这个项目的代码。

不得不佩服，楼主的代码整体非常整洁，代码结构也很合理，在合适的位置配有注释，这个值得表扬，这个项目适合让新人提升阅读理解开源项目的能力。

但缺点也很明显:
1. 喜欢重复造轮子，例如 HTTP 的 Utility 部分竟然有单独重写 URL 参数的方法，这违背了 DRY 原则（重复造轮子的必要性能否解释下？）
2. 框架似乎是用 REST 来做的远程通信，这要求显式配置需要传播的节点 IP 地址和端口，不管是从安全还是效率上都让人堪忧
3. 层层嵌套的方法太多，这种组织方式显得很冗余，大大降低代码可读性，也有降低灵活性易用性的问题
4. 楼主没有写一些基本的部署教程或步骤，只有通过阅读源码来猜测框架是如何启动的，我甚至有些怀疑楼主是否能用这个框架跑通一个 demo，是否在实际分布式环境中做了测试，实际的效率、易用性、扩展性如何

暂时就这些反馈。

总之，除了这些缺点以外，真正让人持怀疑态度的是楼主没有给出令人信服的测试结果，推销你的框架好，总之要给点证据吧，这些都没有在楼主的描述中体现出来。因此，楼主项目不受人待见，是自然而然的事情，真的没必要大动肝火。建议多学习一下其他的框架，而不是搞这些看上去高大上的框架，酒香不怕巷子深，你这个东西好用，自然有人用，你这个东西不好用，你把它吹上天也没人鸟你。所以，楼主加油