| 编辑推荐: |
| 云端高可用应用架构三种常用的架构以及两种则是高可用方面的战斗机.大家可以从中作为云端应用设计方面的借鉴.
本文来自于csdn，由火龙果软件Anna编辑、推荐。 |
|
我将通过一个web应用的架构设计来说明这些架构，web应用的基础架构搭建在AWS上，利用AWS提供的相应服务，可以设计出不同的高可用方案。
1. 最简单的三层架构：
这与传统非云架构的三层架构一致，没有分布式架构，只拥有一个单独的应用实例，单一的数据库。如下图，架构采用：
EC2
Amazon RDS
Route 53 DNS服务
S3 作为内容存储，数据备份该架构结构简单，使用的S3备份服务后已经具有一定的防灾，灾难恢复功能。这种架构AWS官方说明可以具有每年少于3天15小时的宕机时间。这对大多数商业应用是不满足要求的。但是在开发，测试环境中被广泛使用。
2. 多域高可用设计模式
该设计模式提高了应用的高可用指标，宕机时间达到少于每年8小时45分钟。该设计采用：
AWS MultiAZ
EC2提供计算服务
ELB 作为负载均衡，
ASG (Auto Scaling Group)管理实例增减，替换
RDS 数据库，采用两个AZ RDS区域，灾难切换通过ASG实现
应用被分为多个AZ 区，最前端是两个Reverse Proxy，之后的两个Web server，提供双活机制，增强可用性。
软件架构要支持双活机制的自动切换
软件架构要支持系统无缝升级，以及客户无感知的业务回滚
软件架构应具有系统监控模块，监控web http 200 状态。
S3 提供系统备份功能
该架构的可用性已经很高，适用于有高可用性要求，但容许短暂业务暂停。比如企业内部使用的，但重要性又是很高的企业级应用，以及客户数量不高的对外商业应用。
3. 面向客户的商业应用
面向客户的应用对高可用有很高的要求，这里提供的架构可以保证每年低于52分钟的宕机时间。这个架构看起来与上面的很相似，但是由双活办成3实例高可用，这就更大的保证了高可用性，在某个instance宕机后不会影响业务，应用通过监控组件，发现问题，自动替换有问题的虚机。设计系统时需要注意着几点：
将应用程序部署在3个域中，三个域相互隔离，每个域设计负载容量极限不是整个系统的三分之一，而是50%容量
对于可以被缓存的内容，添加CloudFront以减少系统负载
在所有层中实现软件/应用程序弹性模式
需要实现自动部署，系统支持自动回滚，以实现系统出现故障是快速回复。
系统必须包括监控组件，用于监控系统，汇报问题。
4. 多物理区域部署方案
良好的应用以及基础架构设计可以很好的提高系统的高可用性，甚至达到每年52分钟的最小宕机时间。如果需要继续提高商业引用的高可用，就需要考虑多物理区域部署的方案，该方案通过夸物理区域的部署，避免单区域灾难的冲击。
跨物理区域方案具体设计为：
设计两个物理区域部署应用，两个区域设计为主、备，热备份的关系。
被动站点按比例缩小，最终保持一致，以获得与活动站点相同的流量。
两个区域都应保持静态稳定，以处理所有能力要求，即使是在一个AZ区故障期间。
在所有层中实现应用组件的弹性模式。
将需要一个轻量应用组件来监测应用程序的健康状况和区域依赖性。
静态网站在系统中扮演重要角色，其不但用于缓解高并发的情况，同时在故障转移期间，请求将被路由到静态网站，用以实现无缝迁移。
软件更新将使用蓝绿部署方法或者是Canary部署方法
该架构可以保证每年4小时以下的宕机时间，虽然不如上面提到的单物理节点商业级应用，但是因为其多物理区域的特点，许多银行，金融企业使用该架构。
5. 最高端的高可用应用架构
最高端的高可用架构可以保证每年少于5分钟以下的宕机时间，提供99.999%的高可用，可以说是高可用上的战斗机。重要的银行，金融，政府，军队部门都采用这样的架构。
高性能的存储解决方案，
架构中的每一层中采用冗余方案
在可能的情况下使用NoSQL数据库
采用主动/主动的多区域方法。每个区域都必须是静态稳定的
路由层将向健康站点发送流量，并在故障期间停止复制
在所有层中实现应用组件的弹性功能
需要一个轻量应用组件来监测应用程序的健康状况和区域依赖性。
静态网站在系统中扮演重要角色，其不但用于缓解高并发的情况，同时在故障转移期间，请求将被路由到静态网站，用以实现无缝迁移。
软件更新将使用蓝绿部署方法或者是Canary部署方法————————————————
|
