我们目前正在开发一款应用程序，它将 IoT 数据存储在数据库中（像平均值一样处理......）并通过 Rest API 使其可用。当然，我们的第一个任务是构建一个应用程序（很好的旧式整体应用程序），该应用程序将获取数据（主要通过 MQTT 端点）并使它们可用于其余 API。
我们正在考虑微服务（我猜我们的用例适合它），但是，我们还没有准备好。我们是两个正在尝试构建应用程序的开发人员，我认为，一旦我们的整体架构不再高效，我们就可以考虑这个问题...我们已经开发了一些使用它的项目，并且我们理解这个概念，但有是一些我们显然还没有的 DevOps 技能，而且我们不是 Netflix、Google...
我的一位同事告诉我拆分应用程序：
MQTT 端点将把遥测数据发送到事件总线，数据处理器将获取它并继续处理（计算平均值，存储它......）
但这听起来像是一个分布式整体应用程序，据我所知，管理起来有点糟糕（库中的共享数据库模型，一切基本上都与一切相关）。
我仍然认为简单的单体应用程序足以启动（我们可以运行该应用程序的多个副本），微服务可以随后出现，并且上述分布式单体应用程序是......原始......
我知道这个问题可能是“基于意见”，但我们更多地寻找一种可以解决我们技术问题的模式。
开发一个整体架构实际上是可以的（甚至是一个分布式整体架构：这个术语的贬义意义实际上描述了这样一种情况：人们认为他们正在开发微服务，但最终他们将它们耦合得如此之深，以至于他们得到了两者的许多最糟糕的方面单体和微服务风格的架构）如果还没有出现微服务的需求；可以说，除非您拥有足够大的开发团队来进行协调和一致性，否则您实际上并不需要微服务，延迟*会极大地影响您交付价值的能力。 尽管早期的技术选择可能会让自己陷入困境，而微服务听起来像是出路，但实际上并没有“永远”强有力的技术理由来进行微服务。 可以设计一个整体开发和部署的系统，它实际上是一个微服务架构。 如果这样做，您将需要严格执行模块化，并且跨越模块边界会强加异步边界。 如果这样做，这些模块就很容易拉出到独立开发和部署的微服务中，只需对所需的粘合代码进行少量更改。 如果模块通过 MQTT 相互通信，而不是共享本地状态或共享数据库，甚至可能不需要任何更改。 Actor 模型（如 Erlang、Akka、Akka.Net、Thespian 中所示）可能有助于强制执行（免责声明：我的雇主为其中一个项目维护和销售支持/咨询服务）模块化和异步性，同时位置透明允许“相同操作系统进程”情况使用比 MQTT 更快的本地消息传输。
*：冈瑟的通用可扩展性定律既适用于构建系统的（人类）系统，也适用于正在构建的系统（当然，构建系统的人类系统也在不断构建自身...... )