问事件驱动架构是否应该针对所有数据和分析平台？

EN

这是一个非常开放的问题，但你可以采纳一些好的原则来帮助你朝着正确的方向前进：

避免了点对点集成()，并通过几个公共点(理想情况下是一个)实现了所有的东西。使用API网关可能是一个很好的起点，大公司(Azure、AWS、GCP)都有自己的选择，还有很多不错的独立公司，比如Tyk或Kong。

批处理和事件流是完全不同的，但是即使这样，您仍然可以通过网关路由它们，从而获得集中化的可观察性(报告、分析、警报等)。

在可能的情况下使用基于标准的规范.基于适当资源模型的好的基于REST的API是一项重要的工作，如果您正在处理大量不同的遗留集成，则不确定它是否适合您所做的工作。如果您打算采用REST，请使用OpenAPI来指定API。使用该标准不仅使消费者更容易使用，而且还帮助您获得更好的工具，因为许多设计、构建和测试工具都支持OpenAPI。还有用于事件/异步API的AsyncAPI

做了一些架构。将sh*t移到云上并不会删除sh*t --它只是将它移动到云端。不要在新的地方重现旧的问题。

• 计算出新解决方案中的逻辑组件:每个组件都做什么(存在的原因是什么)？不要忘记API目录等辅助组件。
• 考虑对集成进行分层(通常取决于它们的使用方式和它们需要扮演的角色，例如系统接口、业务流程、体验API等等)。
• 想要以一致的方式处理数据，而不考虑源(“不可知论者”的评论)？您需要考虑一下数据是如何被摄取和处理的。这可能会导致更多的以数据/ ETL为中心的考虑，而不是集成。

协同设计。是集成的主要数据输入还是输出？是与第三方的整合还是严格的内部整合？

如果您是为外部/第三方用户设计的，那么建议您进行协同设计，因为您实际上是在为他们设计API。

如果API是内部使用的，请考虑将它们设计为外部使用，这样当/如果以后决定这样做，就不会那么难了。

后退一步：

• 不断地问自己：“我们想要解决什么问题？”通常，如果有一个被充分理解的理由，一个技术创办者是成功的，因为它从业务(非it )中获得了坚实的收购力。
• 谁想要报道，为什么-他们想要解决什么问题？

正如您所提到的，它是一个IT产业，也就是企业级解决方案，包括批处理和实时解决方案，因此首先您必须确定这种迁移的最终目标是什么。您可以考虑重构应用程序。如果您试图使其成为事件驱动，那么评估重构的努力和成本。责任分离是重构和迁移的关键因素。如果您正在考虑将来验证您的解决方案，那么请考虑云来存储和处理您的数据。没有必要，这将是廉价的，但混合云和上机可能是一种方式。云提供商提供的服务可以以最低的成本移动数据。云本机解决方案用于对数据执行分析。AWS或Azure中的数据库迁移服务可以移动数据，然后捕获正在进行的更改。因此，您可以继续使用on db &app，并对云进行报告分析。它将减轻事务性DB上的负载。大多数数据从on同步到云几乎是实时的.