我们目前正在开发一款应用程序，该应用程序将物联网数据存储在数据库中(像平均值一样处理……(，并通过Rest API提供。当然，我们的第一步是构建一个应用程序(好的旧单片(，该应用程序将获得数据(主要通过MQTT端点(，并使其与其他API一起可用。
我们正在考虑微服务(我想我们的用例会适合它(，但是，我们还没有准备好。我们是两个试图构建应用程序的开发人员，我认为，一旦我们的整体架构不再高效，我们就可以考虑这一点。。。我们已经参与了一些使用它的项目，我们理解这个概念，但有一些DevOps技能我们显然还没有，我们不是Netflix、谷歌。。。
我的一位同事告诉我拆分应用程序：
- 一个用于MQTT端点(身份验证设备(
- 一个用于Rest API(用于ex的登录用户和管理设备(
- 一个用于处理数据(计算平均值等(
MQTT端点将把遥测发送到事件总线，数据处理器将获取遥测并进行处理(计算平均值，存储…(
但它听起来像是一个分布式的单片应用程序，据我所知，管理起来有点糟糕(库中的共享数据库模型，一切基本上都与一切相关(。
我仍然认为简单的monolith应用程序已经足够启动了(我们可以运行该应用程序的多个副本(，微服务可以在之后出现，上面描述的分布式monolith是…原始的。。。
我知道这个问题可能是"；基于意见"；，但我们更多的是在寻找一种可以解决我们技术问题的模式。
如果微服务的需求还没有出现，那么开发一个单体(甚至是分布式单体：这个词的贬义确实描述了这样一种情况，即人们认为他们正在开发微服务，但他们最终将它们耦合得如此之深，以至于他们得到了单体和微服务风格架构中许多最糟糕的方面(实际上是可以的；可以说，在你有一个足够大的开发团队来进行协调和一致性之前，你并不真正需要微服务。延迟会极大地影响你交付价值的能力。尽管通过早期的技术选择，微服务听起来像是一条出路，但做微服务并没有真正的技术理由。
设计一个整体开发和部署的系统是可能的，它实际上是一个微服务架构。如果这样做，您将需要严格执行模块化，并且跨越模块边界会强加异步边界。如果这样做的话，只需对粘合代码进行少量更改，模块就可以很容易地扩展到独立开发和部署的微服务中。如果模块之间通过MQTT通信，而不是共享本地状态或共享DB，则可能甚至不需要任何更改。行动者模型(如Erlang、Akka、Akka.Net、Thespian中所述(可能有助于强制执行(免责声明：我的雇主为其中一个项目维护和销售支持/咨询服务(模块化和异步性；相同的OS进程"；使用比MQTT更快的本地消息传输的情况。
*：Gunther的通用可伸缩性定律适用于构建系统的(人类(系统，也适用于正在构建的系统(当然，构建系统的人类系统也在构建自己…(