假设 facebook 作为单个二进制文件运行。在 N 个服务器中发布此服务的 N 个副本，可以平均分配工作量。现在，如果我将 facebook 代码库分成两半，它究竟如何更具可扩展性？ （在这个article的y轴刻度上）。
如果我为前半部分分配 1 个服务器，为后半部分分配 2 个服务器，它肯定会比一个单片服务器更快，因为现在我们有 3 个。这与 x-axis 缩放完全一样。只是现在您的负载平衡不均匀。
但考虑到服务器是其原始大小的 25%。从一开始，这些服务器就拥有更高百分比的已用 RAM。之所以如此，是因为将代码分成两半并不意味着将 RAM 占用空间减半。每个服务器都会在重复的库代码等上浪费更多的内存。
我想知道从性能/计算资源的角度来看，使用微服务是否有任何好处。
【问题讨论】：
微服务架构允许开发人员通过从小服务组合构建应用程序来创建应用程序的单独组件...
现在...如果我们有一个单体应用程序，并确定一个特定功能接收的流量/请求比其他功能多，那么我们需要扩展所有应用程序，包括流量较低或为零的应用程序部分，如果这部分应用程序崩溃，而不是所有应用程序崩溃！在微服务架构中，每个小功能都可以部署为一个小微服务，在这种情况下，我们只能扩展我们需要的系统部分，即使这个服务崩溃，系统的所有其他部分仍然存在......这个场景向我们展示了两个好处：隔离和可扩展性。
当您考虑 RAM 消耗时，您需要考虑上面的场景，因为我们可以只在需要时生成服务，如果不需要，我们可以减少实例数量，在这里我们可以在性能/计算效率资源方面获得收益......从存储方面来看，仍然占用空间很小，一个单体应用程序可能使用一些库来处理一组特定的特性，而另一组特性可能使用其他库......问题依然存在！哎呀，我们在一个单体应用程序中调用了很多我们不需要扩展的操作系统库和资源。
如果我们在应用程序的生命周期中考虑，开发新功能可以通过开发或更新小型服务来实现，因此，与整个单体应用程序相比，与微服务架构相关的功能是一种易于理解的能力。微服务方法让开发人员可以为正确的任务选择正确的工具。他们可以使用他们需要的语言或框架来构建每个服务器，而不会影响其他微服务之间的通信。这个场景向我们展示了更多的两个好处：生产力和灵活性。
【讨论】：