集群部署

一台物理机能够承载的请求是十分有限的，且一台物理机还存在单点故障的问题。

负载均衡

对外只暴露一个地址，对内通过反向代理将访问请求按照某种策略分发到相应的后端服务器上。比如使用 F5 等负载均衡设备映射到几台服务器上，或者使用 DNS 来实现广域网的路由。

负载均衡的策略算法：

• 随机选择 —— 随机选择一台后端服务器去处理请求。
• 轮询 —— 按顺序将请求发送给一台一台的后端服务器去处理请求。
• 最小连接 —— 检测和负载均衡器链接的服务器中连接数最小的一台机器。
• 最小资源占用 —— 检测服务器报告上来的 CPU 使用率等资源信息来分配机器。
• 指定哈希算法 —— 利用算法来分配机器。

哈希算法，又被称为散列算法，就是通过某种确定的键值函数，将源数据映射成为一个简短的新数据串，这个串叫做哈希值。如果两个源数据的 hash 值不同，那么它们一定不相同；如果两个源数据的 hash 值相同，那么这两个源数据可能相同，也可能不相同。

服务端 Session 和浏览器 Cookie

负载均衡的策略是适合无状态请求的，如何处理有状态请求呢？

服务端 Session（会话）：后端服务器在内存中存放一个临时对象，这个对象可以存放针对特定用户的具体信息。这个 session 需要主动（主动登出）或被动（超时）的销毁掉。
浏览器 Cookie：浏览器可以以文本的形式在本地存放少量的信息合并成一个字符串，通过这个字符串后端服务器就可以知道接口的用户信息、过期信息等。

HTTP 的三大坑

• 明文传输 —— 于是有了 HTTPS 加密传输。
• 客户端发起 —— 服务器推送技术。
• 无状态 —— 服务端的 Session 和浏览器的 Cookie。

集群部署

集群带来了无单点故障的好处，不会由于个别宕机而影响服务。但是，有了集群后，在部署上线时，应该按何种策略来做呢？

• 重建部署 —— 停止全部服务，部署新版本。可用性差。
• 滚动部署 —— 逐步部署新版本，替代旧版本。最常见。
• 蓝绿部署 —— 旧版本不听记得情况下，再开一组集群部署新版本。部署完成后切换流量到新版本上。需要两倍的服务器资源。
• 金丝雀部署 —— 新导入少量用户访问新版本，在验证无误后再逐步扩展到所有机器。效率低。
• A/B 部署 —— 导入特定用户到新版本代码。效率低。
• 影子部署 —— 新版本接收实际发往老版本的请求拷贝，并不影响老版本请求处理和响应本身。效率低。

滚动部署

一般的滚动部署，会以 1/2 或者 1/3 的机器数量逐步进行。

在滚动部署中，除了要考虑程序，还要考虑数据。特别是数据和版本的兼容问题。数据造成的问题会更大，单纯因为程序的问题还可以回滚，但如果数据有问题却是没有回滚机会的。

比如新版本增加表字段 A，然后滚动部署。结果用户存的数据时访问的新版本接口是有 A 的，然后用户在读取数据的时候访问的老版本接口。这时候就会报错。

解决方案：在设计的时候就需要考虑到数据与版本的兼容问题。

• 既要考虑新代码版本 + 老数据
• 也要考虑老版本代码 + 新数据

可以在版本 1 和 2 之间，先发一个兼容版本 1.5