问题解决系列：io.grpc.netty.shaded.io.netty.handler.ssl.NotSslRecordException_ not an SSL_TLS record

问题场景

最近使用公司微服务框架开发后台，要调用由​​python​​​写的服务端接口。这里我们是使用了​​grpc​​​来做不同语言之间的接口调用。已知​​python​​服务端是开启着的，而在测试过程，发现后台报错，报错提示如下：

Caused by: io.grpc.StatusRuntimeException: UNAVAILABLE: io exception
Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
  at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:244)
  at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:225)
  at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:142)
  at AlarmCategory.AlarmCategoryGrpc$AlarmCategoryBlockingStub.getAlarmCategory(AlarmCategoryGrpc.java:169)
  
  ... 97 common frames omitted
Caused by: io.grpc.netty.shaded.io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 000018040000000000000400400000000500400000000600002000fe0300000001000004080000000000003f00010000080600000000000000000000000000
  at io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1214)
  at io.grpc.netty.shaded.io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1282)
  at io.grpc.netty.shaded.io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:498)
  at io.grpc.netty.shaded.io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:437)
  
  ... 1 common frames omitted

问题环境

问题原因

通过查看相关的文档，才知道，同事的​​python​​​服务端的​​grpc​​​使用了​​PLAINTEXT ​​​模式，而我的客户端默认是使用了​​TLS​​模式。两边模式不同，导致我的请求过去，服务端解析不了，然后就会报这个问题。

解决方案

这里有两种方案：

一、简单快捷

因为我是使用了​​grpc-client-spring-boot-starter​​​来简化使用​​grpc​​，所以直接在配置文件加入以下的配置，如下：

grpc.client._server_name_.negotiationType=PLAINTEXT

这里的​​_server_name​​是由开发者自定义的。按照这种方法，重启之后，果然可以正常通信了！

二、安全但有点繁琐

在服务端使用​​TLS​​​模式。假如服务端开发是使用了​​grpc-client-spring-boot-starter​​​，则在生成对应的​​crt​​​和​​key​​文件之后，可以加入以下配置（记得把路径修改成自己的文件路径），然后重启即可。

grpc.server.security.enabled=true
grpc.server.security.certificateChain=file:certificates/server.crt
grpc.server.security.privateKey=file:certificates/server.key

结果

我这里使用了第一种方式，简单快捷地解决了问题。因为服务端是由其他语言进行编写，如果要沟通进行修改，耗费的时间和精力比较多。目前是属于测试阶段，可以先让应用跑起来。等需要完善的时候，再进行完善。

总结

不同语言之间的通信，可以使用业界已经比较成熟的组件来进行开发，这样减少重复造轮子的时间精力，也可以快速地迭代进行开发，缩短开发周期。

参考链接

​​grpc-spring-boot-starter问题解答​​

随缘求赞

如果我的文章对大家产生了帮忙，可以在文章底部点个赞或者收藏；

如果有好的讨论，可以留言； 如果想继续查看我以后的文章，可以左上角点击关注 可以扫描以下二维码，关注我的公众号：枫夜之求索阁，查看我最新的分享！