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