云架构中心-内部工具或公测类应用典型部署架构(99%)
内部工具或公测类应用典型部署架构(99%)
内部工具类应用通常用于内部操作,且在故障时只会对内部员工造成影响,不可用时只会带来不方便,可以承受长时间的恢复时间和恢复点;公测类应用用于面向客户的实验性的工作负载,在必要时可以隐藏其功能;针对这些应用,其可用性目标通常要求不高,可达到99%,即每年中断时间可以为3.65天。
导致业务中断的时间包含故障中断时间及由于升级配置维护等导致的中断时间,假定分别中断时间如下:
- 故障中断:假定每年故障中断4次,每次应急恢复决策时长为1小时,应用负载重新部署、配置与数据恢复时长为2小时,则每年故障中断时长为12小时。
- 变更中断:假定应用离线更新,每年更新6次,每次更新时长4小时,则每年更新时长为24小时。
按照以上评估,每年应用系统不可用的时长是36小时,满足可用设计目标要求。
内部工具类应用典型架构为前端无状态应用层+后端数据库,其中前端无状态应用可采用E CS 或CCE(以ECS为例),后端数据库基于不同业务类型可采用不同数据库,通常为RDS for MySQL;为满足对应的可用性目标,建议方案如下:
类别 |
实施方案 |
---|---|
冗余 |
ECS与RDS单节点部署。 |
备份 |
RDS自动备份,在数据故障时使用最新备份数据恢复,可以满足可用性目标要求。 |
容灾 |
不支持容灾部署,在站点故障的情况下,重新进行应用部署与备份数据恢复。 |
监控告警 |
进行简单的监控,检查应用系统是否能正常返回消息。 |
弹性扩缩容 |
提供常见故障处理runbook,以便在容量不足等场景可以手工扩容。 |
变更防差错 |
软件更新采用离线更新,安装和重启应用需要停机,根据runbook进行应用的部署与回滚。 |
应急恢复处理 |
指定应用系统责任人,在突发事件后能找到相关责任人进行恢复处理。 |
根据以上方案,典型部署架构如下:
该架构的主要特点包括:
- 应用系统部署在单Region单AZ。
- 为了保证数据的可靠性,RDS数据库的数据定期自动备份到OBS,在数据丢失时可以快速恢复。