标签：网关 tps 效率 安全 实战 image 获取 大量 security
到目前为止已经实现了一个基于微服务的，前后端分离（这里我用的jquery做的，并不是真的前后端分离，因为我不会vue和angular所以没用）的架构。在网关上做了限流、认证、审计、授权等安全机制，在前端应用上也做了SSO单点登录，
现在的架构存在的问题是：
1，在网关做限流。
在网关上做限流是有问题的，比如订单服务限流是100，库存服务限流也是100，订单服务又调了库存服务。如果网关上给订单转了100个请求，给库存转了100个请求，订单又调了库存，这时候库存就同时接到了200个请求，库存服务就可能挂掉了。
2，身份认证。
现在的做法是，经过了一个OAuth流程以后，给前端服务器发了一个令牌。每次前端发请求的时候都会拿着这个令牌，在网关上，会调用认证服务器校验这个令牌，对应的用户信息是什么。然后在请求头里放了username，去调用其他微服务，其他微服务从请求头里获取到username，就知道当前用户是谁了。
存在的问题是
a) 效率低，在网关上每一个请求都要去认证服务器验令牌。多一次网络请求的开销，认证服务器压力也会变大，同时认证服务器要保证高可用，一旦认证服务器挂了，所有请求就没法验令牌了，所有请求就都没法处理了。
b) 不安全，在代码里传递用户信息的时候，是在请求头里加了个用户名username字段，网关转发到订单服务，是在授权过滤器（最后一个过滤器）里，将token里的username字段放在了请求头，订单服务从请求头拿出来username，就认为是谁。这样其实是不安全的，你说你是张三，订单服务就认为你是张三，你说你是李四，订单服务就认为你是李四。【不能根据请求/请求头里的一个明文的参数来判断一个用户是谁的】
c）用户身份传递麻烦。网关调用订单服务，在请求头放了一个username，订单服务再调用库存服务，需要再将用户名放入请求参数，库存服务才能知道用户是谁，传递起来比较麻烦。
3，授权。
授权的问题和限流的问题类似，在网关上，你控制住了只能调用订单服务，但是订单服务又调用了库存服务。你一访问订单服务实际上又访问到了库存服务了。权限实际上是越权了，没控制住。
4，服务雪崩
通关网关进行调用的时候，当一个服务出现问题的时候，把其他服务都给带死了。比如因为某些原因（网络，数据库），库存服务的响应变慢了，就会导致订单服务也变慢，然后所有调库存服务的服务都变慢，这堆线程都在这等待着，然后这些线程可能又都是通过网关进来的，所以网关上也有一堆线程等待着，最后导致网关上所有的线程都被占住，导致大量的服务都不可用，但是最根上只是一个库存服务导致的。这就是服务雪崩。
本章就是要解决这些个问题。
代码 https://github.com/lhy1234/springcloud-security
Spring Cloud微服务安全实战_6-1_微服务之间的通讯安全之概述
标签：网关 tps 效率 安全 实战 image 获取 大量 security
原文地址：https://www.cnblogs.com/lihaoyang/p/12203586.html
