企业级微服务架构下API保护和控制层如何做？
以springcloud来讲，实现api的鉴权及保护，需要配合jwt技术（无状态）来实现，一般有两种方法：
方法一：
直接在网关中设置各种过滤器，并配置一定的路由拦截规则，并将部分用户认证的代码编
以springcloud来讲，实现api的鉴权及保护，需要配合jwt技术（无状态）来实现，一般有两种方法：
方法一：
直接在网关中设置各种过滤器，并配置一定的路由拦截规则，并将部分用户认证的代码编码到网关中，来实现在网关侧的初步鉴权及认证。等于是将系统90%以上的鉴权认证全都压在网关上。所有客户端都请求网关的地址而非微服务的实际地址。当请求通过NGINX到达springcloud网关时，网关取出请求的前缀，再根据代码中配置的前置pre、post、错误error等过滤器选择进入对应的过滤器，根据请求中携带的jwt信息，解析后取出凭证信息，执行自定义的用户登录鉴权认证逻辑（一般是网关服务去调用用户中心服务查用户信息），若用户中心服务返回正确的结果，则网关服务接收到其的响应结果，将过滤器返回null放行，请求继续走到其他微服务中，执行完对应的业务逻辑后，对应业务服务再将结果返回给网关，网关再通过NGINX返回给客户端。
方法二：
原理同上，区别是这里新建一个微服务叫用户授权认证中心。当请求过来时，网关只做最基本的请求验证，如jwt格式是否合法、jwt是否过期这类判断，不再对用户进行鉴权操作，即不在网关查询用户，而是去调用用户授权认证中心，将必要的参数传给此中心的对应http方法，请求后得到结果并返回到网关，网关再给客户端具体的响应（鉴权后失败则返回给客户端失败信息，成功则在网关过滤器中放行即可）。等于是网关的活少了很多，90%以上的鉴权认证操作都压在授权认证中心上了。
两种办法都可以用，但更建议第二种，比较符合微服务的思想。第一种适合项目初期，规模还不是那么大的时候可以临时用用，流量上来了网关会顶不住，所以长远来看需要新开一个微服务来分流。
