大家好,今天小编来为大家解答以下的问题，关于初步认识微服务与资源服务器，这个很多人还不知道，现在让我们一起来看看吧！

传统安全方式的不足

在Spring Security教程系列中，我们一步步学习了Spring Security的使用。其中大多数涉及保护应用程序的传统方法。我们通过用户名和密码（或验证码）获取服务器给出的凭证（JWT就是其中之一），然后携带凭证去请求接口获取相应的资源（Resource）。对于大多数单体应用程序来说，这种模式非常方便且简单。

但一旦你的项目变大，需要改造成微服务，使用这种方法就变得有点麻烦了。每个服务的资源都需要认证和授权，因此需要一个范例来简化这个过程。

认证和授权是可以松耦合的用户认证和资源访问控制其实是可以分开的。例如，如果你购买机票，现在你不仅可以在航空公司的票务部门购买，还可以去第三方票务中心线下或网上购买。最后，您的机票将针对每个航班进行验证。确定您是否有资格注册，而不关心您在哪里购买门票。这是一个现实生活中的例子。

如果在微服务中，我们每个服务只需要验证请求是否有访问资源的权限，我们可以将资源访问验证的逻辑抽象成一个通用的模型，并用代码来实现，这与微服务非常一致。集中思想。这就是资源服务器的根本意义。

资源服务器

资源服务器的全称是OAuth2 Resource Server，它实际上是OAuth 2.0协议的一部分。我们通常借助Json Web Token 来实现它（实际上，还有另一种称为Opaque Tokens 也可以使用）。 OAuth2.0授权服务器向客户端发送Json Web Token。该Token用于验证客户端是否有权限访问某个资源。

当单体应用改造为微服务时，授权服务其实还是集中化比较好，用户的认证授权统一管理，发放给客户端Token。每个具体服务也是一个资源服务器。我们只需要抽象出访问控制接口即可。这里遵循一个原则：将通用功能封装到类库（jar）中，将个性化抽象配置到配置中。大致流程图如下：

微服务认证授权流程

这样，授权服务器只负责发放Token，资源服务器只负责验证Token。每当接入新服务时，我们只需要添加支撑资源服务依赖和配置即可，改造非常简单。

还有一种方式是互联网上资源服务器集中化，即在网关处进行集中认证处理。我个人认为不太容易接受，除非你有类似的经历，而且你还要处理一些安全上下文跨服务的问题。上述模型强烈推荐给初学者。

事实上，我已经对上述模型进行了初步的实现和改造。在下一篇文章中，我将讲解如何使用Spring Security在微服务中实现资源服务器，以及单体应用转为微服务的一些关键点。