以 Firebase 为中心的架构

Firebase centered architecture

这是一个架构问题。

我目前正在设计一个 Web 应用程序,我已经习惯了基本的:前端、api、数据库、微服务设置。

为了省钱并使我的架构比我习惯的更现代一点,我决定研究无服务器。

我感兴趣的两个主要部分是google云函数和firebase。我的理解是 google 可以在 firebase 中的数据库条目被操作时触发云函数。

我以前在服务之间进行通信的方式是通过 RabbitMQ 等消息队列,但在我看来,通过使用 firebase 和云函数,您可以通过数据库建立通信,而无需消息队列。在这种情况下,我所说的通信的意思是,一项服务能够通过看到数据库中的条目已更改来对另一项服务的执行做出反应。

因此,我的问题是,让微服务之间的所有“通信”运行 通过 firebase 而不是消息队列有什么好处和坏处,这是一种普遍使用的架构吗?

AFAIK,云函数触发器是 Firebase 中的测试版功能,根据 doc,firestore 触发器事件有一些限制:

  • It can take up to 10 seconds for a function to respond to changes in Cloud Firestore.
  • Ordering is not guaranteed. Rapid changes can trigger function invocations in an unexpected order.
  • Events are delivered at least once, but a single event may result in multiple function invocations. Avoid depending on exactly-once mechanics, and write idempotent functions.
  • Cloud Firestore triggers for Cloud Functions is available only for Cloud Firestore in Native mode. It is not available for Cloud Firestore in Datastore mode.

这里最令人担忧的限制是第一个。如果您需要更新对用户可见,则 10 秒的更新时间很长。

我看到的另一个缺点是,随着复杂性的增加,它可能 运行 失去控制(在系统设计方面)。您可能很想为所有内容添加事件,并且可能很难按类别对它们进行分区,例如(在消息队列中,您可以为此使用主题)。

此外,根据 doc,云函数的速率限制为每 100 秒调用 16 次,如果您的应用程序有一些流量,可能会很快达到。

我会在孤立的场景中使用触发事件,并在微服务之间的 backbone 通信中使用消息队列。