想象一个只有几百名用户的小生意:一台服务器、一个数据库,服务100个用户绰绰有余。突然需求暴涨,活跃用户从100人涨到10万人,系统开始崩溃,请求失败,客户不满,这门唯一的生意眼看就要垮掉。
![]()
问题出在哪?为什么偏偏是用户数从100涨到10万的时候,故障集中爆发?
根因并不神秘。原来的简单架构在100用户时够用,所有用户都能被顺利处理。可当活跃用户数上升,涌入系统的请求量随之激增,服务器很难再给出任何响应。说白了,这套系统在用户数增加时不具备扩展能力。
解决办法是扩容,路径有两条:垂直扩展与水平扩展。
垂直扩展:给现有机器加料
架构评审会上,团队先抛出几个问题:为什么不能给现有服务器更多算力?为什么不能加更多计算资源——升级硬件、增加CPU、塞满内存?这就是垂直扩展。
它的好处很直接:核心架构没动,不需要改代码;操作简单,省时间。
但讨论没有停在这里。资深工程师继续追问:加了算力服务器还是挂了怎么办?这是单点故障。资源一直加下去,能加多少?总有上限。而且,是不是太贵了?
这几个问题让会议室安静下来,直到有人提出另一个方案。
水平扩展:用一群小服务器分担
与其用一台强大笨重的服务器,不如用几台小服务器,在前面放一个负载均衡器,把请求分发到不同服务器上。这就是水平扩展。
它的优势包括:没有单点故障;一台服务器挂了,另一台还能处理请求;按需增加服务器,扩展性相当好。
不过会议室里并非人人都买账。资深工程师很快指出这种分布式做法带来的新麻烦:是不是得同时在所有服务器上部署、管理和更新代码?搭建是不是很复杂?多台服务器同时读写,是不是很容易出现数据同步问题?
最终怎么选
现代硬件的性能强得惊人。仅靠垂直扩展——买一台顶级机器——就足以扛过10万用户的冲击。事实上,一些非常成功的平台主要就是靠高度优化的垂直扩展来承载巨大流量。
但水平扩展提供了难以替代的高可用性:它消除了可怕的单点故障,也为用户规模冲到100万的那天做好准备,代价是立刻要背上配置负载均衡器、部署流水线和复杂数据库同步的负担。
工程师该走哪条路?系统设计里很少有唯一正确答案。决定取决于企业的预算、工程人力和长期规划。有的团队选择升级服务器,省下宝贵的工程时间;有的团队接受分布式系统的复杂度,换取稳定运行时间。
系统就是这样演进的:从简单的基础架构起步,在必要时扩容,让系统保持可靠,让客户保持满意。
如果真走水平扩展这条路,怎么管理这些流量而不造成大规模拥堵?那就要看负载均衡器了。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.