转载

Spring Cloud微服务架构包含身份验证的源码案例 -Gabriele

什么是微服务架构以及它提供的优势/劣势？

可以轻松制定一系列好处，例如：

安全;
可扩展性;
自我一致，彼此独立;
珍贵美丽的X²和......

所有这些喧嚣的背后，所有美丽的单词都能让时尚成为现实吗？最重要的是，如果我们想要整合身份登录验证的提供者 Identity Provider ，那么什么是解决方案呢？

为了详细解释，我决定构建一个非常简单的项目，演示Spring Cloud的强大功能和身份验证和授权提供程序的美，所有微服务包含在一个专用的Docker容器中，它们可以相互通信并通过docker启动-容易构成。

首先，可以在这里找到这个项目的代码（首先阅读自述文件！）： https://github.com/hyseneim/cloud-application-starter

SpringCloud的架构图：

Spring Cloud微服务架构包含身份验证的源码案例 -Gabriele

源码说明：

Macrocategory 1：

客户：转发请求的主题。它可以是PC，移动设备，智能电视，极限是想象力！

Macrocategory 2：

授权和身份验证提供程序（AAP）：它公开请求访问令牌，刷新令牌和撤销令牌，管理各种流（包括“ 密码 ”流，使用其他微服务）所需的端点。他总是与服务发现/注册处联系，通过该服务发现/注册，他记录并发现其他微服务的位置。
数据库（MySQL）：这个应用程序的DB选择是无关紧要的（显然，修改Spring连接器）。存储的唯一信息与AAP相关，即：用户表，角色，访问/刷新令牌和客户端详细信息。
API网关：通过Zuul实施，它与服务发现/注册表 “ 紧密联系 ”，以获取有关其他微服务的信息，这些微服务将被注册为客户端可用的路由。此外，它充当负载均衡器（通过功能区），以及请求的过滤器和代理（通过Hystrix）。此外，与所有/一些微服务的请求，读取时间或套接字相关的超时可通过方便的Hystrix参数进行配置。
配置服务器：它包含可能来自不同来源的所有微服务的配置。在Docker容器之外，它通常使用文件系统或Git作为事实来源。但是，在容器内部，使用它的JAR 类路径，前瞻性更改其他微服务的引用及其逻辑名称（通过docker-compose.yml指定）。显然，当您拥有配置服务器的“ 集群 ”时，不建议使用后一种方法。PS：在后一种情况下，蓝绿色图案可能会在更换配置时帮助您。
服务发现/注册服务器：上面广泛提到，它允许发现和注册微服务。Feign特别有用，您可以通过该工具使用包含所有录音的寄存器来请求其他微服务。
微服务1：示例微服务，仅包含受所有非管理员用户保护的Hello World端点，通过向AAP提交请求（通过Feign）来检索用户和角色。

此体系结构可以是您的个人或业务项目的具体基础。

原文 https://www.jdon.com/51712

正文到此结束