rnda2架构 rdna3架构

之前的几篇文章介绍了高可用应用，以及说明了高可用架构是云端应用的重要特点。今天的文章介绍一些高可用应用架构框架，大家可以从中作为云端应用设计方面的借鉴。

 

我将通过一个web应用的架构设计来说明这些架构，web应用的基础架构搭建在AWS上，利用AWS提供的相应服务，可以设计出不同的高可用方案。

 

1. 最简单的三层架构：

这与传统非云架构的三层架构一致，没有分布式架构，只拥有一个单独的应用实例，单一的数据库。如下图，架构采用：

1. EC2
2. Amazon RDS
3. Route 53 DNS服务
4. S3 作为内容存储，数据备份

该架构结构简单，使用的S3备份服务后已经具有一定的防灾，灾难恢复功能。这种架构AWS官方说明可以具有每年少于3天15小时的宕机时间。这对大多数商业应用是不满足要求的。但是在开发，测试环境中被广泛使用。

 

2. 多域高可用设计模式

该设计模式提高了应用的高可用指标，宕机时间达到少于每年8小时45分钟。该设计采用：

1. AWS MultiAZ
2. EC2提供计算服务
3. ELB 作为负载均衡，
4. ASG (Auto Scaling Group)管理实例增减，替换
5. RDS 数据库，采用两个AZ RDS区域，灾难切换通过ASG实现
6. 应用被分为多个AZ 区，最前端是两个Reverse Proxy，之后的两个Web server，提供双活机制，增强可用性。
7. 软件架构要支持双活机制的自动切换
8. 软件架构要支持系统无缝升级，以及客户无感知的业务回滚
9. 软件架构应具有系统监控模块，监控web http 200 状态。
10. S3 提供系统备份功能

 

该架构的可用性已经很高，适用于有高可用性要求，但容许短暂业务暂停。比如企业内部使用的，但重要性又是很高的企业级应用，以及客户数量不高的对外商业应用。

 

3. 面向客户的商业应用

面向客户的应用对高可用有很高的要求，这里提供的架构可以保证每年低于52分钟的宕机时间。这个架构看起来与上面的很相似，但是由双活办成3实例高可用，这就更大的保证了高可用性，在某个instance宕机后不会影响业务，应用通过监控组件，发现问题，自动替换有问题的虚机。设计系统时需要注意着几点：

1. 将应用程序部署在3个域中，三个域相互隔离，每个域设计负载容量极限不是整个系统的三分之一，而是50%容量
2. 对于可以被缓存的内容，添加CloudFront以减少系统负载
3. 在所有层中实现软件/应用程序弹性模式
4. 需要实现自动部署，系统支持自动回滚，以实现系统出现故障是快速回复。
5. 系统必须包括监控组件，用于监控系统，汇报问题。