我自己开发系统时，应该使用微服务吗？

我正在开始一个新的项目，尽管可能需要一个或两个其他开发人员将现有的应用程序或简单的脚本集成到主项目中，但我几乎将是该项目的唯一开发人员。该项目需要处理小规模的批量和流数据的摄取/处理，以及事件驱动和按需代码执行。框架的某些部分受CPU限制，而某些部分则受I / O限制。大多数数据必须存在于单个计算机上，但是我们能够创建集群并连接虚拟机以增加可用的计算能力。可能会有一个或多个小型Web应用程序依赖于此核心框架提供的服务。主要语言将是适用于几乎所有内容的Python。

我的问题是，考虑到我将自己完成大部分开发工作，我是否应该采用微服务方法来进行此类工作或坚持使用单一应用程序。我的想法是，微服务（使用Nameko）在具有不同执行模型（数据管道，事件启动，按需，Web应用程序等）的框架元素之间提供了自然的分隔，并提供了一种清晰的方式来分配工作负载和跨多个流程的沟通。我担心的是，我可能最终会使用一个Kubernetes集群来管理（我熟悉Docker，但对于Kubernetes来说还很陌生），为了促进系统运行，需要多个服务（rabbitmq，redis等），并可能有很多小的代码块来实际实现我们所需要的所有必要功能

对于只有一个开发人员的项目，微服务是否仍会简化这样的复杂系统的开发和维护？我是否应该考虑使用其他方法/系统/框架，或者减少以这种方式设计系统所涉及的开销？

微服务通常是不可取的，因为它们将您的软件变成了分布式系统-分布式系统使一切变得更加困难。但是面向服务的体系结构具有一些重要的好处：

• 不同的团队可以独立开发和部署不同的服务
• 不同的服务可以独立扩展

因为您将是唯一的开发人员，所以您不需要灵活地独立开发服务。

但是您注意到某些部分可能受CPU限制。因此，可能需要独立于应用程序的其余部分来扩展它们。如果是这样的话，这并不意味着您必须将整个项目变成一个微服务架构。您只需要将该CPU密集型部分移至其自己的服务中，即可将其余部分保留在方便的整体中。很难区分应该沿着哪条线划分系统，但是总的来说，DDD的“有限上下文”概念是一个很好的指导原则。

请注意，整体结构还不错。巨石并不等于一个庞大的，难以维护的项目。您可以将系统拆分为不同的微服务，也可以将系统拆分为整体中的不同组件。在面向服务的体系结构中，这些组件之间的分离更加明显，并且更加清晰地实现了。这也意味着对于一个设计良好的系统，在以后的某个时刻将组件变成服务应该相当容易。因此，您现在不必决定，如果整体证明自己不合适，那么您可以转向微服务。

还要考虑一下马丁·福勒（Martin Fowler ）的“微服务高级版”（Microservice Premium，2015）的概念：微服务除了引入系统的基本复杂性之外，还引入了自身的大量复杂性。您必须为降低生产力支付“溢价”。这意味着对于简单的项目，微服务会使您的生产力降低。对于更复杂的项目，这会发生变化：虽然单片解决方案可能变得越来越难以使用，但微服务体系结构的伸缩性要好得多，并且需要大致不变的努力。您必须知道，对于您的软件系统，微服务的额外初始投入是否值得。由于您是在问这个问题，答案可能是“否”。福勒继续：

因此，除非您的系统过于复杂而无法作为一个整体进行管理，否则我的主要指导原则是甚至不考虑微服务。大多数软件系统应构建为单个整体应用程序。请务必注意该整体中的良好模块化，但不要尝试将其分离为单独的服务。