# 金融类核心应用典型部署架构（99.999%）
金融类核心应用通常比较重要，要求非常短的恢复时间和数据丢失量，其可用性目标通常要求达到99.999%，即每年故障时间可以为5.26分钟。
假定故障中断与变更中断的时长分别如下：
- 故障中断：由于要求的故障中断时间很短，要求尽可能自动恢复，没有手动触发的恢复，假定每年故障中断4次，每次自动恢复时长为1分钟，则每年故障中断时长为4分钟。
- 变更中断：假定应用支持金丝雀部署或蓝绿部署，并自动完成，软件更新不中断业务。
按照以上评估，每年应用系统不可用的时长是4分钟，满足可用设计目标要求。
金融类应用典型架构为三层架构：前端Web集群+后台应用集群+后端数据库集群，其中前端无状态应用可采用ECS或CCE（以CCE为例），后端数据库通常采用RDS for MySQL提供更高性能与可靠性；为满足对应的可用性目标，建议方案如下：
| 类别     | 实施方案                                                                                          |
|:---|:---|
| 冗余     | ELB、CCE、DCS、Kafka、RDS、DDS等云服务实例均高可用部署。                                                        |
| 备份     | RDS、DDS数据库自动备份，在数据故障时使用最新备份数据恢复，可以满足可用性目标要求。                                                  |
| 容灾     | 应用跨AZ部署，AZ故障时自动恢复；支持跨Region双活容灾，在出现Region级故障时可以自动切换在异地恢复业务。                                   |
| 监控告警   | 进行站点运行状态检查，在发生故障时告警；针对CCE、DCS、kafka、RDS、DDS等实例负载状态进行监控，在资源过载时需要告警。                            |
| 弹性扩缩容  | CCE集群支持工作负载的自动弹性伸缩。                                                                           |
| 变更防差错  | 软件更新采用金丝雀或蓝绿部署，部署过程自动完成，在部署过程中出现问题时自动回滚。                                                      |
| 应急恢复处理 | 制定应急处理机制，指定应急恢复人员，以便在突发事件后能快速决策和恢复；并提供常见应用、数据库问题以及升级部署失败的相关解决方案，以便在出现问题后可以及时恢复；定期进行演练，及时发现问题。 |
   
根据以上方案，典型部署架构如下：
![](https://support.huaweicloud.com/usermanual-architecture/zh-cn_image_0000001967751385.png)
该架构的主要特点包括：
- 应用系统采用无状态应用+有状态数据库的分层部署架构。
- 应用系统在两个Region各部署一套完整系统，Region内跨AZ高可用部署，提供同城跨数据中心双活能力；Region间数据单元化部署，实现跨Region双活容灾，在任一Region故障的情况下能快速恢复业务。
  - 接入层（外部GSLB、API网关）：通过外部GSLB进行域名解析与流量负载均衡，两个Region同时提供服务，在单个Region故障时自动将业务流量切换到另一Region；API网关支持流量纠正，以便将业务路由到正确单元。
  
  - 应用层（ELB负载均衡器、应用软件及容器）：对于无状态应用，通过ELB负载均衡器进行故障检测与负载均衡，并可通过容器进行弹性伸缩。
  
  - 中间件层：Redis、Kafka集群跨可用区高可用部署。
  
  - 数据层：MySQL数据库跨可用区高可用，通过DRS数据复制服务实现跨Region的双向数据库复制与容灾切换；并支持定期自动数据备份，在数据丢失时能快速恢复。OBS对象存储服务同样支持跨Region的双向复制能力。
   
- 为了保证数据的可靠性，RDS for MySQL、DDS数据库的数据定期自动备份。