首页- 百度SEO资源- 如何保证大型网站的高可用性(2)

如何保证大型网站的高可用性(2)

发布时间:2020-08-18 14:00:00

在上一篇文章中,我们讨论了如何在大型网站的开发中确保高可用性。在网站运维实践中,除了网络、服务器等硬件故障导致的系统可用性风险外,软件系统本身也存在风险。

特别是当我们的网站在网上发布的时候,项目需要打包再发布是不可避免的。在这段时间内,由于网站的可用性,服务器处于停机状态。设计一个高可用性的网站,如果我们的网站更新迭代速度很快,每周更新两次或一次,那么系统的可用性就会更频繁地不可用。

下面我们将分享一些不同于传统软件开发过程的确保可用性的不同方法

事实上,网站发布过程的影响与服务器宕机的影响相似,对系统可用性的影响也类似于服务器宕机。因此,在设计一个网站的高可用性架构时,服务器中断的概率不应该是物理上的一年或两次,而应该是每周两次。也许你不认为这很重要,重启非常快,用户一年可以忍受一两次宕机,所以他们不需要复杂的高可用性设计。事实上,由于应用程序的不断发布,用户每周需要面对一两次停机。

但毕竟网站发布是一台预言的服务器机器,所以过程可以比较温和,对用户的影响较小。发布脚本通常用于完成发布,其过程如图所示

代码在发布到在线服务器之前需要经过严格的测试。即使每一个新功能都是在原有系统功能的基础上小幅增加,为了保证系统不引入意外的bug,网站测试还需要对整个网站功能进行全面的回归测试。此外,还需要测试各种浏览器的兼容性。在频繁发布的网站应用中,如果使用人工测试,其成本、时间和测试覆盖率都难以接受。

目前,大多数网站采用web自动化测试技术,使用自动测试工具或脚本来完成测试。大型网站通常开发自己的自动化测试工具,可以完成系统部署、测试数据生成、测试执行、测试报告生成等整个测试过程。

即使经过严格的测试,软件部署到在线服务器后,仍然存在各种问题,甚至根本无法启动服务器。主要原因是测试环境与在线环境不一样,尤其是应用程序需要依赖的其他服务,如数据库、缓存、公共业务服务,以及一些第三方服务,如电信短信网关、银行网银接口等。

可能是数据库表结构不一致,接口更改导致通信失败,配置错误导致连接失败,或者依赖的在线服务环境没有准备好,都可能导致应用程序失败。因此,网站发布时,通过测试的代码包不会直接发布到在线服务器,而是首先发布到预发布机器上。开发工程师和测试工程师在预发布服务器上进行预发布验证,执行一些典型的业务流程,在正式发布前确认系统没有问题。

预发布服务器和在线正式服务器(应用服务器1、2、3)都部署在同一物理环境中(同一数据中心甚至同一机架,如果使用虚拟机,它甚至可能在同一物理服务器上),使用相同的在线配置并依赖相同的外部服务。网站工程师通过在开发计算机上配置主机文件,绑定域名IP关系,直接使用IP地址,可以直接访问预发布服务器。如果在预发布服务器上执行的测试验证是正确的,则基本上可以确保在线部署正式服务器时没有问题。

代码控制主要控制在我们的开发部门。如果对主干进行打包和发布,则可能会在分支中产生问题。开发完成后,可以将分支同步到主干。这不会影响已发布系统在开发过程中的可用性。

网站版本发布频繁,整个发布过程需要多个团队的配合。在发布之前,多个代码分支合并回主干可能会导致冲突,发布前验证也会带来风险。每次释放都相当于一次停机事故。

应用程序成功发布后,仍然可以找到由软件问题引起的故障。此时需要做一次发布回滚,即卸载刚刚发布的软件,并重新分发上一版本的软件包,以恢复系统并消除故障。

大型网站的主业务服务器集群规模很大,比如大型应用集群服务器超过10000台。一旦发现故障,即使想发布回滚,也需要很长时间才能完成,但只能眼睁睁地看着失败时间的增加,却又心急如焚。为了应对这种情况,大型网站会采用灰色发布模式,将集群服务器分成若干部分。每天只发布一部分服务器。观察稳定运行后,不会出现故障。第二天,一些服务器将陆续发布。整个集群将出版数天。如果在此期间发现问题,则只需要回滚已发布的服务器的一部分

Copyright © 2015-2020. 未经许可,不可拷贝或镜像 pasun.cn