比方说，facebook作为一个二进制运行。在N台服务器上发布这个服务的N个副本，把工作负载平均分配，很好。现在，如果我把facebook的代码库一分为二，到底怎样才更有扩展性呢？(从这个y轴的尺度意义上讲，是这样的 文章).
如果我给前半部分分配1台服务器，后半部分分配2台服务器，肯定会比一台单片服务器快，因为现在我们有3台。这就像 十轴 缩放。只不过现在你的负载均衡不均衡。
但是考虑到服务器的规模是原来的25%。从启动开始，这些服务器就有较高比例的使用内存。之所以如此，是因为将代码一分为二并不意味着RAM占用率减半。每台服务器都会在重复的库代码等方面浪费更多的RAM。
我想知道从这个性能计算资源的角度来看，使用微服务是否有任何好处。
微服务架构允许开发者通过从小型服务的组合中构建应用，创建应用的独立组件...
现在... 如果我们有一个单体应用，并确定一个特定的功能比其他功能有更多的traficrequest，那么我们需要扩展所有的应用，包括应用中trafic较低或为零的部分，如果这部分应用崩溃，那么所有的应用都会崩溃！在微服务架构中，每一个小的应用都有一个小的服务。在微服务架构中，每一个小的功能都可以部署成一个小的微服务，在这种情况下，我们可以只扩展我们需要的那部分系统，即使这个服务崩溃了，所有其他的系统部分仍然活着...... 这个方案向我们展示了两个好处：隔离和可扩展性。
当你考虑RAM消耗时，你需要考虑上面的方案，因为我们可以只在需要的时候才产生一个服务，如果我们不需要，我们可以减少到较少的实例数量，在这里我们可以获得性能计算效率资源角度的收益......。从存储的角度来看，还是要考虑到占用空间的问题，一个单片机应用可能会对一组特定的功能使用一些类库，而另一组功能可能会使用其他的类库......这里的问题仍然存在! 在单片机应用中，我们有很多不需要扩展的类库和资源被扩展。
如果我们在一个应用程序的生命周期中思考，开发新的功能可以实现开发或更新小的服务，所以，与微服务架构相关的功能是容易理解的能力，当与整个单体应用程序相比。微服务方法可以让开发人员为正确的任务选择正确的工具。他们可以利用自己需要的语言或框架来构建每个服务器，而不会影响其他微服务之间的通信。 这种方案更向我们展示了两个好处。生产力和灵活性。