事件中心不允许将消息存储超过 7 天(可能最多 30 天(。具有这些限制的 Azure 建议的 PaaS 事件溯源体系结构是什么？如果是事件中心 + 快照，如果我们以某种方式需要重新生成该状态，会发生什么情况？此外，事件中心是否回答 KSQL/Spark Azure 流分析？
好问题！
是的，事件中心旨在用于Event Sourcing或Append-only log模式。EventHubs可以用作SPARK等流处理和分析引擎的源/接收器，因此不是其竞争对手。一般来说，EventHubs提供的功能与Apache Kafka类似。
是的，从仅追加日志Snapshotting实现重建事务绝对是推荐的方法！
在将EventHubs塑造为产品时，我们为retentionPeriod分配默认值的考虑因素是 -
- 大多数关键系统每隔几分钟就会创建快照。
- 围绕此的大多数设计模式都建议保留较旧的快照以进行重建
所以，很明显，我们不需要无限的日志，对于大多数用例来说，一天的时间限制就可以了。因此，我们从默认的 1 天开始 - 并给出一个旋钮直到 7 天。
如果您认为，您将遇到一个案例，您必须及时返回>7 天来重建快照(例如：用于调试 - 这通常不是 99% 的场景 - 但同意设计和适应这是非常明智的(，推荐的方法是将数据推送到存档存储。
当我们usage Metrics显示许多客户都有一个专用于将数据推送到存档存储的EventHubs consumer group时，我们希望启用此功能现成，然后开始提供 - 事件中心捕获功能。
详细了解事件中心。
事件中心应该用于临时存储事件，同时在数据存储实例之间移动事件。您必须将它们加载到某个永久存储中才能无限期使用，例如 Cosmos DB。
KSQL在某种程度上与Azure Stream Analytics相当。Spark 是一个更广泛的产品，但你可以使用 Spark 来处理事件中心数据。
附言我不是Microsoft的官方发言人，所以这只是我的观点。
在许多情况下，使用事件溯源模式时，Cosmos DB 是比事件中心更好的事件存储。 原因是 Cosmos DB 不会自动删除数据。使用事件中心，可以使用捕获功能将较旧的数据复制到 Azure Blob 存储，但是，在访问较旧的事件时，需要能够从事件中心和 Blob 存储读取事件，这使得实现更加复杂。
与 Cosmos DB 相比，可以将事件与分区键和时间戳一起存储。然后，可以轻松筛选事件或使用 Cosmos DB 更改源来获取通知。
但是，同样对于 Cosmos DB，如果经常需要事件的完整重播，并且这变得昂贵或需要很长时间，则将事件转储到 Blob 存储可能很有用。尽管对于具有合理事件数量的域，使用数据库作为唯一的存储似乎是最好的。