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

【问题标题】：Should event driven architecture be targeted for all data & analytics platforms?事件驱动架构是否应该针对所有数据和分析平台？
【发布时间】：2021-07-20 10:54:48
【问题描述】：

例如，

您有一个 IT 资产，其中混合了来自多个系统的批处理和实时数据源，例如ERP、项目管理、资产、网站、监控等。
目的是将数据源集成到云环境中（不可知）。
需要对所有数据源的组合进行报告和分析。
不可避免地，某些源系统无法进行流式传输，因此需要批量加载。
根据提取的数据执行功能/更改/更新的潜在用例。

考虑到创建面向未来的平台的指导，在架构上，您会如何设计它？

【问题讨论】：

标签： events architecture cloud analytics eda

【解决方案1】：

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

避免点对点集成，让一切都通过几个共同点——最好是一个。使用 API 网关可能是一个不错的起点，大玩家（Azure、AWS、GCP）都有自己的选择，此外还有很多像 Tyk 或 Kong 这样的独立的不错的选择。

批次和事件流完全不同，但即便如此，您仍然可以通过网关将它们全部路由，以便获得集中的可观察性（报告、分析、警报等）。

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

做一些架构。 将 sh*t 移至云端并不会移除 sh*t - 它只是将其移至云端。不要在新地方重现旧问题。

找出新解决方案中的逻辑组件：每个组件的作用是什么（存在的理由是什么）？不要忘记 API 目录等辅助组件。
考虑分层集成（通常取决于它们的使用方式以及它们需要扮演的角色，例如系统接口、编排、体验 API 等）。
想要以一致的方式处理数据而不考虑来源（您的“不可知论”评论）？您需要考虑如何摄取和处理数据。这可能会导致您考虑更多以数据/ETL 为中心的考虑，而不是集成考虑。

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

如果您正在为外部/第 3 方消费者进行设计，那么建议您采用协同设计流程，因为您实际上是在为他们设计 API。

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

退后一步：

不断问自己“我们要解决什么问题？”。通常，如果有充分理解的理由进行技术启动，并且得到业务（非 IT）的坚定支持，则技术启动是成功的。
谁想要报告，为什么 - 他们试图解决什么问题？

【讨论】：

这是非常有用的建议。任何关于构建未来的cmets，例如。所有架构的最终目标是事件驱动，还是总是需要数据驱动？
我不确定事件与数据驱动的具体关系，但我知道您应该始终先了解问题，然后再匹配正确的解决方案。您可能听说过“对锤子来说，一切看起来都像钉子”这句话。就未来而言 - 你拥有的工具越多越好。固执己见地固守一个想法通常会以糟糕的结局告终。

【解决方案2】：

正如您提到的，它是一个 IT 资产，也就是批处理和实时的企业级解决方案组合，因此首先您必须确定此迁移的最终目标是什么。您可以考虑重构应用程序。如果您试图使其成为事件驱动的，那么请评估重构工作和成本。职责分离是重构和迁移的关键因素。如果您正在考虑在未来验证您的解决方案，那么请考虑使用云来存储和处理您的数据。没必要它会很便宜，但云和本地的混合可能是一种方式。云提供商提供的服务可以以最低的成本移动您的数据。云原生解决方案可用于对您的数据进行分析。 AWS 或 Azure 中的数据库迁移服务可以移动数据，然后捕获正在进行的更改。因此，您可以继续使用本地数据库和应用程序并执行分析以在云上报告。它将减轻您的事务数据库的负载。从本地到云端的大多数数据同步都是近乎实时的。

【讨论】：

所以同意云评论，我认为目的是将所有数据集成到云平台中，在可能/可行的情况下将应用程序迁移到云，然后摄取外部应用程序数据。您对事件驱动架构如何随着时间的推移而发展有何看法，例如无论数据频率和延迟如何，它都会是所有架构的最佳实践方法吗？
@InterestedDeveloper 事件驱动架构并不是一个新概念，之前（甚至现在）我们曾经使用 ESB、MQ、监听器等来执行一些异步操作，使用所有本地资源，现在它只是移动到云/容器并获得了花哨的名字。它会在这里呆很长时间。根据客户需求，我们可以决定是否需要事件驱动。是的，在设计解决方案时应考虑延迟、数据频率和许多其他因素，如 OLTP、OLAP、DWH 等。它总是混合搭配，如果实施不当，将会产生大量技术债务。