大家好，欢迎来到停止重构的频道。
本期，我们讨论大型网站的伸缩性。
伸缩性指的是通过自动增减服务器数量以适应用户量或压力。
这些年，微服务、ServerLess、K8S等技术，都让人有一种服务器自动伸缩很容易实现的错觉。
其实，想要实现服务器完全自动伸缩是一件十分困难的事情。
我们按这样的顺序讨论：
1、自动伸缩服务器的难点在哪
2、数据服务软件为什么扩展服务器非常困难
3、如何处理数据服务软件扩展困难的问题
自动伸缩服务器的难点在哪
在前面《部署架构》里说过，一个网站系统是由4部分组成的，分别是前端部分、后端部分、数据部分、云计算部分。
前端部分由于可以接入CDN 所以基本不会出现性能问题。
后端部分采用微服务且解决好共享session的话，服务器扩展也是十分简单的。
云计算部分的话，如果采用一些分布式框架，如我们研发的Hive框架，云计算服务器扩展也是十分简单的。
但是数据部分的扩展确实是一件特别麻烦的事情，数据部分包含MySQL等数据库、Redis等非关系型数据库、RabbitMQ等消息队列等等。
所以网站系统伸缩服务器的难点在于数据服务软件上。
数据服务软件为什么扩展服务器非常困难
当然，数据服务软件一般都有集群方案，感兴趣的小伙伴可以翻看之前介绍。
那为什么说数据服务软件的扩展特别困难呢？不是都有集群方案吗，加一台服务器到集群应该不麻烦吧。
数据服务软件的集群方案一般有2种 ：
一种是所有服务器镜像存储数据，数据库主从读写分离也是这种模式。
每次更新数据时需要做多服务器的数据同步。
如果需要新增一台服务器的话，新服务器需要同步所有数据，而同步数据是需要时间的，数据量大的话所需时间会特别长（十分不现实）。
另一种是分片存储，集群中的每个服务器只负责处理一部分数据，这是MySQL等关系型数据库常见的集群模式。
这种集群方式虽然说扩展服务器不需要同步数据，但是新扩展的服务器其实并不能缓解压力，因为数据压力仍然集中在旧服务器上。
除了以上的问题，还有请求均衡的问题，一般需要额外增加中间件实现请求均衡。
另外，一些数据服务软件集群只能手动添加服务器（需要手工配置重启）。
所以数据服务软件的服务器扩展特别麻烦，而且扩展服务器也不一定能提升性能。
如何处理数据服务软件扩展困难的问题
那如何处理数据服务软件扩展困难的问题呢？
一般是预先扩展，我们的做法是让数据服务软件都拥有目标性能的两倍，当突发情况发生时，就可以通过快速扩展后端服务实现2倍性能扩展。
如果是有大型活动，则提前扩展好数据服务软件的服务器。
另外，一个网站系统最好不要采用单数据软件实例的做法，最好根据业务模块分离多数据软件实例。
这样，一开始压力不大时可以多实例部署在一台服务器上，压力上来了，可以立马分离服务器并实现集群。
但是，正如前面性能那一期所言，数据服务软件的性能是有极限的，不可能通过增加服务器以扩展无限性能。
所以，终究还是需要跳出 “扩展服务器就能扩展性能的误区”。
在性能要求特别高时，需要考虑编程方案以突破性能瓶颈。
比如，对于点击量观看量这些频繁更新的数据，可以先在Redis中增加，然后再定期写入数据库。
对于大量统计信息，可以先放到KafKa，然后再慢慢处理。
对于一些修改概率特别低的数据，可以考虑静态化，这样就可以利用CDN缓解性能压力。
总结
网站系统的伸缩性，虽然理论上是可以做到自适应用户量的，但是现实其实很难做到，至少现在还比较困难。
最后，作为工程师，我们不要过分依赖某个软件或框架，比这更重要的是清楚软件系统的核心问题，并根据实际情况调整解决方案。