设计高可用Web服务
浏览数：68 /
时间：2015年06月09日
高可用的设计可以说是web服务架构的目标，如果服务达不到高可用，万一出现故障将会对产品带来重大的负面影响。高可用的架构就是能够让服务在任何情况下都能正常响应，比如双十一的淘宝，面对激增的洪峰照样正常工作；而聚美三周年时服务器的宕机恰好是高可用的反例。
什么是高可用
- 可用性：在应用工作周期中可用时间的百分比
- 不可用：应用无法访问，服务中断应用访问非常缓慢
- 高可用：服务一直正常可用，快速响应
Tags
- SPoF：单点故障
- Failover：故障转移
- Disaster Recovery：灾难恢复
- Load Balancing：负载均衡
- …...
说到高可用，我们常常会提到上面这些标签，也是设计高可用服务需要考虑和解决的点。下面我们来看看如何设计一个高可用的架构，如何来解决上面的问题，实现高可用。
如何设计
在服务架构时，我们不能相信任何一个环节是100%没问题的，服务的每个层级，使用的数据库，缓存，甚至是服务器本身，服务器放置的机房这些硬件环节都不能完全相信。如果我们假设每个环节都有可能出现问题，在每个环节出现问题时都有方案应对，那么这样设计出来的服务一定就是高可用的了。上面这种考虑问题的方式我们称为“假定失效原则”，在设计服务架构时，我们就要坚持这一原则。
下面我以一个例子从浅入深的为大家讲解如何设计高可用服务：
在服务搭建初期，其实并不需要考虑太多，目标是将服务快速搭建，完成功能，验证产品；我们的架构可能是这样的：
但是，与高可用的标准相比，这样的设计最大最直接的问题显而易见。我们可以看到整个架构就只有一个web server和一个数据库，那么要是它们之中任意一个无法访问，整个服务就瘫痪了；这样的故障，我们称之为SPoF—单点故障。
单点故障可难不倒我们，采用分布式架构，web server放置在不同的数据中心，同时数据库做主备或者复制集；这样就解决了单点故障，此时的架构应该是这样的：
在这样的架构中，我们将用户的请求通过一个代理（只能做简单的分发）分发到处于不同数据中心的web server上解决了单点故障。可是另一个问题又来了，如果其中一个数据中心的web server无法访问，虽然另一个web server能够正常工作，但是仍然会有部分请求发送到故障的机器上，整体来说仍然不能达到高可用。面对这样的问题，我们的第一反应是是否能够让请求不要再转发到故障的机器呢？
答案是肯定的，这种做法叫failover—故障转移，与failover经常一起出现的还有一种设计方案叫灾难恢复，它们常常一起使用。要达到的效果是，代理发现某台服务器无法访问，便不将请求发往这台机器，同时会启动另外一台机器，当这台机器完成初始化便将部分请求发往新的机器上。此时的架构应该是这样的：
通过上面的设计，我们离高可用又近了一步，但是仍然不能说是高可用的设计。试想，现在我们的服务都是多数据中心的了，而且能够进行故障转移和灾难恢复；然而，如果我们的web server并没有出现故障，能够被访问并且响应请求，但是响应速度非常的慢，每次请求都要过很久才能返回，原因可能是请求量太大，导致机器资源消耗严重无法正常响应。我们前面说过，当一个服务不能够正常的响应，就算它能够处理请求，也算是不可用。
那么遇到这种情况该怎么处理呢？这里我需要引入一个新的概念：Scaling—伸缩。这个概念在云服务中经常能够看到，AWS，Google cloud都号称自己的计算服务是Auto Scaling的，意思是他们的服务能够自动伸缩，这正是我们解决上述问题的关键。
我们希望达到的效果是：当web server资源（CPU，内存等）消耗达到很高的值时，我们能够启动新的web server缓解压力；与此同时，当过了高峰期，请求量降到很低时，我们能够关闭掉多余的服务器，不至于造成资源浪费。此时的架构应该是这样的：
通过上面的设计，这样的架构我们已经基本上可以称之为高可用的了。我们对每个环节都作了考虑，出现的问题也有了相应的处理方案，让服务保持一直可用——高可用。
总结
- Cluster/Distributed
- HA Proxy(Load Balancing, Failover etc.)
- Auto Scaling
我们如果能够做好上面的三点，那么搭建一个高可用的架构就不是什么难事了，虽然上面三点都是难点 :p
参考资料
- AWS官网：http://aws.amazon.com
- AWS参考架构：http://aws.amazon.com/architecture
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
