Spring Cloud Gateway 学习路线图
一、引入网关的背景
在微服务架构中，每个服务都是一个可以独立开发和运行的组件，而一个完整的微服务架构由一系列独立运行的微服务组成。其中每个服务都只会完成特定领域的功能，比如订单服务提供与订单业务场景有关的功能、商品服务提供商品展示功能等。各个微服务之间通过轻量级通信机制REST API或者RPC完成通信。
实现微服务之后在某些层面会带来一定的影响，比如一个用户查看一个商品的详情，对于客户端来说，可能需要调用商品服务、评论服务、库存服务、营销服务等多个服务来完成数据的渲染。如图，在这个场景中，客户端虽然能通过调用多个服务实现数据的获取，但是存在一些问题，比如：
- 客户端需要发起多次请求，增加了网络通信的成本及客户端处理的复杂性。
- 服务的鉴权会分布在每个微服务中处理，客户端对于每个服务的调用都需要重复鉴权。
- 在后端的微服务架构中，可能不同的服务采用的协议不同，比如有HTTP、RPC等。客户端如果需要调用多个服务，需要对不同协议进行适配。
API 网关的作用
网关可以解决这个问题 ，如图所示，在客户端与服务端之间增加了一个API网关。整体来看，网关有点类似于门面，所有的请求都会先经过网关这一层。
对于商品详情展示的场景来说，增加了API网关之后，在API网关层可以把后端的多个服务进行整合，然后提供唯一的业务接口，客户端只需要调用这个接口即可完成数据的获取及展示。在网关中会再消费后端多个微服务，进行统一的整合，给客户端返回唯一的响应。
网关不仅仅只是做一个请求的转发及服务的整合，有了网关这个统一的入口之后，它还能提供以下功能。
-
针对所有的请求进行统一鉴权、限流、熔断、日志
-
协议转化。针对后端多种不同的协议，在网关层统一处理后以HTTP对外提供服务。用过Dubbo框架的读者应该知道，针对Dubbo服务还需要提供一个Web应用来进行协议转化。
-
统一错误码处理
-
请求转发，并且可以基于网关实现内、外网隔离
统一认证鉴权
统一认证鉴权包含如下两部分
- 客户端身份认证：主要用于判断当前用户是否为合法用户，一般的做法是使用账号和密码进行验证。当然，对于一些复杂的认证场景会采用加密算法来实现，比如公、私钥。
- 访问权限控制：身份认证和访问权限一般是相互联系的，当身份认证通过后，就需要判断该用户是否有权限访问该资源，或者该用户的访问权限是否被限制了。
在单体应用中，客户端身份认证及访问权限的控制比较简单，只需要在服务端通过session保存该用户信息即可。但是在微服务架构下，单体应用被拆分成多个微服务，鉴权的过程就变得很复杂。
- 首先要解决的问题是：原来单体应用中session方式已经无法用于微服务场景。
- 其次就是如何实现对每个微服务进行鉴权。
当然，对于第一个问题，目前已经有非常多的成熟解决方案了，比如AccessToken、Oauth(开发API)等。对于第二个问题，我们可以把鉴权的功能抽离出一个统一认证服务，所有的微服务在被访问之前，先访问该认证服务进行鉴权。这种解决方案看似合理，但是在实际应用中，一个业务场景中可能会调用多个微服务，就会造成一次请求需要进行多次鉴权操作，增加了网络通信开销。
如图，增加了API网关之后，在网关层进行请求拦截，获取请求中附带的用户身份信息，调用统一认证中心对请求进行身份认证，在确认了身份之后再检查是否有资源的访问权限。
