到目前为止已经实现了一个基于OAuth2的认证和授权的流程(如下图),订单还是一个单一的节点,还没有进入到微服务的环境下。
实际场景下,类似订单服务的服务,可能有几十个,每个服务是一个集群,有几十个节点,如下图,
在这种场景下,当前微服务架构下的问题:
问题1:安全处理和业务逻辑耦合,增加了复杂性和变更成本
在之前的架构中,订单服务 ,同时又是 资源服务器(如下图),订单服务需要知道认证服务器的地址,去校验令牌,通过token转换为用户信息。也就是安全相关的代码,和业务的代码耦合在了一块。虽然可以把这些资源服务器相关代码提成一个jar包,把跟认证相关的代码做成配置,然后每个服务依赖这个jar包,但本质上是没变的,安全相关的代码还是和业务代码在一块。在微服务环境下,解耦是价值最大的,其他的都要为解耦让路。这样耦合在一块,如果你修改了安全相关的代码,那么依赖这个安全的jar包的服务,都要升级这个jar包,在业务代码没变的情况下,因为安全而要修改配置、重新部署,这如果是在一线互联网企业,有几百、上千、上万的微服务环境下,影响面非常大,这样是不能接受的。
问题2:随着业务节点增加,认证服务器压力增大
随着业务场景的变化,之前的10个微服务,可能拆分成20个服务、50个微服务,某些场景下,比如商城有大促,某些服务要做扩缩容,关键的业务节点要部署加倍,这些个微服务都要到认证服务器验token,可能之前认证服务器能撑住原来那么多服务,但是随着服务节点的增多,超过了认证服务器的最大连接数,把认证服务器的连接都占满了,导致认证服务器不可用,所有依赖认证服务器的服务都不可用,导致这些服务都崩掉了,这也是很大的风险。
问题3:多个微服务同时暴露,增加了外部访问的复杂性
客户端直接和各个服务打交道,增加了客户端访问的复杂性
添加网关:
上边说的三个问题,都可以在添加网关后解决:
1,解决安全处理和业务逻辑耦合:获取令牌、校验令牌等,所有跟安全相关的逻辑,都放在了网关上处理,一旦请求过了,订单服务里只有顶单相关的业务逻辑。
2,解决随着业务节点增加,认证服务器压力增大:顶单等服务,跟认证服务器没有任何交互,不管各个微服务怎么扩,认证服务器是不受影响的。虽然网管也会扩,但是网关扩缩容的频率和幅度,都远不及各个服务。微服务可能是10到20,20到40的扩容,但是网关可能是2个变4个,4个变8个。网关的扩容幅度和频率,远远小于微服务,再怎么扩,网关的数量是远远小于微服务的。
3,解决外部访问的复杂性:所有的请求都只和网关打交道,客户端应用只知道一个网关的地址,由网关转发到各个微服务。
搭建Zuul网关
新建项目:nb-server-gateway
pom加入zuul依赖:
<!-- 网飞的zuul网关 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>
网关端口:9070
yml网关配置
这样配置了之后,访问 http://localhost:9070/token/aaa/bbb ,会被转发到 http://localhost:9090/aaa/bbb
访问 http://localhost:9070/token/ccc/ddd ,会被转发到 http://localhost:9060/ccc/ddd
启动类加上 @EnableZuulProxy 注解
分别启动三个服务:
![](https://img2018.cnblogs.com/blog/702434/201912/702434-20191228034916881-2085881578.png)
现在,客户端访问网关, http://localhost:9070/token/oauth/token ,会被转发到认证服务器(端口9090)的 http://localhost:9090/oauth/token ,来获取令牌,postman实验:
可以成功获取token,说明zuul网关已经帮你把请求转发到了认证服务器9090 。
拿token 访问网关 创建顶单:http://localhost:9070/order/orders
创建成功,说明网关已经将请求转发到了顶单服务。
网关已经初步搭建好了,但是只解决了问题3,客户端访问的复杂性,下面解决两外两个问题。
代码github:https://github.com/lhy1234/springcloud-security/tree/chapt-4-8-gateway01
欢迎关注个人公众号一起交流学习: