Design patterns 微服务间的数据共享

当前架构：

问题：

我们在前端和后端层之间有两步流程

• 第一步： 前端在microservice 1（MS1）上验证来自用户的输入
• 第二步： 前端向微服务2提交I1和更多信息

微服务2（MS2）需要验证来自前端的I1的完整性。如何避免对MS1进行新的查询？最好的方法是什么

我试图优化的流程删除步骤1.3和2.3

流程1：

• 1.1用户X向MS2请求数据（MS2_数据）
• 1.2用户X在MS1上保存数据（MS2_数据+MS1_数据）
• 1.3 MS1使用B2B HTTP请求检查MS2_数据的完整性
• 1.4 MS1使用MS2_数据和MS1_数据持久化数据库1并构建HTTP响应

流程2：

• 2.1用户X已将数据（MS2_数据）存储在本地/会话存储器中
• 2.2用户X在MS1上保存数据（MS2_数据+MS1_数据）
• 2.3 MS1使用B2B HTTP请求检查MS2_数据的完整性
• 2.4 MS1使用MS2_数据和MS1_数据持久化数据库1并构建HTTP响应

方法

一种可能的方法是在MS2和MS1之间使用B2B HTTP请求，但我们将在第一步重复验证。 另一种方法是将数据从MS1复制到MS2。然而，由于数据量及其波动性，这是禁止的。复制似乎不是一个可行的选择

我认为更合适的解决方案是，前端有责任在微服务2上获取微服务1所需的所有信息，并将其交付给微服务2。这将避免所有这些B2B HTTP请求

问题在于微服务1如何信任前端发送的信息。也许使用对来自微服务1和微服务2的数据进行签名可以验证消息。

注意 每当微服务2需要来自微服务1的信息时，执行B2B http请求。（HTTP请求使用和）。如何避免这种情况

架构目标

微服务1需要微服务2随需应变的数据，以便能够在MS1数据库上持久化MS1_数据和MS2_数据，因此使用代理的异步方法在此不适用。

我的问题是，是否存在一种设计模式、最佳实践或框架来支持这种推力通信

当前体系结构的缺点是每个微服务之间执行的B2B HTTP请求的数量。即使我使用缓存控制机制，每个微服务的响应时间也会受到影响。每个微服务的响应时间至关重要。这里的目标是归档一个更好的性能，以及一些如何使用前端作为网关跨多个微服务分发数据的方法，但使用的是推力通信

---

MS2_数据只是一个实体SID，如产品SID或供应商SID，MS1必须使用它来维护数据完整性

可能的解决方案

其思想是将网关用作api网关请求处理，缓存来自MS1和MS2的一些HTTP响应，并将它们用作对MS2 SDK和MS1 SDK的响应。这样，MS1和MS2之间就不会直接进行通信（同步或异步），也可以避免数据重复

当然，上述解决方案仅适用于跨微服务的共享UUID/GUID。对于完整数据，事件总线用于以异步方式（事件源模式）跨微服务分发事件和数据

灵感：和

相关问题和文档：

---

如果不查看“盒子内部”，很难判断任何解决方案的可行性，但是：

• 如果您在这里唯一关心的是阻止前端对数据进行潜在的篡改，那么您可以为MS2发送到前端的数据包创建一种“签名”，并将签名与数据包一起传播到MS1。签名可以是数据包的散列，该数据包与从微服务共享的种子以确定性方式生成的伪随机数相连（因此，MS1可以在不需要额外B2B HTTP请求的情况下重新创建与MS2相同的伪随机数，然后验证数据包的完整性）

• 我想到的第一个想法是验证数据的所有权是否可以修改。如果MS1必须经常访问来自MS2的数据子集，则可以将该子集的所有权从MS2移动到MS1

• 在理想情况下，微服务应该是完全独立的，每个微服务都有自己的持久层和一个复制系统。您说代理不是可行的解决方案，那么共享数据层呢

---

希望有帮助

从问题和评论中，我了解到您正试图重新排列块以提高系统性能。如图所述，您建议网关查询MicroService 2，而不是MicroService 1查询MicroService 2，然后再查询MicroService 1，向其提供MicroService 2中的信息

因此，我看不出这将如何显著提高系统性能，但这种变化似乎只是改变了逻辑

为了纠正这种情况，应提高关键微服务2的性能。这可以通过分析和优化微服务2来实现