提交gRPC

提交gRPC

目录前言gRPC-spring-boot-starter是什么？选型gRPC-spring-boot-starterbug出现，grpc未优雅下线定位bug，寻找真实原因模拟环境，反复验证验证定位的bug验证修复后的效果

前言

pr地址：https://github.com/yidongnan/grpc-spring-boot-starter/pull/454

gRPC-spring-boot-starter是什么？

这是一个spring-boot-starter项目，用来在spring boot框架下，快速便捷的使用grpc技术，开箱即用。它提供如下等功能特性：

在 spring boot 应用中，通过@GrpcService自动配置并运行一个嵌入式的 gRPC 服务。使用@GrpcClient自动创建和管理您的 gRPC Channels 和 stubs支持Spring Cloud(向Consul或Eureka或Nacos注册服务并获取 gRPC 服务端信息)支持Spring Sleuth作为分布式链路跟踪解决方案(如果brave-instrument-grpc存在)支持全局和自定义的 gRPC 服务端/客户端拦截器支持Spring-Security支持metric (基于micrometer/actuator)也适用于 (non-shaded) grpc-netty

选型gRPC-spring-boot-starter

博主新入职公司接手的项目采用grpc做微服务通讯框架，项目底层框架采用的spring boot，然后grpc的使用是纯手工配置的，代码写起来比较繁琐， 而且这种繁琐的模板化代码充斥在每个采用了grpc的微服务项目里。所以技术选型后找到了gRPC-spring-boot-starter 这个开源项目，这个项目代码质量不错，非常规范，文档也比较齐全。但是鉴于之前工作经验遇到过开源项目的问题（博主选型的原则，如果有合适的轮子，就摸透这个轮子，然后基于这个轮子二开，没有就自己造一个轮子），而且一般解决周期比较长，所以 最后，我们没有直接采用他们的发行包，而是fork了项目后，打算自己维护。正因为如此，才为后面迅速解决问题上线成为可能。也验证了二开这个选择是正确的。

bug出现，grpc未优雅下线

风风火火重构了所有代码，全部换成gRPC-spring-boot-starter后就上线了，上线后一切都非常好，但是项目在第二次需求上线投产时发生了一些问题。 这个时候还不确定是切换grpc实现导致的问题，现象就是，线上出现了大量的请求异常。上线完成后，异常就消失了。后面每次滚动更新都会出现类似的异常。 这个时候就很容易联系到是否切换grpc实现后，grpc未优雅下线，导致滚动更新时，大量的进行中的请求未正常处理，导致这部分流量异常？因为我们线上 流量比较大，几乎每时每刻都有大量请求，所以我们要求线上服务必须支持无缝滚动更新。如果流量比较小，这个问题可能就不会暴露出来，这也解释了之前和同事讨论的点，为什么这么明显的问题没有被及早的发现。不过都目前为止，这一切都只是猜测，真相继续往下。

定位bug，寻找真实原因

有了上面的猜测，直接找到了gRPC-spring-boot-starter管理维护GrpcServer生命周期的类GrpcServerLifecycle，这个类实现了spring的SmartLifecycle接口，这个接口是用来注册SpringContextShutdownHook的钩子用的，它的实现如下：

@Slf4j

public class GrpcServerLifecycle implements SmartLifecycle {

private static AtomicInteger serverCounter = new AtomicInteger(-1);

private volatile Server server;

private volatile int phase = Integer.MAX_VALUE;

private final GrpcServerFactory factory;

public GrpcServerLifecycle(final GrpcServerFactory factory) {

this.factory = factory;

}

@Override

public void start() {

try {

createAndStartGrpcServer();

} catch (final IOException e) {

throw new IllegalStateException("Failed to start the grpc server", e);

}

}

@Override

public void stop() {

stopAndReleaseGrpcServer();

}

@Override

public void stop(final Runnable callback) {

stop();

callback.run();

}

@Override

public boolean isRunning() {

return this.server != null && !this.server.isShutdown();

}

@Override

public int getPhase() {

return this.phase;

}

@Override

public boolean isAutoStartup() {

return true;

}

/**

* Creates and starts the grpc server.

*

* @throws IOException If the server is unable to bind the port.

*/

protected void createAndStartGrpcServer() throws IOException {

final Server localServer = this.server;

if (localServer == null) {

this.server = this.factory.createServer();

this.server.start();

log.info("gRPC Server started, listening on address: " + this.factory.getAddress() + ", port: "

+ this.factory.getPort());

// Prevent the JVM from shutting down while the server is running

final Thread awaitThread = new Thread(() -> {

try {

this.server.awaitTermination();

} catch (final InterruptedException e) {

Thread.currentThread().interrupt();

}

}, "grpc-server-container-" + (serverCounter.incrementAndGet()));

awaitThread.setDaemon(false);

awaitThread.start();

}

}

/**

* Initiates an orderly shutdown of the grpc server and releases the references to the server. This call does not

* wait for the server to be completely shut down.

*/

protected void stopAndReleaseGrpcServer() {

final Server localServer = this.server;

if (localServer != null) {

localServer.shutdown();

this.server = null;

log.info("gRPC server shutdown.");

}

}

}

也就是说当spring容器关闭时，会触发ShutdownHook，进而关闭GrpcServer服务，问题就出现在这里，从stopAndReleaseGrpcServer()方法可知，Grpc进行shudown()后，没有进行任何操作，几乎瞬时就返回了，这就导致了进程在收到kill命令时，Grpc的服务会被瞬间回收掉，而不会等待执行中的处理完成，这个判断可以从shutdown()的文档描述中进一步得到确认，如：

/**

* Initiates an orderly shutdown in which preexisting calls continue but new calls are rejected.

* After this call returns, this server has released the listening socket(s) and may be reused by

* another server.

*

*

Note that this method will not wait for preexisting calls to finish before returning.

* {@link #awaitTermination()} or {@link #awaitTermination(long, TimeUnit)} needs to be called to

* wait for existing calls to finish.

*

* @return {@code this} object

* @since 1.0.0

*/

public abstract Server shutdown();

文档指出，调用shutdown()后，不在接收新的请求流量，进行中的请求会继续处理完成，但是请注意，它不会等待现有的调用请求完成，必须使用awaitTermination()方法等待请求完成，也就是说，这里处理关闭的逻辑里，缺少了awaitTermination()等待处理中的请求完成的逻辑。

模拟环境，反复验证

验证方法：

这个场景的问题非常容易验证，只需要在server端模拟业务阻塞耗时长一点，然后kill掉java进程，看程序是否会立刻被kill。正常优雅下线关闭的话，会等待阻塞的时间后进程kill。否则就会出现不管业务阻塞多长时间，进程都会立马kill。

验证定位的bug

先验证下是否如上面所说，不加awaitTermination()时，进程是否立马就死了。直接使用gRPC-spring-boot-starter里自带的demo程序，在server端的方法里加上如下模拟业务执行耗时的代码：

@GrpcService public class GrpcServerService extends SimpleGrpc.SimpleImplBase {

@Override

public void sayHello(HelloRequest req, StreamObserver responseObserver) {

HelloReply reply = HelloReply._newBuilder_().setMessage("Hello ==> " \+ req.getName()).build();

try {

System._err_.println("收到请求，阻塞等待");

TimeUnit._MINUTES_.sleep(1);

System._err_.println("阻塞完成，请求结束");

} catch (InterruptedException e) {

e.printStackTrace();

}

responseObserver.onNext(reply);

responseObserver.onCompleted();

}

}

上面代码模拟的执行一分钟的方法，然后触发grpc client调用。接着找到server端的进程号，直接kill掉。发现进程确实立马就kill了。继续加大阻塞的时间，从一分钟加大到六分钟，重复测试，还是立马就kill掉了，没有任何的等待。

验证修复后的效果

先将上面的代码修复下，正确的关闭逻辑应该如下，在Grpc发出shutdown指令后，阻塞等待所有请求正常结束，同时，这里阻塞也会夯住主进程不会里面挂掉。

protected void stopAndReleaseGrpcServer() {

final Server localServer = this.server;

if (localServer != null) {

localServer.shutdown();

try {

this.server.awaitTermination();

} catch (final InterruptedException e) {

Thread.currentThread().interrupt();

}

this.server = null;

log.info("gRPC server shutdown.");

}

}

同样，如上述步骤验证，当kill掉java进程后，此时java进程并没有立马就被kill，而是被awaitTermination()阻塞住了线程，直到业务方法中模拟的业务阻塞结束后，java进程才被kill掉，这正是我们想要达到的优雅下线关闭的效果。被kill时的，线程堆栈如下：

即使被kill了，还是能打印如下的日志【阻塞完成，请求结束】，进一步验证了修复后确实解决了问题：

以上就是提交gRPC-spring-boot-starter项目bug修复的pr说明的详细内容，更多关于gRPC-spring-boot-starter项目提交bug修复pr说明的资料请关注我们其它相关文章！

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。