异步消息传递系统的消息验证
我正在寻找最佳方法，即如何在基于异步消息传递系统中启用消息验证消息。
设想： 假设我们有两个服务A和B，他们需要异步地相互互动。我们之间有一个队列，可以说SQ将收到A的消息，然后由Service B对此进行轮询
B。 我如何验证该消息（例如执行架构验证），因为它已被验证为SQS，因为当前SQS没有任何内置的模式验证功能，就像我们对JMS的
几个选项一样，我可以想到：
- 拥有一个验证层，也许是一个小型服务层， A和SQS队列，但不确定这将如何
- 使用某种妈妈，例如A和SQS队列之间的AWS EventBridge，因为它具有验证模式的功能，并且可以充当存储所有模式的中心
- 位置B中的端点将进行验证并使SQ坐在B后面，但随后删除了异步通信b/w a和b
将感谢上述询问的任何输入，以及如何通过最佳实践解决。
I'm looking for the best approach as to how I can go about doing validation of a message as its enqueued in async messaging based systems.
Scenario:
Let's say we have a two services A and B where they need to interact with each other asynchronously. And we have a queue between them lets say SQS which will receive the message from A, which will be then polled by service B.
Ask:
How can I validate the message like doing schema validation as its enqueued to SQS since currently SQS doesnt have any in-built schema validation functionality like we have for JMS
Couple of options I can think of:
- Have a validation layer maybe a small service sitting between A and SQS queue but not sure how feasible this will be
- Use some sort of MOM like AWS Eventbridge between A and SQS queue as it has functionalities to validate schemas as well as it could act as a central location to store all the schemas
- Have a rest endpoint in B that'll do the validation and have SQS sitting behind B but then this removes the async communication b/w A and B
Would appreciate any inputs on the above ask and how it could be resolved via best practices.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您阅读有关事件驱动的体系结构样式的中介拓扑。从您共享的详细信息中，对我来说，将“调解器服务”放置为
m，它将从a中获取消息，进行所需的验证和然后，将消息发送到sqs到b- 将实现所需的目标。I'd recommend to read about the Mediator Topology of Event-Driven architecture style. From the details that you shared, it sounds to me that putting a "Mediator Service" called
Mfor example, which will get messages fromA, make the required validations, and then will send the message toSQSon its way toB- will achieve what you want.消息有效载荷的验证可能会在“中”或“出路”或“出路”上发生，具体取决于您的用例和扩展需求。大多数方案将旨在防止无效的数据变得太远，即您将在将数据放入SQS之前验证。
但是，您可以选择在从队列中阅读时验证消息有效负载的原因。例如，您可能有许多添加消息的服务，随着时间的流逝，这些消息可能具有多个“有效载荷版本”，不同的团队可能是构建服务（前端和后端）等。不要假设所有内容，每个人都一致。
假设SQS中的有效负载数据已验证，并且可以由下游消费者处理而不检查的情况可能会导致很多问题和/或破坏方案。 总是在这些情况下检查您的数据。根据我的经验，这是为什么发生破裂变化的原因的第一原因，要么是接近它。
最后几点：使用事件驱动的体系结构，设计决策点不仅涉及处理/计算软件服务，还涉及事件数据有效载荷本身，也必须正确设计。
Validation of the message payloads can occur on the "way in" or the "way out" depending on your use case and scaling needs. Most scenarios will aim to prevent invalid data getting too far downstream i.e. you will validate before putting data into SQS.
However, there are reasons you may choose to validate the message payload while reading from the queue. For example, you may have many services adding messages, those messages may have multiple "payload versions" over time, different teams could be building services (frontend and backend) etc. Don't assume everything and everyone is consistent.
Assuming that the payload data in SQS is validated and can be processed by a downstream consumer without checking could cause lots of problems and/or breaking scenarios. Always check your data in these scenarios. In my experience it's either the number one reason, or close to it, for why breaking changes occur.
Final point: with event-driven architectures the design decision points are not just about the processing/compute software services but also about the event data payloads themselves which also have to be designed properly.