今天来和小伙伴们聊一聊该如何处理 gRPC 中遇到的异常。

在 HTTP 请求中，我们发送请求的时候，可以设置一个请求超时时间-connectTimeout，即在指定的时间内，如果请求没有到达服务端，为了避免客户端一直进行不必要的等待，就会抛出一个请求超时异常。

[TOC]

上篇文章松哥和小伙伴们聊了在 gRPC 中如何使用拦截器，这些拦截器有服务端拦截器也有客户端拦截器，这些拦截器的一个重要使用场景，就是可以进行身份的校验。当客户端发起请求的时候，服务端通过拦截器进行身份校验，就知道这个请求是谁发起的了。今天松哥就来通过一个具体的案例，来和小伙伴们演示一下 gRPC 如何结合 JWT 进行身份校验。

今天我们继续 gRPC 系列。

前面松哥跟大家聊了 gRPC 的简单案例，也说了四种不同的通信模式，感兴趣的小伙伴可以戳这里：

温馨提示：本文需要结合上一篇 gRPC 文章一起食用，否则可能看不懂。

前面一篇文章松哥和大家聊了 gRPC 的基本用法，今天我们再来稍微深入一点点，来看下 gRPC 中四种不同的通信模式。

这篇文章本来要在年前和小伙伴们见面，但是因为我之前的 Mac 系统版本是 10.13.6，这个版本比较老，时至今天在运行一些新鲜玩意的时候有时候会有一些 BUG（例如运行最新版的 Nacos 等），运行 gRPC 的插件也有 BUG，代码总是生成有问题，但是因为系统升级是一个大事，所以一直等到过年放假，在家才慢慢折腾将 Mac 升级到目前的 13.1 版本，之前这些问题现在都没有了，gRPC 的案例现在也可以顺利跑起来了。

年过完啦，松哥也已经搬砖搬了三天了。

玩过微服务的小伙伴对 Spring Cloud 中的的 Spring Cloud Gateway 多多少少都有一些了解，松哥之前既写过相关的文章，也录过相关的视频跟小伙伴们介绍 Spring Cloud Gateway，不过在之前的介绍中，我可能更加侧重于跟小伙伴们介绍 Spring Cloud Gateway 的用法，对于我们在微服务中为什么要使用 Spring Cloud Gateway 可能没有和大家仔细分析过，最近年前得空，我们来一起探讨一下这个话题。

今天我们来聊一下微服务项目中的版本号要怎么设计。

说起 REST API，小伙伴们多多少少都有听说过，但是如果让你详细介绍一下什么是 REST，估计会有很多人讲不出来，或者只讲出来其中一部分。