我目前的项目存在架构困境,即近乎实时地处理大量数据。因此,这是当前架构的示意图:
这是对我的想法的解释,这使我想到了那张照片:
当 API 网关接收到请求时,它会被放入流中(这是因为我的应用程序的性质——“即发即弃)”这就是我得出这个结论的方式。输入数据根据特定请求在分片中分离属性保证我正确的顺序。
然后我有一个 lambda,它负责验证输入和异常检测。因此,它是一种抽象,可以为下一层(数据丰富)保持数据清洁。所以这个 lambda 将数据发送到 kinesis firehose,因为它可以备份“原始”数据(我绝对想要拥有的东西)并附加一个转换 lambda 来进行丰富 - 所以我不在乎保存数据在 S3 中,它将开箱即用。所以一切都很好,直到我需要保留接收数据的顺序(丰富器正在进行会话化),这在 firehose 中丢失了,因为那里没有数据分离,因为它在 kinesis 流中。
所以我唯一能想到的就是 - 在第一个 lambda 中移动 sissionization,这将打破我的抽象,因为它会开始关心数据丰富,而更大的缺点是备份数据将包含丰富的数据,这也在打破架构。而这一切之所以发生,是因为消防软管中缺少分片概念。
那么有人能在不丢失 aws 为我们提供的开箱即用功能的情况下想出解决该问题的方法吗?