构建应用程序和反模式（分布式单体......）

Question

我们目前正在开发一个应用程序，它将物联网数据存储在数据库中（像处理平均值等一样处理它），并通过 Rest API 使其可用。 我们的第一个当然是构建一个应用程序（良好的旧单体），它将获取数据（主要通过 MQTT 端点）并通过 rest API 使它们可用。

我们正在考虑微服务（我猜我们的用例会适合它），但是，我们还没有准备好。 我们是两个试图构建应用程序的开发人员，我认为，一旦我们的单体架构不再有效，我们就可以考虑这样做......我们已经在一些使用它的项目上工作过，我们理解这个概念，但是是一些我们显然还没有的 DevOps 技能，而且我们不是 Netflix、Google……

我的一位同事告诉我拆分应用程序：

• 一个用于 MQTT 端点（身份验证设备）
• Rest API 一个（登录用户和管理设备前）
• 一个用于处理数据（计算平均值等......）

MQTT 端点会将遥测数据发送到事件总线，数据处理器将获取它并继续它（计算平均值，存储它......）

但这听起来像是一个分布式的单体应用程序，据我所知，管理起来有点糟糕（在一个库中共享 db model，一切基本上都与一切有关）。

我仍然认为简单的单体应用程序足以启动（我们可以运行该应用程序的多个副本），微服务可以随后出现，并且上述分布式单体应用程序是......原始......

我知道这个问题可能是“基于意见的”，但我们更多的是寻找一种可以解决我们技术问题的模式。

Answer 1

开发单体架构实际上是可以的（即使是分布式单体架构：该术语的贬义实际上描述了人们认为他们正在开发微服务但最终将它们耦合得如此之深以至于他们得到了两个单体架构的许多最糟糕方面的情况和微服务风格的架构），如果没有出现做微服务的需求； 可以说，在您拥有足够大的开发团队进行协调之前，您实际上并不需要微服务，而一致性延迟*会极大地影响您交付价值的能力。 做微服务并没有真正的技术上的理由，尽管通过早期的技术选择将自己描绘成一个角落，微服务听起来像是出路。

可以设计一个整体开发和部署的系统，它实际上是一个微服务架构。 如果这样做，您将需要严格执行模块化，并且跨越模块边界会施加异步边界。 如果这样做，这些模块很容易被拉出到独立开发和部署的微服务中，只需对粘合代码进行少量更改。 如果模块通过 MQTT 相互通信，而不是共享本地 state 或共享数据库，甚至可能不需要任何更改。 The actor model (as found in, eg Erlang, Akka, Akka.Net, Thespian) may be helpful in enforcing that (disclaimer: My employer maintains and sells support/consulting services for one of those projects) modularity and asynchronicity while location-transparency允许“相同操作系统进程”的情况使用比 MQTT 更快的本地消息传输。

*：冈瑟的通用可扩展性定律适用于构建系统的（人类）系统，就像它适用于正在构建的系统一样（当然，构建系统的人类系统也在构建自身......）