在微服务架构中，我有微服务，其中包含用户详细信息，但在zuul API gateway中，我想验证我的请求
微服务架构我有一个微服务（userservice：用户相关的微服务），但在Zuul API网关应用程序中，我想验证所有微服务的请求并使用Spring Security性。我必须在Zuul应用程序中创建登录和注册请求（AuthController），这需要数据源、userRepository zuul应用程序中的所有内容。
如果我对其他与用户相关的请求使用userservice（microservice user related），那么我必须使用相同的数据源，并为已经在zuul api网关应用程序中创建的相同数据源创建重复的bean和存储库？
共有1个答案
我觉得在网关级别验证用户名和密码不是一个好的设计。相反，您可以添加JWT令牌，它可以在zuul过滤器中验证请求本身。这可以是网关级别的一级验证。其次，可以在api级别实现缓存，这将显著提高后端安全api的吞吐量。
-
我读了一些文章，看了一些视频，但在为这些微服务提供服务方面，没有找到具体的建议。我的理解是，他们应该使用自己的应用程序服务器。 我的问题是它们应该部署在不同的服务器上，还是没关系。 当它们在同一台服务器（计算机）上提供服务时，不会有端口冲突吗？
-
我现在读了很多关于微服务的书，但仍然不了解其中的一些部分。我画了以下图： 每个微服务有2个访问： REST：对于超文本传输协议使用 gRPC：用于内部/后台通信/交换 如果我想登录，我可以向我的身份验证服务发送一个Http请求。但是，如果我想访问需要您连接的Stuff服务，该怎么办？ 假设用户希望显示数据库中可用的内容，服务人员将首先通过与身份验证服务交换来检查连接用户的“令牌”是否正确，然后返回
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr
-
假设有两个微服务:订单和库存。order service中有一个API，它接受< code>ProductId 、< code>Qty等并下订单。 理想情况下，只有在库存服务中存在库存时才允许下订单。人们建议使用Saga模式或任何其他分布式事务。这很好，最终将利用一致性。 但是如果有人想滥用这个系统。他可以使用无效或缺货的产品(< code>ProductId)推送订单。系统将接受所有这些订单，并
-
本文向大家介绍详解Java 微服务架构，包括了详解Java 微服务架构的使用技巧和注意事项，需要的朋友参考一下 一、传统的整体式架构 传统的整体式架构都是模块化的设计逻辑，如展示（Views）、应用程序逻辑（Controller）、业务逻辑（Service）和数据访问对象（Dao），程序在编写完成后被打包部署为一个具体的应用。如图所示： 系统的水平扩展 如果要对系统进行水平扩展，通常情况下，只需要
-
null null