微服务架构-全球数据共享
在所有情况下，重要的是，如果允许用户Y访问该公司，微服务本身仍然必须检查是否允许用户Y对该公司进行某种操作。因此，此用户到公司的匹配仅用于确保用户对公司有访问权限。
我并不是真的很喜欢这些方法，因为将消息放入队列（1）意味着每个服务都必须被告知一个更改。使用Zuul验证（2）也不是真正实用的，因为它应该只是一个网关。
共有1个答案
在我看来，全球数据是不存在的。所有的数据都被本地化到一个给定的服务，它是它的拥有者，其他人可以通过调用获取这些数据。在其他微服务中复制这些数据可能会导致不一致的状态。
对于这个用例，为什么不尝试授权路由。当用户登录您的系统时，您授权他访问某个公司。一个或多个。这个信息可以在令牌中传递，每个关心公司id的服务都可以拿起它并处理它，因为令牌的生存时间有限，一旦userX从公司中删除UserY，后续的令牌就不会有company_id并且将被忽略。
这里，您的逻辑是在Auth服务中，而其他人只是在头中查找这些信息。如果您不喜欢auth service的想法，可以添加一个服务，该服务一次性将公司头添加到所有传入请求中。（这与API网关做这件事不同，因为API网关还有其他职责）。
-
我不清楚如何取回购买服务不保存的数据--例如：用户的全名。当试图通过购买用户名进行更复杂的搜索购买时，问题会变得更严重。 我认为，显然可以通过在两个服务之间同步用户来解决这个问题，方法是在用户创建时广播某种类型的事件（并在购买服务端只保存相关的用户属性）。在我看来，这远非理想。当你有数百万用户时，你如何处理这个问题？您会在每个使用用户数据的服务中创建数百万条记录吗？ 另一个明显的选择是在用户服务端
-
我的微服务架构中有几项服务。 其中两个服务（服务A、服务B）有不同的api，并提供不同的域逻辑。然而，它们确实共享一些应该从Redis返回的逻辑-用户状态。 当用户状态更改时，我正在从第三个服务发布到我的所有微服务 解决方案： > 我可以创建另一个服务，负责“用户状态”并将保存Redis上的所有用户数据。缺点：我的客户端将对每个api请求进行额外调用（以获取用户状态）。 为每个微服务复制用户状态数
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr
-
TL；DR服务应该选择将偶尔需要的数据保存在其本地数据库中，还是每次都从数据来源的服务请求数据？ 让我们举一些Web商店/订购应用程序的通用示例。服务A是一种用户会话管理服务。它处理用户正在做什么、他可以做什么等的业务逻辑。用户可以创建自己的衬衫以供购买。服务B是一个数据聚合器，包含大量库存和可用内容。 用户开始创建衬衫，因此service a请求service B提供可用的样式/颜色。服务B向下
-
让我们讨论一下微服务环境的体系结构。我们正在公司内部进行讨论，我想得到一些反馈。我认真考虑的是编排层（代码复制、更多移动部件改变api）。 网络应用- 原料药- 在这种情况下，服务不允许相互对话。业务流程层中的聚合服务 网络应用- 原料药- 这里允许服务相互对话，这里存在聚合服务。 账单属于哪里
-
我正在设计一个微服务架构中的评审分析平台。 应用程序如下所示； null null 问题在于，验证服务需要获取site-a的所有评论，应用验证规则并生成错误（如果有的话）。我知道共享数据库模式和实体打破了微服务体系结构。 一个可能的解决方案是 每当验证服务需要对站点进行审查时，它就会请求网关，网关会将请求重定向到审查服务并采取响应。 这种方法的两个可能缺点是 验证服务是否知道网关？是否会带来依赖？