集成模式: API与事件

Question

我需要设计一个集成5-6遗留CRM的CRM“平台”的架构。一个重要的功能是在一个仪表板中显示存储在其他CRM中的客户记录。实际记录被存储在他们自己的CRM中进行编辑。

一个问题是:我是否应该存储一组关于这些记录的最低限度的信息？解决办法可以是：

1. 调用每个CRM，组装BFF中的所有内容，并将结果服务于平台的CRM。
2. 另一种解决方案可以是将创建/更新事件从每个CRM发送到服务总线，将平台订阅到这些事件，并将最少的信息存储到平台CRM中，如externalID、客户名称、CRM类型。

每种解决方案的优缺点是什么？不仅从技术角度，而且从开发团队的角度？

我希望在平台CRM方面有更多的需求，但我们还不知道，所以它必须是可扩展的。例如，在集成平台中，可能有一个合并函数，其中用户将记录标记为等效的。或者某种适用于所有记录的工作流。

我现在没有强烈的看法，除了事件看起来更加解耦“，但更复杂的实现。

任何关于如何撰写分析报告的建议欢迎

Answer 1

我想这取决于你的最终目标。如果您只想要一种比较不同系统的方法，那么您只需简单地‘依次调用每个api’计划就可以了。

然而，如果试图替换遗留系统，或提供“统一的真相来源”或类似的东西，那么您自己的数据库可能是必须的，将事件推送给它比轮询更好。

即使简单地比较一下，你也可能需要一些额外的字段来连接不同的记录，也许你有一个“链接过程”，在这个过程中，计算机试图通过某种具体的东西来连接客户，比如一个国家的id，但不得不回到名称/道布，甚至可能是一个人的确认。您不会希望每次用户刷新时都运行该过程，并且必须将链接信息存储在某个地方。

Answer 2

事件更容易测试--对于纯函数来说，更容易推理--事件可能更难集成到现有体系结构中，这是因为遗留的决策预期会出现单块或微服务API交互

另一方面，API更易于部署，因为所有版本控制策略都能工作，事件体系结构依赖于在发布版本更改之前，即事件使用者必须能够处理以前的版本，并且同时准备在发布服务器更新时处理下一个版本，或者当新事件到达时，使用者将失败，而API可以为您的特定场景执行一长串部署选项。本质上，事件发布服务器在不对使用者进行同步更新的情况下发生变化，这意味着消费者无法按预期操作，除非生产者使用多个版本发送相同的事件，从而导致重复的数据处理。

事件架构的安全特性偏向于生产者，因为它无法处理任意请求，从而使攻击面和服务器负载最小化。另外，生产者可以使用JWT或HMAC保护消息的内容( webhooks和事件数据都是常见的)，因此发送/广播数据只能通过按住密钥以明文读取，从而使数据保护成为silve的PKI问题，而不是100 API数据保护问题。