扩展整体与扩展微服务

使用微服务的常见论点之一是更好的可伸缩性。但我想知道这种说法是否真的有效。

假设我们有一个包含10个微服务的应用程序，其中9个有两个实例（用于冗余），其中一个有4个实例来处理负载（可伸缩性）。赞成微服务的论点是，您可以独立于其他服务扩展此微服务。

但是，可以说所有10个微服务都是单个整体中的模块，并且已部署了该整体的几个（例如22个，类似于上面的总和）实例。该系统应该能够处理一个关键部分的负载，因为有足够的实例可以执行此操作。如果实例中不需要程序逻辑，唯一的缺点是二进制文件和所需的RAM数量会稍大。但话又说回来，在大多数情况下，差异应该不会太大-至少与堆栈的其余部分相比（与Spring Boot相比）应该没有。可缩放的monlith的优势将是没有（大部分）分布式系统的谬误的更简单的系统。

我想念什么吗？

微服务的重点不是减少处理器负载。实际上，由于通信和功能重复（以前是全局实用程序代码）的开销，通常会增加处理器的负载。

取消一个整体的观点是更要能维护，部署和运行的功能，一个复杂的系统在所有。一旦您的系统达到一定的大小，进行编译，测试，部署等工作，那么在保持适当的正常运行时间的情况下，整体组件将变得过于昂贵而无法实施。使用微服务，您可以逐步升级，重新启动或回滚系统。

没错，我们不编写微服务，因为它本质上是通过远程接口松散耦合事物的更好解决方案。实际上，整装件可能无法提供的强类型和一致性检查通常是一个主要缺点。我们之所以这样做，是因为我们必须这样做，因为复杂性已经变得更好，并且正在充分利用次优的情况。

您基本上是正确的。如果您有快速加载的服务，则最好将它们全部安装在所有包装盒上。它不像每个服务都有一个盒子那么“好”，但是确实节省了钱。

然而。一旦出现不平衡，例如服务5占用了100％的CPU 2分钟，您就希望将该服务移到其自己的盒子上，这样它就不会在运行时阻止所有其他服务。

如果由于加载导致对服务5的调用超时，则仅应用程序的某些功能将失败，而不是全部失败。

现在，您可以使用模块化程度良好的整体执行相同的操作。安装所有服务，但仅将服务5流量路由到其中之一。虽然未将服务5流量路由到其他设备。

但是，通常情况下，巨石本身并不是一个偶然的服务集合，它们恰好安装在同一盒子上。模块之间将存在内存调用，这将导致应用程序失败。

微服务的重点是1）关注点分离和2）分配负载。从本质上讲，这使我们可以腾出时间来使用特定于该任务的技术来提供最好的黑盒服务。我们的服务可以是多种语言-用不同的编程语言编写在不同的堆栈上。不同的团队可以在每个服务上工作，而无需了解其他服务如何超出其API的合同范围。总体上讲，这为每个服务提供了更简单的代码库，从而更易于调试，理解和调整性能。