时间戳

首页 > 解决方案 > 事件驱动架构是否应该针对所有数据和分析平台？

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

问题描述

例如，

给定一个创建面向未来的平台的指导，在架构上，您会如何设计它？

标签： eventsarchitecturecloudanalyticseda

解决方案

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

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

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

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

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

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

共同设计。 集成主要是数据进来还是出去？是与第三方集成还是严格内部集成？

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

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

退后一步：

  • 不断问自己“我们要解决什么问题？”。通常，如果有一个很好理解的理由，一个技术启动是成功的，它得到了业务（非 IT）的坚定支持。
  • 谁想要报告，为什么 - 他们试图解决什么问题？

推荐阅读