大家好，欢迎来到停止重构的频道。

本期讨论大型网站的可用性。

高可用指的是当一部分服务器宕机时，网站系统仍可正常运行。

一些常用的软件服务的高可用部署方案 ，如Tomcat、Nginx、Redis、MySQL等，在往期性能调优时已经有详细的介绍，这里不做讨论。

这里讨论一个问题，是否全部软件服务都做了高可用部署，就能保证网站系统的可用性呢？

当然不是，这只是保证网站系统可用性的其中一项，除了软件服务都采用高可用部署方案，还需要考虑以下几点：

1、  服务器定期维护巡检 

2、  服务器监控 

3、  应用、数据备份 

4、  完善的日志机制 

5、  环境分离与灰度发布

服务器定期维护巡检

首先是服务器定期维护巡检，长时间运行的网站系统出现问题不一定在开发的软件上，也可能在服务器的硬件、操作系统上。

定期对服务器进行维护巡检能防止一些由于长时间运行产生的奇怪问题，如内存错误、内存泄漏、磁盘读写错误等。

维护巡检一般是服务器重启、漏洞修复、基础软件升级、日志清理、磁盘容量健康检查等。

维护巡检的周期一般是3个月，但也要视操作系统、网站系统实际压力而定。

 

服务器定期维护巡检一般是被忽略的，但这却是十分重要的。

定期维护巡检就好像是定期身体检查，很多问题可以预先解决，而非问题发生时再病急乱投医。

服务器监控

接下来是服务器监控，一般监控的是服务器的CPU、内存、带宽使用率、磁盘容量、某个程序是否意外退出等。

当出现问题时，可以自动通知运维人员及时处理。如果使用公有云或私有云的话，服务器监控、异常通知一般都是完备的。

如果是使用物理机搭建的环境，可以安装实时监控系统，一般称为APM 如SkyWalking等。

 

服务器监控除了能让运维人员及时处理问题，还有一个好处。

就是可以通过监控记录，知道网站系统的峰值压力时段，这数据无论对运营还是对系统维护都是有帮助的。

应用、数据备份

接下来是应用、数据备份，人不能保证一生无病无痛，那服务器也是有可能坏掉的。

所以，应用、数据都需要定期做备份，如定期做系统快照、磁盘备份等。

一旦服务器出现问题，可以通过系统快照、数据备份快速恢复。

 

一些系统会考虑灾备，灾备本质上还是应用、数据备份，只不过是异地备份。

防止当原来服务器所在地区发生不可抗力后，异地备份的系统能立马接替工作。

完善的日志机制

软件是很难做到毫无BUG的，有些问题很玄学地只能在生产环境出现，有些问题发生概率很低，很难复现。

如果有日志的话，则能快速定位问题，而不是花大量时间复现问题，然后在程序中打断点排查。

当然，完善的日志不一定是件麻烦的事情，其实网站系统的日志不需要关注所有部分，只需要重点关注后端部分的日志即可，其他软件服务的日志一般正常记录即可。

对于后端日志详细的介绍可以参考往期《后端规整化》。

当然，这样记录的日志量是比较大的，很多人会担心性能问题，不过日志记录的库一般都支持异步写入磁盘，所以在实际项目中其实并不会造成多大的性能问题。

另外，不要一开始就着眼于ELK等日志收集方案，应该先定好日志规则，不然收集再多的日志也没有用。

顺便一提，在性能测试时，不要关闭日志，虽然这样有可能会提升性能测试的结果，但这样做其实并没有什么实际意义。

另外，日志除了能快速定位问题，还有一个好处。

就是在运营过程中，会有一些咨询或投诉 ，比如充值了金币没到账，则日志可以作为断定是系统BUG还是用户人品问题的依据。

环境分离与灰度发布

网站系统的发布更新成本是相对较低的，所以更新频率是相对较高的。

系统更新频率高是系统不稳定的一大因素，系统不稳定的话会让用户有一种山寨感。

最好的做法是有明确的版本迭代计划，先发布到测试环境经过完整测试后，再发布到生产环境，且在版本测试过程期间不随便追加功能。

当然，这样也很难保证新功能不会对旧功能产生影响，所以一些网站系统会考虑灰度发布。

灰度发布的实际做法根据具体业务场景、系统规模会有十分大的区别，但目的都是一样的，就是新功能只让部分地区或特定用户使用，当功能稳定后，再逐步扩展到全部用户群体。

 

当然，这些发布流程都会加大发布的成本，所以我们一般只推荐对比较大的版本进行完整的测试流程和实施灰度发布。

总结​​

以上提到的点，都是一些运维、流程上的问题，技术上的要求相对会少一些。但是这些正是系统可用性高、稳定的关键 而且对实际项目而言，这些比各种集群、高可用部署方案都重要。

这其实也说明一个道理 ：一个软件系统最终的长久运行，长年维护升级，并不是因为其技术有多高深或不可思议，而是完善的规则和过程造就的。