云服务器负载均衡SLB实战入门
当你的网站访问量上来之后，单台云服务器迟早会扛不住。这时候要么升级更高配置，要么加机器做集群。多台机器协同工作就需要一个负载均衡器，把用户请求分发到不同后端服务器上。这篇文章聊聊云服务器的负载均衡（SLB）怎么入门用。
为什么需要负载均衡
单台服务器有两个瓶颈：性能上限和单点故障。性能到顶了，再加钱也提升有限；机器万一挂了，整个网站就打不开。
负载均衡的思路是：前面放一个统一入口，后面挂多台后端服务器。用户请求先到 SLB，由它按规则转发给某一台后端。这样既分担了压力，又有了冗余——一台挂了，其他机器还能接着服务。
SLB 是怎么工作的
云厂商的负载均衡是个托管服务，你不用自己装软件。在控制台里创建一个 SLB 实例，绑定一个公网 IP，然后把你的后端 ECS 加进去，设置监听端口和转发规则就行。
它支持常见的轮询、最少连接、会话保持等算法。刚开始用选轮询就够了，简单稳定。等你对业务有了解之后，再调更细的策略。
后端服务器怎么准备
要挂到 SLB 后面的几台服务器，环境必须保持一致：同样的程序版本、同样的代码、同样的配置。否则用户被分发到不同机器上，体验会不一致。
数据库不要放在后端服务器本地，要单独用 RDS 或者独立数据库，这样几台后端都连同一个数据库，数据才不会乱。文件上传也同理，要存到对象存储或者共享文件系统。
健康检查很重要
SLB 会自动做健康检查，定时向后端服务器发探测请求。如果某台机器连续几次没响应，SLB 会自动把它从转发列表里剔除，等它恢复了再加回来。
这个机制让你可以安心地逐台维护机器：把某台从 SLB 里摘下来，重启升级，完了再加回去，用户几乎无感。
成本和适用场景
负载均衡本身是要收费的，外加流量费。小站点一天没多少访问量，完全不需要上 SLB，单台机器加个 CDN 就够了。
等你真的遇到单台扛不住、或者对可用性要求高的时候，再上 SLB 也不迟。它是个扩容工具，不是建站标配，不要过早优化。
什么时候暂时不要上SLB
如果你现在只有一台服务器，访问量也不大，那真没必要急着上负载均衡。多一层网络跳转、多一份费用，却换不来多少实际收益。
正确的节奏是：单台机器先撑着，等它真的到瓶颈了再扩容。扩容的时候再考虑加机器、上 SLB。过早做分布式，维护成本会远超性能收益。
