当我们的程序只部署一套，不再能满足访问量（调用量）的时候，最简单的横向扩容的方法就是部署多套应用环境，负载均衡将用户（客户端）的访问平均地分配到每台服务器上，这样就可以利用多台机器的资源，增加系统的负载能力。
那么要做负载均衡，对我们的系统有什么要求么？或者说我们的代码需要做什么改造么？
大部分时候我们的代码是不需要改造的，但是也要注意这么几点。
我们的服务最好是无状态的，也就是每一次的调用，不依赖于前一次的调用结果，如果前后有依赖，则需要后面的请求携带着前一次请求的结果，作为参数进行访问。
除非负载均衡开启了会话保持，或者通过一些负载均衡路由策略，让同一个 IP 的请求始终路由到同一台服务器上，但是这并不是一个好的解决方案。
通常我们需要保持服务的无状态性，如果需要做权限认证的话，建议采用 Token 或使用 Redis 做 Session 共享（推荐使用 Token）。
还有一点，可能不一定必须的，不过我觉得也是个不错的方案，供大家参考。
假如我们有两台应用服务器 A 和 B，前面挂一台负载均衡，当我们需要做应用升级的话，通常可以怎么做？
通常的办法是停掉服务器 A，这时候负载均衡会监控到这台服务器 A 已经无法使用了（比如监控到端口消失），再来的请求会发送给服务器 B；
对服务器 A 升级并启动，负载均衡监控到 A 恢复了，会将请求发送给 A 和 B；
对服务器 B 做相同的操作。
这样看似没有问题，因为在服务器升级的时候，负载均衡不在发送请求到这台服务器上；但是大家仔细想一想这个过程，如果在停服务器的那一刻，已经有请求进来了并进行处理，但是还没有返回，这时候停掉服务器，会导致这部分请求发生异常，那么这个问题如何解决呢？这就需要对程序进行一定的改造了。
应用提供一个接口，返回一个静态变量的值，只要 true 或 false 两个状态；
负载均衡不再监控端口是否消失，而是监控剪口返回的状态，返回 true 表示应用正常，false 或没有返回表示不正常；
每次停服务之前，通过接口修改当前应用静态变量的值为 false；
负载均衡认为该服务器状态不正常，将不再发送请求到这台服务器上；
等待几十秒，这段时间相当于等待当前请求都处理并返回，再停止服务。
“停止服务时，不再接受新的请求，等现有请求都处理完成后再真正停止服务”，这只是一个笨办法，想要避免以上问题还有更好的办法，并且对代码没有侵入性；有些中间件本身提供了类似的功能，我们只需执行对应的停止服务的命令即可；或者需要在代码中添加监听类，当收到 kill 信号的时候，拒绝新的请求，等待一段时间，再结束程序等等。
评论0
加载中...
1.确保你的接口无状态，鉴权可以使用token，redis集中化session
2.确保你的接口幂等性，可以为接口生成请求id，过滤请求id，防重，或者可以使用一次性token。
3.确保你的接口集群对等，代码，数据，都需要对等，通常每台机器数据源都是一样的，代码是相同的。同时机器的配置也是相同的。
评论0
加载中...
代码中不能把数据、上传文件、日志等保存到本地。
评论0
加载中...
大家好，我是IT屠工，很高兴回答此问题，希望我的回答可以帮助到你！
什么是负载均衡
负载均衡主要通过专门的硬件设备或者通过软件算法实现。通过硬件设备实现的负载均衡效果好、效率高、 性能稳定，但是成本比较高。通过软件实现的负载均衡主要依赖于均衡算法的选择和程序的健壮性。均衡 算法也是多种多样的，常见的有两大类：即静态负载均衡算法和动态负载均衡算法。静态算法实现比较简 单，在一般网络环境下也能达到比较好的效果，主要有一般轮询算法、基于比率的加权轮询算法以及基于 优先级的加权轮询算法等。动态负载均衡算法在较为复杂的网络环境中适应性更强，效果更好，主要有基 于任务量的最少连接优先算法、基于性能的最快响应优先算法、预测算法及动态性能分配算法等。
网络负载均衡技术的大致原理是利用一定的分配策略将网络负载平衡地分摊到网络集群的各个操作单元 上，使得单个重负载任务能够分担到多个单元上并行处理，或者使得大量并发访问或数据 流量分担到多个 单元上分别处理，从而减少用户的等待响应时间。
Nginx 服务器负载均衡配置
Nginx 服务器实现了静态的基于优先级的加权轮询算法，主要使用的配置是 proxy_pass 指令和 upstream 指令，这些内容实际上很容易理解，关键点在于 Nginx 服务器的配置灵活多样，如何在配置负载均衡的同 时合理地整合其他功能，形成一套可以满足实际需求的配置方案。
下面的有一些基础示例片段，当然不可能将所有的配置情况包括在内，希望能够起到抛砖引玉的效果，同 时也需要大家在实际应用过程中多总结多积累。在配置中需要注意的地方将以注释的形式添加。
配置实例：
在以下实例片段中，backend 服务器组中所有服务器的优先级全部配置为默认的 weight=1，这样它 们会按照一般轮询策略依次接收请求任务。该配置是一个最简单的实现 Nginx 服务器负载均衡的配置。所 有访问 www.myweb.name 的请求都会在 backend 服务器组中实现负载均衡。实例代码如下：
...
upstream backend #配置后端服务器组
{
server 192.168.1.2:80;
server 192.168.1.3:80;
server 192.168.1.4:80; #默认 weight=1
}
server
{
listen 80;
server_name www.myweb.name;
index index.html index.htm;
location / {
proxy_pass http://backend;
prox_set_header Host $host;
}
...
}
由于 Nginx 服务器的 功能在结构上是增量式的，因此 ，我们可以在这些配置的基础上继续添加更多功能，比如 Web 缓存等功 能，以及 Gzip 压缩技术、身份认证、权限管理等。同时在使用 upstream 指令配置服务器组时，可以充 分发挥各个指令的功能，配置出满足需求、高效稳定、功能丰富的 Nginx 服务器。
欢迎大家关注并点赞，我是@IT屠工，专注IT网络技术资源分享，普及IT网络技术
评论0
加载中...
一般涉及到负载均衡，以下几种情况必须要注意：
这里所说的文件管理是指通过上传至服务器的文件，这就不能再单纯地存储至代码所在服务器上了，必须有专门的文件服务器。
单一服务器一般都是WEB服务器与数据库在一起。在负载均衡中，数据库最好做成读写分离。
代码需要对SESSION以及缓存做处理，保证能够正常访问这些共享的数据，建议引入R edis。
日志也应与文件管理一样，有专门的服务器进行管理。
评论0
加载中...
建议用户授权不要用session。可以采用token方式。将用户信息加密到token中，每次请求将token通过header post给服务器，然后再去解密。这样负载均衡就没任何问题了。
评论0
加载中...6
回答8
回答0
回答2
回答0
回答6
回答0
回答0
回答2
回答10
回答
