分布式高可用架构.pptxVIP

分布式高可用架构 网站可用性的度量与考核 网站的页面能完整呈现在最终用户面前，需要经过很多个环节，任何一个环节出了问题，都可能会导致网站页面不可用。DNS会被劫持、CDN服务可能会挂掉、网站服务器可能会宕机、网络交换机可能会失效、硬盘会损坏、网卡会松掉、甚至机房会停电、空调会失灵、程序会有BUG、黑客会攻击、促销会引来大量访问、第三方合作伙伴的服务会不可用。。。。。。要保证一个网站永远完全可用几乎是一件不可能完成的使命。 业界通常用多少个9来衡量网站的可用性，如QQ的可用性是4个9，即QQ服务99.99%可用，这意味着QQ服务要保证其在所有运行时间中，只有0.01％的时间不可用，也就是一年中大约53分钟不可用。 网站年度可用性指标＝（1－网站不可用时间/年度总时间）×１００％ 网站不可用时间（故障时间）＝故障修复时间点－故障发现（报告）时间点 对可用性的定性描述，两个9是基本可用，年度停机时间小于88小时；3个9较高可用，年度停机时间小于9小时；4个9是具有自动恢复能力的高可用，年度停机时间小于53分钟；5个9是极高可用性，年度停机时间小于5分钟。由于可用性影响因素很多，对于网站整体而言，达到4个9，乃至5个9的可用性，除了过硬的技术、大量的设备资金投入和工程师的责任心，还要有个好运气。 CAP原理 在讨论高可用数据服务架构之前，先必须要讨论的一个话题是，为了保证数据的高可用，网站通常会牺牲另一个也很重要的指标：数据一致性。 数据备份 数据备份是一种古老而有效的数据保护手段，早期的数据备份手段主要是数据冷备，即定期将数据拷贝到某种存储介质（磁带，光盘。。。）上并物理存档保管，如果系统存储损坏，那么就从冷备的存储设备中恢复数据。 数据热备有可分为两种：同步热备方式和异步热备方式。 同步方式是指多份数据拷贝的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功； 异步方式是指多份数据拷贝的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，数据服务系统将会异步的写其他拷贝（这个过程有可能会失败）。 失效转移 数据服务器集群中任何一台服务器宕机的时候，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫做失效转移。 失效转移操作由三部分组成：失效确认、访问转移、重新备份恢复数据一致性。 失效确认 判断服务器宕机是系统进行失效转移的第一步，系统确认一台服务器是否宕机的手段有两种：心跳检测和应用程序访问失败报告。 访问转移 确认某台数据存储服务器宕机后，就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器（几台存储服务器存储的数据完全一样，这几台服务器叫对等服务器），当其中一台宕机后，应用程序根据配置直接切换到对等服务器上。如果存储是不对等的， 那么就需要重新计算路由，选择存储服务器。 重新备份恢复数据一致性 因为某台服务器宕机，所以数据存储的拷贝数目会减少，必须将拷贝的数目恢复系统设定的值，否则，再有服务器宕机，就可能会出现无法访问转移（所有拷贝的服务器都宕机了），数据永久丢失的情况。因此系统需要从健康的服务器拷贝数据，将数据拷贝数目恢复到设定值。 高可用网站的软件质量保证 在网站运维实践中，除了网络、服务器等硬件故障导致的系统可用性风险，还有另一个重要的方面，就是来自软件系统本身。 关于传统的软件测试和软件质量保证管理无需赘言，我们这里重点讨论网站为了保证线上系统的可用性而采取的一些与传统软件开发不同的质量保证手段。 网站发布 网站需要保证7×24高可用运行，同时网站又需要不断的发布新功能吸引用户以保证在激烈的市场竞争中获得成功。许多大型网站每周都需要发布一到两次，而中小型网站则更加频繁，一些处于快速发展期的网站甚至每天发布十几次。 不管发布的新功能是修改了一个按钮的布局还是增加一个核心交易功能，都需要在服务器上关闭原有的应用，然后重新部署启动新的应用，整个过程还要求不影响用户的使用。这相当于是要求给飞行中的飞机换个引擎，既不能让飞机有剧烈的晃动，也不能让飞机降落，更不能让飞机坠毁。 既然网站的发布过程事实上和服务器宕机效果相当，那么就可以用服务器宕机的高可用方案来应对网站的发布。所以设计一个网站的高可用架构的时候，需要考虑的服务器宕机概率不是物理上的每年一两次，而是事实上的每周一两次。也许你认为这个应用不重要，重启也非常快，用户可以忍受每年一到两次的宕机故障，因而不需要复杂的高可用设计。事实上，由于应用的不断发布，用户需要面对的是每周一到两次的宕机故障。用户哭了。 自动化测试 代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但是为了保证系统没有引入未预料的BUG