问题描述
例如
- 您有一个 IT 资产，其中存在来自多个系统的批处理和实时数据源的混合，例如ERP、项目管理、资产、网站、监控等
- 目的是将数据源集成到云环境中（不可知）。
- 需要对所有数据源的组合进行报告和分析。
- 不可避免地，某些源系统无法流式传输，因此需要批量加载。
- 根据摄取的数据执行功能/更改/更新的潜在用例。
在指导创建一个面向未来的平台的基础上，您会如何设计它？
解决方法
这是一个非常开放的问题，但您可以采用一些好的原则来帮助您朝着正确的方向前进：
避免点对点集成，让所有事情都经过几个共同点 - 最好是一个。使用 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）的大力支持，那么技术入门就是成功的。
- 谁想要报告，为什么 - 他们试图解决什么问题？
正如您提到的，它是一个 IT 资产，也就是批量和实时的企业级解决方案组合，因此首先您必须确定此次迁移的最终目标是什么。您可以考虑重构应用程序。如果您试图使其成为事件驱动，那么请评估重构工作和成本。职责分离是重构和迁移的关键因素。 如果您正在考虑让您的解决方案面向未来，那么请考虑使用云来存储和处理您的数据。没有必要它会很便宜，但云和本地的混合可能是一种方式。云提供商提供了一些服务，可以以最低的成本移动您的数据。云原生解决方案可用于对您的数据进行分析。 AWS 或 Azure 中的数据库迁移服务可以移动数据，然后捕获正在进行的更改。因此，您可以继续使用本地数据库和应用程序并执行分析以在云上报告。它将减轻您的事务数据库的负载。大多数数据从本地同步到云端几乎是实时的。