分布式微服务权限校验方式一览

在微服务架构中相比原来的单体服务变的复杂很多，在整个微服务架构中可能有成百上千个服务提供给网页或APP或其他客户端调用。我们不可能为不同的客户端所调用的每一个服务实现一套安全策略，这样是不现实的。

有几种解决方案：

• distribution sesssion
• sidecar proxy
• 共享库
• API网关

distribution session

建立一个服务集群，然后在前面设置一个负载均衡器，通过该负载均衡器可以始终路由到同一个session管理器。比如某个服务有三个节点，用户A访问这个服务时通过负载均衡器都会路由到他上次访问的那个节点，这样它登陆的信息就一直都是在那台服务器的内存或者本地缓存中。这种缺陷也很明显，没有有效的打散流量，还有当服务器故障进行重启或者某种原因粘性失效了，那它将会路由到其他服务器，这个时候就没有用户的信息，需要重新进行认证。这个问题有一种弥补的方案，就是节点之间相互复制session,但是这样会消耗大量的带宽，而且会在授权方面增加复杂性。当然我们也可以有某种集中式的session存储，比如Spring Session中使用Redis或MySQL进行session的存储。这种方式是将问题推到了底层结构，每次去数据存储中校验用户身份，之后如何扩展数据存储方面又要面临更多挑战。在上面的所有方案都是有状态的范式。

sidecar proxy

这种就是在微服务相同的容器或虚拟机中运行另一个服务，这个服务就是sidecar，它处理一些非核心功能，例如日志记录和保证安全性等。这样将他们放在了sidecar增加了程序的复杂性，每次部署新的微服务时，都必须同时部署新的sidecar。

共享库

共享库是一个很古老的方式了，将安全校验问题交给共享库，它就会帮我们完成所有的问题。但是共享库的缺点也很明显，如果我们是一个异构系统，共享库就很明显不能共享了。还有在共享库从1.0升级到2.0的时候怎么将它推送给所有使用它的程序。共享库使各个服务之间耦合的太紧。

API gateway

API gateway通常是在所有微服务的最前面，通过它去路由到各个微服务。程序的安全检查都在gate这个最外层进行处理（除了安全检查，还可以做日志记录，限流等）。任何资源都需要先通过gateway来暴露。微服务可以根据传递给他的权限来控制其内容的授权，我们将讨论身份传播，微服务可以更专注的处理自己的核心业务，而不用关心安全性的问题。同样，它也是一种无状态的身份校验机制，身份信息不在各个微服务中保存，而是通过JWT TOKEN保存。

无状态能带来什么好处

现在很多应用都在云平台或者部署在K8S容器中，它们都有很好的自扩展性，当服务是有状态时会出现distribution session的问题，服务器扩展用户的登录信息会丢失。这样就没有很好的利用它们的优势。无状态服务就可以根据负载状态动态实时进行扩展和缩放。

使用网关还有一个好处是屏蔽了系统内部的结构，有一个统一对外提供服务的出口。这样我们在内部进行单体拆分时，外部是无感知的。网关知道怎么路由到单体，什么时候路由到微服务。

使用API gateway的具体处理方法：

 

使用token返回给前端，而不是直接使用JWT TOKEN。使用TOKNE返回，它相比JWT TOKEN来说更小，也更安全。它没有携带任何用户的信息，不用担心用户的信息泄露。

 

我们有了nginx为什么还要再加一个网关API gateway?

1.业务相关的处理

在API gateway中可以根据不同的业务做不同的处理。比如：不同的业务做不同的日志记录。在nginx中不能做业务相关的处理，nginx更侧重路由和协议的转发。

2.服务器IP频繁更换

现在都是K8S部署，节点的ip都不固定，使用nginx需要频繁的reload。当然也不是完全做不了，openresty提供了lua扩展的能力，但lua毕竟没有Java用的人多，维护起来比较麻烦。

使用API gateway可以和注册中心配合，解决这种问题。

3.监控限流，缓存

使用API gateway可以有更丰富的限流策略，缓存方式。

等等。。。

 

 

参考资料

https://www.simtoco.com/#/albums?id=1000039