提交gRPC-spring-boot-starter项目bug修复的pr说明提交gRPC-spring-boot-starter项目b

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

前言为了更好的说明给gRPC-spring-boot-starter项目提交bug修复的pr的原因，解答作者的问题。以博文的形式记录了整个过程的上下文，目前pr未合并还在沟通处理中，希望此博文可以更清楚描述问题
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的钩子用的，它的实现如下：

@Slf4jpublic 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; }@Overridepublic void start() {try {createAndStartGrpcServer(); } catch (final IOException e) {throw new IllegalStateException("Failed to start the grpc server", e); }}@Overridepublic void stop() {stopAndReleaseGrpcServer(); }@Overridepublic void stop(final Runnable callback) {stop(); callback.run(); }@Overridepublic boolean isRunning() {return this.server != null && !this.server.isShutdown(); }@Overridepublic int getPhase() {return this.phase; }@Overridepublic 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 runningfinal 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 {@Overridepublic 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说明的详细内容，更多关于gRPC-spring-boot-starter项目提交bug修复pr说明的资料请关注脚本之家其它相关文章！