大家好，欢迎来到停止重构的频道 。本期，我们讨论一个问题， 这也是很多人的误区。
一台服务器性能不足 ，集群扩展就可以了吗？
当然不是，至少，扩展服务器并不是说得这么轻巧的。
如果真的这么简单的话，那么就不会有这么多系统扛不住压力崩溃， 也就不会存在造价几千万几亿的网站系统了。
我们按这样的顺序讨论几个问题：
微服务真的无限扩展性能吗 ？
所有服务都使用集群的话是否可以无限扩展性能 ？
无限扩展性能的难点在哪？
微服务真的无限扩展性能吗
微服务可以无限扩展可能很多人都听说过。
以SpringCloud为例： 新启动的服务自动连接到注册中心就可以分流压力了， 理论上一台后端服务器性能不足，扩展一台就可以了。
但是在实际项目中， 这却是起不到性能扩展作用的。
在前面《性能调优的基本思路》里说过 ，网站系统就像是一个水管网络 ，只有各个部分吞吐量都均衡了才是合理的。
所以只是后端服务扩展的话，网站系统的整体性能是不会有所提高的。
而且由于在线用户上来了，session量也会增加 ，如果存储共享session的redis服务没有配置好淘汰机制的话，那么扩展再多的后端服务 ，网站系统都会崩溃 。
所有服务都是用集群的话是否可以无限扩展性能？
那么，所有服务都使用集群的话是否可以无限扩展性能呢？
Redis、RabbitMQ都有集群模式 ，MySQL的话可以分片存储集群化， 也可以使用MongoDB等分布式数据库，这样网站系统的每个部分都可以扩展了。
理论上是这样的，但是实际上却并不是，集群化后，网站系统的关系会变得更加复杂 ，而且集群服务器也并不一定会分摊压力。
例如，每个集群服务器只负责一部分的数据。
理论上会分摊所有数据的操作压力，但是如果压力集中在其中一部分数据呢 ？例如限时抢购等场景， 则其实压力仍然会集中在一台服务器上。
即使是多台服务器同时负责一部分数据的集群方案，也会由于数据同步等机制，以至于集群的性能可能没有想象中高。
当然，数据服务的集群化性能如何，需要根据具体数据服务的实现方式而定。
所以，集群的性能并不是1+1等于2的关系。一些极端情况下， 加上带宽等问题 、性能，甚至是1+1<1的， 测试过你就知道了 。
无限扩展性能的难点在哪
无限扩展性能的难点在于，数据服务集群的扩展，虽然能加大数据存储的量， 但是性能并不一定是增长的。
这也是大型网站的真正难点，所以需要设计很多机制规避性能问题。如缓存、异步写入、服务分区等机制。
这些经验是区别团队技术能力的关键，也是几万块钱与造价几千万的网站系统的本质区别。
这也就是往期《性能调优基本思路》中强调的编程方案 ，比较通用的一些方案会在后续内容分享 。
总结
感谢看到这里的朋友，在本期内容的结束，我们还想说明一下。
为什么停止重构的内容都偏向于一些更加专业的问题，而不是去讨论工具使用或编程技巧上呢？
这里想引用一位前辈的话：
工程师做的是给用户带来便利或需要的东西
所以应该对用户负责
这种负责
不应该体现在某个沾沾自喜的技巧上
而是应该体现在用户看不见的专业问题上