一个开源分布式微服务RPC框架 ~ 正式发布

Posted 延年有余

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一个开源分布式微服务RPC框架 ~ 正式发布相关的知识,希望对你有一定的参考价值。

介绍

一个分布式微服务RPC框架 | 英文说明文档

1. 服务提供

  • 负载均衡策略
  • 序列化策略
  • 自动发现和注销服务
  • 注册中心

    2. 安全策略

  • 心跳机制
  • 信息摘要

    3. 设计模式

  • 单例模式
  • 动态代理
  • 静态工厂
  • 建造者
  • 策略模式
  • Future(观察者)

    亮点

    1. 信息摘要算法的应用

    对于信息摘要算法的使用,其实并不难,在数据包中添加 String 类型的成员变量 checkCode 用来防伪的就可以实现。

  • 原理

发送端把原信息用HASH函数加密成摘要,然后把数字摘要和原信息一起发送到接收端,接收端也用HASH函数把原消息加密为摘要,看两个摘要是否相同,若相同,则表明信息的完整.否则不完整。

  • 实现

客户端在发出 请求包,服务端会在该请求包在请求执行的结果的内容转成字节码后,使用 MD5 单向加密成为 唯一的信息摘要(128 比特,16 字节)存储到响应包对应的成员变量 checkCode 中,所以客户端拿到响应包后,最有利用价值的地方(请求要执行的结果被改动),那么 checkCode 将不能保证一致性,这就是信息摘要的原理应用。

安全性再增强

考虑到这只是针对客户需求的结果返回一致性,并不能确保请求包之间存在相同的请求内容,所以引入了请求 id

每个包都会生成唯一的 requestId,发出请求包后,该包只能由该请求发出的客户端所接受,就算两处有一点被对方恶意改动了,客户端都会报错并丢弃收到的响应包,不会拆包后去返回给用户。

如果不是单单改动了返回结果,而是将结果跟信息摘要都修改了,对方很难保证修改的内容加密后与修改后的信息摘要一致,因为要保证一致的数据传输协议和数据编解码。

2. 心跳机制

心跳机制的 RPC 上应用的很广泛,本项目对心跳机制的实现很简单,而且应对措施是服务端强制断开连接,当然有些 RPC 框架实现了服务端去主动尝试重连。

  • 原理

对于心跳机制的应用,其实是使用了 Netty 框架中的一个 handler 处理器,通过该 处理器,去定时发送心跳包,让服务端知道该客户端保持活性状态。

  • 实现

利用了 Netty 框架中的 IdleStateEvent 事件监听器,重写userEventTriggered() 方法,在服务端监听读操作,读取客户端的 写操作,在客户端监听写操作,监听本身是否还在活动,即有没有向服务端发送请求。

如果客户端没有主动断开与服务端的连接,而继续保持连接着,那么客户端的写操作超时后,也就是客户端的监听器监听到客户端没有的规定时间内做出写操作事件,那么这时客户端该处理器主动发送心跳包给服务端,保证客户端让服务端确保自己保持着活性。

3. IO 异步非阻塞

IO 异步非阻塞 能够让客户端在请求数据时处于阻塞状态,而且能够在请求数据返回时间段里去处理自己感兴趣的事情。

  • 原理

使用 java8 出世的 CompletableFuture 并发工具类,能够异步处理数据,并在将来需要时获取。

  • 实现

数据在服务端与客户端之间的通道 channel 中传输,客户端向通道发出请求包,需要等待服务端返回,这时可使用 CompletableFuture 作为返回结果,只需让客户端读取到数据后,将结果通过 complete()方法将值放进去后,在将来时通过get()方法获取结果。

快速开始

/**
     * 自定义对象头 协议 16 字节
     * 4 字节 魔数
     * 4 字节 协议包类型
     * 4 字节 序列化类型
     * 4 字节 数据长度
     *
     *       The transmission protocol is as follows :
     * +---------------+---------------+-----------------+-------------+
     * | Magic Number  | Package Type  | Serializer Type | Data Length |
     * | 4 bytes       | 4 bytes       | 4 bytes         | 4 bytes     |
     * +---------------+---------------+-----------------+-------------+
     * |                           Data Bytes                          |
     * |                       Length: $Data Length                  |
     * +---------------+---------------+-----------------+-------------+
     */

1.依赖

1.1 直接引入

首先引入两个jar包文件rpc-core-1.0.0.jarrpc-core-1.0.0-jar-with-dependencies.jar

jar包中包括字节码文件和java源码,引入后会自动把classsources一并引入,源码可作为参考

1.2 maven引入

引入以下maven,会一并引入rpc-common与默认使用的注册中心nacos-client相关依赖

<dependency>
    <groupId>cn.fyupeng</groupId>
    <artifactId>rpc-core</artifactId>
    <version>1.0.0.RELEASE</version>
</dependency>

2. 启动 Nacos

-m:模式standalone:单机

命令使用:

startup -m standalone

官方文档:https://nacos.io/zh-cn/docs/quick-start.html

Nacos 启动效果:

3. 提供接口

public interface HelloService 
    String sayHello(String message);

4. 启动服务

  • 真实服务
    @Service
    public class HelloServiceImpl implements HelloService 
    @Override
    public String sayHello(String message) 
        return "hello, here is service!";
    
    
  • 服务启动器
    @ServiceScan
    public class MyServer 
    public static void main(String[] args) 
        try 
            NettyServer nettyServer = new NettyServer("127.0.0.1", 5000, SerializerCode.KRYO.getCode());
            nettyServer.start();
         catch (RpcException e) 
            e.printStackTrace();
        
    
    

5. 启动客户端

初始化客户端时连接服务端有两种方式:

  • 直连
  • 使用负载均衡

    public class MyClient 
    public static void main(String[] args) 
        RoundRobinLoadBalancer roundRobinLoadBalancer = new RoundRobinLoadBalancer();
        NettyClient nettyClient = new NettyClient(roundRobinLoadBalancer, CommonSerializer.KRYO_SERIALIZER);
    
        RpcClientProxy rpcClientProxy = new RpcClientProxy(nettyClient);
        HelloService helloService = rpcClientProxy.getProxy(HelloService.class);
        String result = helloService.sayHello("hello");
        System.out.println(result);
    
    

    5. 额外配置

logback 重写使用

在 resources 中加入 logback.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <!--%dateHH:mm:ss.SSS %c -->
            <pattern>%dateHH:mm:ss.SSS %c [%t] - %m%n</pattern>
        </encoder>
    </appender>

    <root level="info">
        <appender-ref ref="console"/>
    </root>
</configuration>

除此之外,框架还提供了 Socket 方式的 Rpc 服务

6. 场景应用

  • 支持 springBoot 集成

为了支持springBoot集成logback日志,继承rpc-netty-framework使用同一套日志,抛弃nacos-client内置的slf4j-apicommons-loging原有Jar包,因为该框架会导致在整合springboot时,出现重复的日志绑定和日志打印方法的参数兼容问题,使用jcl-over-slf4j-api可解决该问题;

springboot1.02.0版本中,不使用它默认版本的spring-boot-starter-log4j,推荐使用1.3.8.RELEASE
springboot简单配置如下

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <exclusions>
            <!-- 排除 springboot 默认的 logback 日志框架 -->
            <exclusion>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-logging</artifactId>
            </exclusion>
            <!-- 排除 springboot 默认的 commons-logging 实现(版本低,出现方法找不到问题) -->
            <exclusion>
                <groupId>org.springframework</groupId>
                <artifactId>spring-jcl</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

    <!-- 与 logback 整合(通过 @Slf4j 注解即可使用) -->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.10</version>
    </dependency>
    <!--引入log4j日志依赖,目的是使用 jcl-over-slf4j 来重写 commons logging 的实现-->
    <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j</artifactId>
    <version>1.3.8.RELEASE</version>
    </dependency>
</dependencies>

7. 异常解决

  • ServiceNotFoundException

抛出异常ServiceNotFoundException

解决真实服务不存在的情况,导致负载均衡中使用的策略出现异常的情况,修复后会强制抛出ServiceNotFoundException,或许大部分情况是服务未启动。

当然,推荐真实服务应该在服务启动器的内层包中,同层可能会不起作用。

除非使用注解注明包名@ServiceScan("com.fyupeng")

  • ReceiveResponseException

抛出异常data in package is modified Exception

信息摘要算法的实现,使用的是String类型的equals方法,所以客户端在编写Service接口时,如果返回类型不是八大基本类型 + String 类型,也就是复杂对象类型,那么要重写toString方法。

不使用Object默认的toString方法,因为它默认打印信息为16位的内存地址,在做校验中,发送的包和请求获取的包是需要重新实例化的,说白了就是深克隆,必须 重写Object原有toString方法。

为了避免该情况发生,建议所有PoJoVO类必须重写toString方法,其实就是所有真实业务方法返回类型的实体,必须重写toString方法。

  • RegisterFailedException

抛出异常Failed to register service Exception

原因是注册中心没有启动或者注册中心地址端口指定不明。

  • NotSuchMethodException
    抛出异常java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log

出现该异常的原因依赖包依赖了jcl-over-slf4jjar包,与springboot-starter-log4j中提供的jcl-over-slf4j重复了,建议手动删除rpc-core-1.0.0-jar-with-dependenceies.jarorg.apache.commons

  • DecoderException

抛出异常:com.esotericsoftware.kryo.KryoException: Class cannot be created (missing no-arg constructor): java.lang.StackTraceElement

主要是因为Kryo序列化和反序列化是通过无参构造反射创建的,所以使用到Pojo类,首先必须对其创建无参构造函数,否则将抛出该异常,并且无法正常执行。

  • InvocationTargetException

抛出异常:Serialization trace:stackTrace (java.lang.reflect.InvocationTargetException)

主要也是反射调用失败,主要原因还是反射执行目标函数失败,缺少相关函数,可能是构造函数或者其他方法参数问题。

8. 开发说明

有二次开发能力的,可直接对源码修改,最后在工程目录下使用命令mvn clean package,可将核心包和依赖包打包到rpc-netty-framework\\rpc-core\\target目录下,本项目为开源项目,如认为对本项目开发者采纳,请在开源后最后追加原创作者GitHub链接 https://github.com/fyupeng ,感谢配合

对于有兴趣从事开发开源组件,并且想与作者协同开发的,可告知开发者:fyp010311@126.com
RPC 微服务框架正式版本已发布,对于先前体验过程出现任何问题的,可及时与开发者联系,谢谢配合!

以上是关于一个开源分布式微服务RPC框架 ~ 正式发布的主要内容,如果未能解决你的问题,请参考以下文章

RPC协议及实现方式(分布式微服务治理的核心)

腾讯正式对外开源高性能 RPC 开发框架与微服务平台Tars

Dubbo 2.6.3 正式版发布,分布式 RPC 服务框架

云服务架构 - HongHu分布式微服务框架

腾讯开源微服务架构 Tars,高性能 RPC 开发框架

腾讯开源微服务架构 Tars,高性能 RPC 开发框架