Spring cloud微服务安全实战-4-8Zuul网关安全开发（一）

安全相关的代码和业务逻辑相关的代码实际上是在一个应用里面的，在这个应用里面，我们需要去，这个应用本身的处理逻辑里面需要去处理令牌和用户信息之间的转换。

然后我们需要去知道认证服务器的地址，这些都是耦合。

虽然我们把server.resource这里面的代码提炼成一个公用的jar包

把这些clientId和ClientSecret这些做成配置。然后让各个应用去依赖这个jar包，写不同的配置来实现这样的效果。但实际上本质是没变的。它的安全处理逻辑和你的业务逻辑仍然是在一个应用里面的。在一个应用里面，这就是一种耦合。我们之前说过在微服务环境下解耦是价值最大的一件事。

那么什么叫做安全处理和业务逻辑耦合呢？？？
举个例子，以为大家刚开始接触这个东西，用的是一个比较简单的获取令牌的方式，验令牌的时候也需要验证服务器，随着我们的规模扩大，我们需要一种新的认证方式。，或者说比如我的令牌是存在数据库的 可能以后会改成jwt或者其他的。或者我一开始下用的jwt，后来jwt有安全漏洞需要升级，不管是前面说的那种情况，只要你的安全相关的逻辑发生了变化，你就要升级你提炼出去的那个jar包，你要告诉所有的微服务的团队，你们要升级你们的安全的扎包，这就意味着这些开发微服务的团队在自己业务没有变化的情况下，他要因为你安全处理这方面的逻辑变化，而重新部署，可能还要改相应的配置或者代码等等一些东西。这个在一个比较复杂的微服务环境里面。一些互联网企业可能有几百上千甚至上万的微服务是不可接受的。因为影响面太大了。我们说安全处理和业务逻辑是耦合的，一旦有变化，影响面会非常大。

二是随着业务节点的增加认证服务的压力变大。我们这里验证token实际上是有一个http的请求连接过去的。当然我们可以通过连接池啊之类的技术来限制这个链接的数量，来控制服务器的压力。但是你的微服务本身它是不断的变化的。比如他原来是10个服务，可能过两天，随着业务的发展，10个服务拆成10个服务，或者拆成50个服务。某些服务在某些场景下它也会做去做扩充，比如说明天要大促，那你所有的节点，尤其是关键业务的节点。要部署的节点的数量要加倍。在这样一个场景下的，你的服务器的数量，一直在增长增长。在某些情况下还会快速增长，比如说某些大促的活动。这时候可能你原来能撑住的服务器的压力，因为你的微服务去增长去扩充容，结果他们连过来的连接数，超出了你认证服务器所能承受的连接数，把你认证服务器压死了。把你认证服务器链接都占满了。导致你的认证服务器不可用，然后所有需要依赖认证服务器的做的这些事情，全都不能做了整个都崩掉了。这也是一个在微服务环境下，一个很大的风险。

最后一个就是 多个服务同时暴露，增加了外部访问的复杂性，

从图上可以看到我们的客户端应用和我们的服务是直接打交道的。如果我这是几十个服务，每个服务都有自己的ip，或者说有自己的域名，那么对于我的客户端应用来说，我要访问访问订单服务，要访问这个服务、那个服务，对于我的客户端来说，我要记很多的东西。这就是增加了外部访问的复杂性。

网关

由网关来解决上面的这些问题。所有安全处理的逻辑全都放在网关上面来了。在订单服务里面不再有和安全处理相关的逻辑，它里面就只有业务逻辑。这个令牌怎么拿到，然后这个令牌是不是有效，全都在网关这里来做判断，一旦过了在订单服务这里只执行订单相关的业务逻辑，

网管的扩缩容比微服务的频率要小的多。
对个微服务现在只要 记住一个网关的地址，所有的请求和交互都是和网关交互，网关知道这些微服务在哪。
应用只知道客户端应用，

网关的搭建

原来都拷贝进来。

先把oauth2的依赖去掉。

先把网关搭建起来，让客户端应用只访问网关就可以访问到认证服务器和微服务。注意的一点，认证服务器也是要放在网关后面的。

添加网关zuul的引用

建启动类

加上@EnbaleZuulProxy它就是一个网关了。

那么代码就写完了。

配置

网关没有什么业务逻辑，主要地方就是在配置，通用的已经被封装好了。

首先来配置一下转发的逻辑，路由 路由后面是一个Map，表示可以有多个。

首先是要转发token ，转发给9090端口

order的转发

网关自己跑在9070的端口上。

敏感头

设置为空表示没有任何的头对我来说是敏感头。也就是说 头里的任何信息都往后转发。这样的话，服务才能通。

如果不设置敏感头的话，这个Authorization是转发不过去的。

启动网关服务

认证服务器启动起来。

订单服务 启动起来。

发送到localhost:9070/token这个路径下 后面的路径 oauth/token才是认证服务的路径。

200就说明转发成功了。

拿这个token再来调用一下创建订单的服务。

成功

结束