0

例如，

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

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

4

2 回答 2

1

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

避免点对点集成，让一切都通过几个共同点——理想情况下是一个。使用 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）的坚定支持。
  • 谁想要报告，为什么 - 他们试图解决什么问题？
于 2021-07-21T02:12:25.140 回答
1

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

于 2021-07-21T11:56:47.093 回答