这一章来讲一下，微服务之间的通讯安全。
当前这个架构还存在的问题
在网关上做限流还是有一些问题的。例如我的订单服务限流是100，库存服务限流也是100。但是我的订单服务会调用我的库存服务。那么在网关这，给订单转100个请求，库存转100个请求，最后订单又调了库存，库存会同时受到200个请求。这时候库存服务可能就挂掉了。
这是在网关这里做限流，可能会出现的一些问题。
第二个问题就是身份认证。
效率低，在网关上每一个请求都要去认证服务器验令牌。这样就会导致多一次网络请求的开销。同时我的认证服务器压力就会很大，而且还要保证高可用。而且一旦我的认证服务器坏了，没法验令牌了。所有的请求就都没法处理了。
不安全：在传递用户信息的时候，是在请求头里面加了个username，然后把用户名放进去了。 订单服务从请求头里就知道他是谁了。
那么我再写一个其他服务，也调用订单服务，下一个订单，在请求头里面传一个张三。订单服务就认为我是张三。传个李四，订单服务就认为我是李四，这样做实际上是不安全的
你不能从头里面一个请求中明文的参数，来判断用户是谁。
第三个问题:传递麻烦，把信息放在请求里面 传给了订单服务，比如说 订单服务还要调用库存服务。那么订单服务调用库存服务的时候，也要在请求头里面再加上username，再去调，库存服务才能知道当前这个用户是谁。传递起来也是比较麻烦的。这是认证面临的一些问题。
授权:和限流的问题类似。例如我在权限控制里面 控制这个人只能访问订单服务，不能访问库存服务。，但是订单服务内部又访问了库存服务。
我一访问订单服务，实际上又访问库存的服务了。权限实际上是越权了。没有限制住，
微服务之间去调用的时候，通过网关调用的时候，还有一个是雪崩。当一个服务出现问题的时候，把其他的服务都给带死了。
比如说我的库存服务。 因为某些原因响应变慢了。比如说是网络的问题，数据库压力大或者是其他的一些问题。我的库存服务变慢了。会导致我的订单服务也变慢。然后所有调用库存服务的服务都变慢。这些线程全都在这等待着，然后这些线程可能都是通过网关进来的。那么网关上也有一大堆线程在这等待着，最后导致所有的服务，你的网关上所有线程都被占住了。
可能订单服务的所有线程都被占住了，最后导致，大量的服务都不能用了。但是最根上只有一个库存服务出了问题。这就是我们说的服务的雪崩，
刚才讲的这些问题就是我们第六章要解决的问题。