Question云原生基础设施Cloud Native IAAS Answer

Cloud Native IAAS云原生基础设施产品数据备份与恢复机制

云原生基础设施产品数据存储依赖于阿里云IAAS层基础服务能力，数据存储采用了阿里云数据库PolarDB,云数据库RDS，云数据库MongoDB，云数据库Redis等。

1、数据库选型 云数据库PolarDB PolarDB采用存储和计算分离的架构，所有计算节点共享一份数据，提供分钟级的配置升降级、秒级的故障恢复、全局数据一致性和免费的数据备份容灾服务。 PolarDB可提供稳定可靠、高性能、可扩展的，性能最高可以提升至MySQL的6倍。

云数据库RDS 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和SSD盘高性能存储，提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案。

云数据库MongoDB 云数据库MongoDB版（ApsaraDB for MongoDB）是基于飞天分布式系统和高可靠存储引擎的在线数据库服务，完全兼容MongoDB协议，提供稳定可靠、弹性伸缩的数据库服务。

2、数据库备份策略 2.1、物理备份，底层跨可用区分布式存储的物理备份，如北京可用区H --> 北京可用区J , 采用高速通道 ，时时备份；

2.2、一级快照备份，保存在本地即直接存储在分布式存储集群中，可实现快速备份与快速恢复；

2.3、二级快照备份，保存在其它离线存储介质中，数据来源于一级备份，可实现较长时间的存储及恢复；

2.4、日志备份，时时记录数据库的Redo日志，确保最近一时间内数据的安全，避免误操作导致的数据丢失，可按时间点实现数据恢复；

3、备份频率 3.1、备份周期
周1~周7 3.2、备份时间 02:00~03:00

4、数据备份保留 4.1、 一级快照备份 7天 4.2、 二级备份 30天 4.3、 日志备份 7天

5、数据库安全 5.1、数据库审计 针对数据库SQL注入、风险操作等数据库风险操作行为进行记录与告警。SQL审计日志可记录对数据库执行的所有操作，从而实现对数据库进行的故障分析、行为分析、安全审计。

5.2、数据库白名单 最小开放可访问数据库集群的IP地址、IP网段；

5.3、数据库操作 5.3.1、禁止开发人员对数据库实例的直连操作； 5.3.2、采用SQL审核管理平台Yearning对开发人员提交的增删改的sql进行审核并执行； 5.3.3、为开发人员开放只读帐号用于对数据的检索查询；

5.4、数据库管理 由专业的数据库管理团队负责对各领域、各环境数据库的日常管理工作；

6、数据恢复 6.1、支持数据库 库/表 级恢复，理论上可实现恢复到任意时间点的数据； 6.2、根据备份保留时间支持恢复7天内的数据、30天内的数据及其它数据恢复要求；

云原生基础设施Cloud Native IAAS 平台产品应用底层高可用性及故障处理

产品底层计算、存储、网络、数据库、CDN、安全等依托于阿里云 & 华为云基础服务能力，容器云CPAAS平台、云原生部署依赖阿里云，华为云IAAS基础产品，Cloud Native IAAS所有应用服CPAAS平台之上。

1、弹性计算产品ECS及高可用性、可靠性可恢复性 CPAAS平台构建于阿里云&华为云ECS之上，ECS单实例可用性高达99.975%，跨AZ多机可用性则 达到了99.995%。ECS镜像文件、快照文件均默认存储3份，分布在不同交换机下的不同物理服务器上，数据可靠性达不低于99.9999999%。 ECS服务器部署在宿主机上，宿主机异常或者硬件故障时，系统会启动保护性迁移，将ECS迁移至正常宿主机上，恢复实例正常运行，保障应用的高可用性。

2、块存储、文件存储、对象存储及高可用性 2.1、块存储采用3副本的分布式机制，为ECS实例提供99.9999999%的数据持久性保证。

2.2、文件存储（NAS）是面向阿里云ECS实例、Docker等计算节点的文件存储服务，它是一个可共享访问，弹性扩展，高可靠，高性能的分布式文件系统。文件存储的数据自动地在可用区以多副本冗余方式存储，避免数据的单点故障风险，可提供高达99.999999999%的数据持久性。

2.3、对象存储（OSS）是阿里对外提供海量、安全高可靠的云存储服务。它采用多可用区（AZ）机制，将用户数据分散存放在同一地域（Region）的3个可用区。它可提供同城冗余存储99.9999999999%（12个9）的数据可靠持久 性，并且能提供99.95的数据可用性。

3、网络及高可用性 3.1、阿里云负载均衡（SLB）是对多台云服务器进行负载分发的负载均衡服务。它通过流量分发扩展了应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。

3.2、SLB采用冗余 设计，无单点，支持同城容灾。配合DNS可实现跨地域容灾，可用性高达 99.95%。

4、云数据库及高可用性 4.1、阿里云关系性数据库（RDS & PolarDB）是稳定可靠、可弹性伸缩的在线数据库服务。基于分布式文件系统及高性能存储，提供了容灾、备份、恢复、监控、迁移等多方面的解决方案。

4.2、高可用版的数据库实例拥有2个及2个以上数据库节点进行主从热备，主节点发生故障可以迅速切换至备节点，服务可用性可达到99.95%。

4.3、云数据库可根据备份 策略将数据库恢复至任意时刻，提高了数据的可回溯性。

5、PAAS平台及高可用性可恢复性 5.1、架构合理化，冗余设计，全链路、全核心组件无单点，可用性高达99.95%。

5.2、监控多元化，无死角、多维度、多视角监控，如资源监控、系统监控、端口监控、核心接口监控、网络监控、流量监控、jvm监控等等。

5.3、报警自动化模块化，分级处理、多渠道监控，如微信报警、IM报警、邮箱报警；0级报警、1级报警、2级报警等等。

5.4、故障处理流程化，从时间维度严格按事前、事中、事后对接收到的报警、业务反馈等内容进行分析、处理、归纳总结。

5.5、人员专业分组化，按专业类别及专业深度对人员进行分组，人员搭配合理，全员轮转值班，做到人尽其才，故障处理无盲点。

cdn内容分发网络如何加速数据处理？

当用户访问使用CDN服务的网站时，本地DNS服务器通过CNAME方式将最终域名请求重定向到CDN服务。CDN通过一组预先定义好的策略(如内容类型、地理区域、网络负载状况等)，将当时能够最快响应用户的CDN节点IP地址提供给用户，使用户可以以最快的速度获得网站内容。

使用CDN后的HTTP请求处理流程如下。

HTTP请求流程说明：

1、用户在浏览器输入要访问的网站域名www.example.com，向本地DNS发起域名解析请求。 2、本地DNS检查缓存中是否有www.example.com的IP地址记录。如果有，则直接返回给终端用户；如果没有，则向网站授权DNS查询。 3、网站DNS服务器解析发现域名已经解析到了CNAME：www.example.com.c.cdnhwc1.com。 4、请求被指向CDN服务。 5、CDN对域名进行智能解析，将响应速度最快的CDN节点IP地址返回给本地DNS。 6、用户获取响应速度最快的CDN节点IP地址。 7、浏览器在得到最佳节点的IP地址以后，向CDN节点发出访问请求。 7.1、如果该IP地址对应的节点已缓存该资源，节点将数据直接返回给用户，如图中步骤7和8，请求结束。 7.2、如果该IP地址对应的节点未缓存该资源，节点回源请求资源。获取资源后，结合用户自定义配置的缓存策略，将资源缓存至节点，如图中的北京节点，并返回给用户，请求结束。

云服务WAF业务带宽说明

Web应用防火墙（WAF）实例有默认业务带宽限制。

什么是业务带宽 业务带宽指WAF实例支持处理的网站正常业务流量的峰值带宽大小，单位为Mbps。每100 Mbps业务带宽对应约4,000 QPS（Query Per Second，即每秒钟的请求量）的并发请求。

多个网站业务接入WAF实例进行防护，则必须保证所有网站业务的正常峰值带宽之和不超出WAF实例的业务带宽。超出业务带宽限制将给网站访问带来影响。

超出业务带宽限制有什么影响

接入WAF防护的网站正常业务流量超出您已购买的WAF实例的业务带宽限制，您将会在Web应用防火墙控制台顶部收到相关提示。

长时间超出业务带宽限制会使网站流量转发进入限速状态，可能出现限流、随机丢包等现象，导致您的正常网站业务在一定时间内不可用、卡顿、延迟等。如果出现这种情况，您需要通过升级WAF版本、购买带宽扩展包，来提升WAF实例的业务带宽，避免正常业务流量超出业务带宽限制所产生的影响。

如何评估所需业务带宽 购买WAF实例前，您需要提前考虑您准备接入WAF防护的所有网站的日常入方向总流量的峰值带宽、出方向总流量的峰值带宽，确保您选购的WAF实例的业务带宽大于入方向总流量峰值带宽、出方向总流量峰值带宽中较大的值（一般情况下，出方向流量峰值带宽更大）。您可以参考云服务器ECS实例的监控数据，或者通过您站点服务器上的其他监控工具来评估您的实际业务流量大小。

如果网站对应多个源站ECS实例，则需要统计所有源站ECS实例流量峰值带宽的总和。假设您需要通过WAF防护三个站点（源站服务器在阿里云），每个站点的出方向的正常业务流量峰值带宽都接近30 Mbps，峰值带宽总和接近90 Mbps。这种情况下，WAF企业版实例的默认带宽（100 Mbps）即可满足您的需求，您可以直接购买企业版实例；如果您希望购买高级版实例（默认业务带宽为50 Mbps），则必须同时购买带宽扩展包，增加实例的业务带宽。

超出业务带宽限制如何处理 如果您通过WAF防护的网站的业务流量大于WAF实例的默认业务带宽，您可以额外购买扩展带宽包（带宽扩展包仅适用于包年包月计费模式），避免网站业务流量超出业务带宽限制所产生的影响。

例如，假设您当前的业务流量需求为150 Mbps（源站服务器在阿里云），您已经购买了WAF企业版实例（默认业务带宽为100 Mbps），这种情况下您需要额外购买50 Mbps的扩展带宽，确保您的业务访问正常。

云服务带宽（WAF）性能运行报告

云服务带宽配额说明 当前云服务带宽支撑的配额信息如下： 业务带宽：400Mbps 业务QPS： 17000

说明：业务带宽及业务QPS支持根据业务需求量进行弹性扩容！

故障应急处理方案

1、确定故障现象并初判问题影响 -- 识别问题

利用监控系统获得有价值的信息，综合多方数据确定故障现象并被判问题影响。 技术早于业务发现问题，监控不仅是报警，还要协助故障定位，利用完善的监控系统、对网络，服务器cpu、负载、io、内存、连接数（文件句柄数）以及应用系统性能、异常日志等进行全方位、全链路监控。

2、根据故障现象制定故障应急操作流程对系统进行应急恢复 -- 定位问题、解决问题、消除影响

部分故障应急操作简述如下：

• 2.1 服务整体性能下降或异常，可以考虑重启服务
• 2.2 应用做过变更，可以考虑是否需要快速回滚
• 2.3 资源不足，可以考虑应急扩容
• 2.4 应用性能问题，可以考虑调整应用参数、日志参数等
• 2.5 数据库繁忙，可以考虑通过数据库快照分析，优化SQL，杀掉异常线程

2.6 应用功能设计有误，可以考虑紧急关闭功能菜单，降级使用

另：故障处理前，有条件情况下应保存下当前系统场景，如dump当前系统快照、对某些现象进行截图保存等等。

3、根据解决过程对问题进行复盘 -- 回顾问题

3.1 是否为偶发性、是否可重现

如可重现可模拟过程对故障进入深入验证以求彻底解决方法； 如故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。

3.2 是否进行过相关变更

大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进 而快速定位故障并准备好回切等应急方案。

3.3 是否可缩小排查范围

故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程度后再开始协调关联团队排查。

3.4 是否有足够的日志 3.4 是否有足够的日志

定位故障原因，最常用的方法就是分析应用日志，日常要对系统日志进行充分日志收集，要做到日志信息尽可能收集详尽、业务系统尽可能收集完善，借助ES/kibana等存储展示工具进行便利化检索及分析

3.5 是否有core或dump等文件 3.5 是否有core或dump等文件

故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如 CORE\DUMP，或TRACE采集信息等，现场截图，备份好一些可能被覆盖的日志等

4、采取措施 -- 规避问题

4.1 建立并完善故障处理流程

4.2 配置生产环境故障处理核心团队

4.3 重大故障处理项目化、流程化

召集相关人员组成问题紧急处理应急项目部 --> 描述故障现状 --> 说明正常应用逻辑流程 --> 陈述变更 --> 排查进展，展示信息 --> 领导决策

4.4 完善监控系统

监控可视化完善，将隐性数据显性化可大大提升故障分析处理效率 完善监控指标，实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理；实现对进程、端口、连接数等全方位的监控； 完善监控告警，监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案，目前cloud native iaas监控告警已实现多终端（移动端、PC端）、多应用（微信、IM、邮箱）、按领域分组、按资源池分组等个性化的告警机制。

4.5 监控告警处理主动性上完善 4.5 监控告警处理主动性上完善

运维人员合理分组（老带新、强弱互补）形成轮值值班制度，确保365*24小时无空白、无间断处理各环境报警信息。

资料储备

高性能 分布式数据库支撑大数据处理，解决了IO及cpu瓶颈问题 微服务基于容器云管理，可弹性伸缩，解决了应用服务性能问题 分布式并行运算，解决了算力不足问题

高可用 系统无单点，任意节点故障，不影响系统正常运行 微服务、容器化，智能运维带来系统自愈能力

敏开发 按微服务粒度，快速更新迭带，灰度发布，滚动升级

简运维 基于Pass实现智能运维，极简运维

创新发展工程项目申报--运维管理系统

运维管理系统 运维管理系统是我公司自主研发的一款集资源管理、资源监控、资源报警、故障处理于一体的运维服务平台，同时它还具备链路管理，安全防护，多数据中心上线管理，容器云管理等等众多能力。

公有云容灾方案

为了给客户提供更好的服务质量，服务体验，技术团队在系统设计之初就详细考虑了系统的高可用、高可靠、高性能及容灾、恢复等方案。

IAAS产品容灾方案

Cloud native iaas系统的底层计算能力、存储能力、网络能力、数据库、缓存、CDN、安全防护等依托于阿里云和华为云等CSP的基础服务能力；Cloud native iaas容器云平台（PAAS）、部分中间件、部分云原生产品依赖于阿里云和华为云提供的ECS自部署；Cloud native iaas所有应用服务（微服务）构建于云PAAS平台之上。

弹性计算产品ECS的容灾

Cloud native iaas云PAAS平台构建于阿里云和华为云ECS之上，ECS单实例可用性高达99.975%，跨AZ（可用区）多机可用性则达到了99.995%。ECS镜像文件、快照文件均默认存储3份，分布在不同交换机下的不同物理服务器上，数据可靠性达不低于99.9999999%。 ECS服务器部署在宿主机上，宿主机异常或者硬件故障时，系统会启动保护性迁移，将ECS迁移至正常宿主机上，恢复实例正常运行，保障应用的高可用性。

块存储、文件存储及对象存储等产品的容灾

块存储采用3副本的分布式机制，为ECS实例提供99.9999999%的数据持久性保证。

文件存储（NAS）是面向阿里云ECS实例、Docker等计算节点的文件存储服务，它是一个可共享访问，弹性扩展，高可靠，高性能的分布式文件系统。文件存储的数据自动地在可用区以多副本冗余方式存储，避免数据的单点故障风险，可提供高达99.999999999%的数据持久性。

对象存储（OSS）是阿里对外提供海量、安全高可靠的云存储服务。它采用多可用区（AZ）机制，将用户数据分散存放在同一地域（Region）的3个可用区。它可提供同城冗余存储99.9999999999%（12个9）的数据可靠持久 性，并且能提供99.95的数据可用性。

OSS底层依托于盘古存储，采用分布式架构部署，无单点故障存在。文件以chunk分块方式存储，默认每块存三副本，并分布在不同机架的ChunkServer节点上。在盘古集群中Master允许宕机1台,Chunkserver允许同时宕机2台,KVServer与WS允许宕机多台。KV集群采用CS架构，故障自动恢复, 对应用透明，WS为无状态接入层,通过SLB实现容错与负载分担。

云负载均衡的容灾

阿里云负载均衡（SLB）是对多台云服务器进行负载分发的负载均衡服务。它通过流量分发扩展了应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。

阿里云SLB产品使用开源软件LVS＋keeplived实现4层的负载均衡。 采用淘宝的Tengine实现7层的负载均衡。所有负载均衡均采用集群部署，集群之间实时会话同步，以消除服务器单点，提升冗余，保证服务稳定。在各个地域采用多物理机房部署，实现同城容灾。 SLB在整体设计上让其可用性高达99.99%。且能够根据应用负载进行弹性扩容，在任意一台SLB故障或流量

波动等情况下都能做到不中断对外服务。

同城容灾（多可用区容灾）

使用负载均衡时，可以将负载均衡实例部署在支持多可用区的地域以实现同城容灾。通过该特性可实现当可用区机房发生故障时，负载均衡能在较短时间内，将前端访问流量切换到同一地域下的其它可用区，恢复服务能力。

异地容灾（跨地域容灾）

可以在不同地域下部署负载均衡实例，并分别挂载相应地域内不同可用区的ECS。上层利用云解析做智能DNS，将域名解析到不同地域的负载均衡实例服务地址下，可实现全局负载均衡。当某个地域出现不可用时，暂停对应解析即可实现所有用户访问不受影响。

云数据库的容灾

阿里云关系性数据库（RDS & PolarDB）是稳定可靠、可弹性伸缩的在线数据库服务。基于分布式文件系统及高性能存储，提供了容灾、备份、恢复、监控、迁移等多方面的解决方案。

高可用版的数据库实例拥有2个及2个以上数据库节点进行主从热备，主节点发生故障可以迅速切换至备节点，服务可用性可达到99.95%。

云数据库可根据备份 策略将数据库恢复至任意时刻，提高了数据的可回溯性。

主备架构容灾

RDS默认采用主备架构（备用实例正常情况下对用户不可见），两个实例位于不同服务器，自动同步数据。主实例不可用时，系统会自动将数据库连接切换至备用实例。切换是分钟级别，而且不需要人工介入，全部由系统自动完成，应用系统也无需任何变更。这种架构足以满足90% 用户的高可用需求。

同城多可用区容灾

用户如果对系统可用性有更高的要求，希望可以做到机房容灾，阿里云RDS可以选择购买多可用区RDS。多可用区是在单可用区的级别上，将同一地域的多个单可用区组合成的物理区域。相对于单可用区RDS实例，多可用区RDS例可以承受更高级别的灾难

异地容灾

对于数据可靠性有强需求用户，比如是有监管需求的金融业务场景，RDS提供异地灾备实例，帮助用户提升数据可靠性。 RDS通过数据传输服务（DTS）实现主实例和异地灾备实例之间的实时同步。主实例和灾备实例均搭建主备高可用架构，当主实例所在区域发生突发性自然灾害等状况，主节点（Master）和备节点（Slave）均无法连接时，可将异地灾备实例切换为主实例，在应用端修改数据库链接地址后，即可快速恢复应用的业务访问。 

云搜索服务的容灾

阿里云Elasticsearch提供数据备份与恢复、负载均衡、跨可用区部署，以及保障集群稳定的各类内核优化策略，全方位保障集群数据的可靠性和服务的可用性。 阿里云Elasticsearch提供了全托管的Elasticsearch服务，并且100%兼容开源版本。可靠性方面，阿里云Elasticsearch具有99.9%的数据可靠性，并且会定时地向OSS进行数据备份，方便用户在数据出现问题的时候进行恢复。此外，通过同城多活，提供了较强的容灾能力。

产品架构部分，阿里云Elasticsearch部署在ECS网段，相当于购买了大量的ECS服务器拉起了ES镜像。对用户而言，可以购买很多的ES集群，每个ES集群中都会有很多的Node，每个Node就是一台ECS。整个ECS部署在系统方VPC内，并且支持跨可用区的同城容灾能力，也就是说在同一个区域下面，可以在不同的可用区内部署服务，通过阿里云VPC和用户VPC之间的IP映射使得每个集群的Node分布在不同的可用区之内。

云缓存redis服务的容灾

阿里云架构上有集群版、标准版和读写分离版。 标准版是主备版本，提供最好的Redis命令兼容性，当主节点出现宕机时，HA高可用切换模块会去做故障迁移，将Slave提升为Master，原来的Master恢复后作为新的Slave； 集群版架构相对复杂，后端有多个DB节点，每个DB节点架构类似于标准版主备形态，多个DB节点数据需要做路由，就需要多个Proxy节点，集群版还增加一个Configserver，该角色保存了集群间元素信息。当某一个DB节点出现宕机，都会有一个独立的切换模块，并更新Configserver和Proxy的信息；读写分离版只有一个DB节点，一个Master上挂了多个只读节点，当读流量进来时，会根据Proxy判断后端只读节点数量做自动负载均衡，当Master出现宕机时，只读节点需要挂载到新的Master上。

云redis产品支持单机房主备容灾；支持同城(单region)双机房（多AZ）容灾；支持异地多机房容灾&多活。

单可用区高可用机制

Redis全架构均支持单机房HA高可用架构。HA监控系统采用独立的平台化架构，提供跨可用区的高可用机制，使云数据库Redis版比自建Redis更稳定。

标准版-双副本

标准版-双副本实例采用双机主从（Master-Replica）架构，高可用HA模块侦测到主节点故障时，会自动进行主从切换，将Replica提升为Master，而原来的Master恢复连接后会成为新的Replica。实例默认开启数据持久化功能，支持数据自动备份，您可以使用备份文件回滚实例或者克隆实例，有效地解决误操作问题并实现可靠的灾备。

集群版-双副本

集群版-双副本实例由配置服务器、代理服务器和分片服务器组成：

• 配置服务器（Config Server）是用于提供全局路由信息和配置信息的集群管理工具，采用遵循Raft协议的三副本集群架构；
• 代理服务器（Proxy Server）为单节点架构，集群版结构中会有多个Proxy，系统自动对所有Proxy进行负载均衡及故障转移；

分片服务器（Shard Server）同样采用双副本高可用架构，与标准版-双副本实例相同，主节点故障之后，HA模块会自动进行主从切换保证服务高可用，并更新Proxy Server和Config Server的信息。

同城容灾机制

Redis标准版和集群版提供跨双机房的同城容灾架构。如果业务为单一地域部署，且对容灾要求较高，可在创建云数据库 Redis版实例时，选择支持同城容灾的可用区，如下图中的华东1多可用区（B+F）或华东1多可用区（G+H）。

创建多可用区实例时，备机房将创建与主机房相同规格的Replica实例，主备机房的实例数据通过专门的复制通道同步。

当主机房出现电力或网络问题时，Replica实例将升级为Master实例，系统调用Config Server接口为Proxy更新路由信息。底层网络根据路由精细度实现故障切换，主机房网段的精细度高，因此在正常情况下，数据会直接传输到主机房的实例；当主机房出现故障时，不会上传路由明细信息，此时骨干网中只存在备机房的精细度较低的大网段路由信息，系统就会自动把请求路由到备机房，从而实现故障切换。

跨地域容灾

云数据库Redis版提供了全球范围的异地多活服务，即Redis全球多活，适用于需要在多地域同步部署的业务场景，与传统的灾备方案最大的区别在于多活。异地多活架构使业务能够在多个地域同时进行，各地域中的全球多活子实例实时双向同步。

Redis全球多活实例由多活子实例、同步通道以及通道管理器构成。

• 多活子实例是基本服务单元，所有子实例均可读写；
• 同步通道支持子实例间的实时双向同步，以及容忍度达到天级别的断点续传；
• 通道管理器管理同步通道的生命周期，同时处理子实例在故障时的主从切换以及备份重搭，保证多活实例的高可用。

底层核心系统容灾设计

Region-区域/地域：简单来说，可以将 Region 理解为不同城市的机房。公有云的 Region 遍布全球，国内的话，通常会有北京 Region、上海 Region、广州 Region 等等。不同 Region 之间，一般只能通过公网连通。

AZ-可用区：可以理解为同一个城市的不同机房，是包含在 Region 内的。比如北京 Region，会包括多个 AZ，而单个 AZ 会有一个或多个 IDC 机房园区组成。AZ 之间通过高带宽、低时延、高冗余的专线网络连接，保证跨 AZ 之间数据传输的安全可靠。

一个 Region 多个 AZ 组成，从机房电力、网络等层面来保障一个 AZ 出现故障的时候不会影响到另外一个可用区。

cloud native iaas容器云部署单region多AZ容灾设计

cloud native iaas 容器云基于阿里云&华为云ECS自建，容器云建设设计之初充分考虑了云系统的高可用、高可靠、高性能等众多因素， 容器云采用集群化部署，整个集群由3台或3台以上ECS组建而成，集群内多台ECS分布在不同的AZ，确保单一AZ发生故障时不会影响整个容器云集群的可用性。 启用多AZ设计后，数据分散存储在城市中多个不同的 AZ 数据中心，当某个 AZ 数据中心因为自然灾害、断电等极端情况导致整体故障时，其他 AZ 数据中心的数据依旧可以正常读取和写入，保障客户数据持久存储不丢失，维持客户业务数据连续性和高可用。

cloud native iaas核心中间件部署region多AZ容灾设计

cloud native iaas系统底层nginx系统、ingress系统，内部DNS系统同样是底层核心系统，对整个业务系统的稳定起到举足轻重的作用。以上系统的部署设计同样全部集群化部署，各系统集群由2台或2台以上的ECS组建而成，集群内多台ECS分布在不同的AZ，确保单一AZ发生故障时不会影响整个集群的可用性。

业务数据中心容灾设计

随着cloud native iaas全球化战略步伐的加快，cloud native iaas用户量的激增和海外业务的大量拓展，单一数据中心已无法满足市场所需

公司一举规化、设计、部署、实施了多个数据中心

单数据中心容灾设计

cloud native iaas IAAS层（ECS/SLB/数据库中间件/云服务）采用同一region 多可用区的部署模式，一是保证了cloud native iaas应用服务在各个可用区的相互访问的网络性能，二是提升了cloud native iaas应用服务在某个可用区不可用情况的容灾恢复能力，多可用区 IAAS层保证了业务的容灾备份和可用性能力；依托公有云优势IAAS层的高可用性和容灾备份能力提到了极大的提升。

• cloud native iaas使用自研"开发者中心"（提供CI/CD能力）接管自建"K8S（Kubernetes）"和公有云"云服务K8S"实现了应用的自动化部署，实现了资源和应用服务的弹性扩缩；同时利用k8s的自动装箱、自我修复（自愈能力）、水平扩展、服务发现和负载均衡、自动发布和回滚、密钥和配置管理、存储编排、批量处理执行等特性实现了应用的灾容，保障了业务的可持续性和连续性。

数据中心多CSP设计

目前在运营中的数据中心部分部署在阿里云，部分部署在华为云，通过多云容灾部署可规避因CSP（云服务提供商）云服务异常导致的全部业务中断情况，保障的cloud native iaas云产品的业务连续性。

国内国外双“引擎”设计

国内3个数据中心可满足现阶段国内大量用户的需求，为提高业务的可延展性、提升海外客户的用户体验，cloud native iaas建设了海外数据中心并成功运营，海外数据中心是国内数据中心的有效补充，极端情况下可作为国内数据中心的容灾环境。

cloud native iaas SAAS服务配置管理流程

1 概述

1.1 内容

配置管理是描述、跟踪、控制和汇报所有cloud native iaas系统基础架构中所有设备或系统的管理流程。这些设备和系统被称为配置项，通过该管理流程实现对所有配置项的有效管理、跟踪和控制，以支持基础设施和系统服务的成功运行。

1.2 适用范围

cloud native iaas系统相关联的所有相关基础设施配置及应用配置

1.3 术语

1.3.1 配置

一种通称，用于描述一组配置项，它们共同提供服务，或可识别的部分服务。配置也用于描述一个或多个配置项的参数设置。

1.3.2 配置管理（CM）

负责维护提供服务所需配置项（包括它们的关系）有关信息的流程。此信息在配置项的整个生命周期得到管理。

1.3.3 配置管理数据库(CMDB)

CMDB专用于保存配置项信息的数据库，配置项信息包括所有配置项的属性、状态及配置项间的关系。CMDB是数据标准制定者、数据加工厂 、信息桥梁。

1.3.4 配置记录（CR）

包含配置项详细信息的记录。每个配置记录，记录了一个配置项的生命周期。配置记录保存在配置管理数据库中。

1.3.5 配置项（CI）

为提供服务而需要进行管理的任何组件或其它服务资产。每个配置项的有关信息记入配置管理系统内的配置记录，并由服务资产和配置管理在信息的整个生命周期内维护。配置项受变更管理的控制。cloud native iaas的配置项通常包括云服务、云中间件、云数据库、云缓存、云虚机、云集群等。

cloud native iaas配置更新和变更流程

配置更新和变更阶段相关角色及权责说明

需求名称	角色划分	操作内容
主动需求变更	配置管理员	日常工作中配置项的增、删、改
CMDB更新维护	配置流程管理员	CMDB结构的调整、高更、修改

配置审计流程

为提升整体数据有效性，cloud native iaas不定期对整体配置数据准确性进行审计

需求名称	角色划分	操作内容
配置项审核请求	配置流程管理员	主动发起配置项审核请求
审核配置、反馈结果	配置审核管理员	仔细核对配置项信息，识别反馈异常配置信息

配置管理策略和制度

1. 不定期对配置进行审核
2. 对大量配置项进行抽样审核，确保样本单位对全部样品具有充分的代表性
3. 配置审核发现异常情况时，应及时对配置信息进行纠正
4. CMDB结构的变更（分类、属性、关系等）：仅限配置流程经理操作，重要变更需经质量管理部评审后方可变更。
5. 配置项的增删改的变更：配置管理员根据需求可变更
6. 配置项的查看权限：原则上不对外开放，仅限各业务领域运维人员查看
7. 配置管理数据库(CMDB)的备份策略

8. CMDB数据库在周一、周二、周三、周四、周六的凌晨2:00~3:00进行数据备份,binlog日志的备份每20分钟备份一次

   数据备份保留天数为12天

cloud native iaas配置项变更管理说明

cloud native iaas配置项以数据中心、资源类型、资源环境为其三大核心属性

2.4.1 cloud native iaas部署单元（应用服务）配置管理

部署单元（应用服务）CMDB信息中除展示了常见的三大核心属性外，还展示了应用code，应用id，应用名称，所属用户，所属领域，资源详细等信息。其中应用id用于唯一标识一个应用，其中操作详情中又关联了此应用所使用的中间件及数据库等信息，此配置信息可用于快速实现对此应用的监控，快速实现对此应用的故障定位和排障。

cloud native iaas 服务器的配置管理

• 服务器CMDB信息中除展示了常见的三大核心属性外，还展示了资源ip、资源所属部门、资源所属资源池等信息，其中依据ip地址信息可以阿里云或华为云控制台上唯一标识一台资源。
• 资源编辑页签可实现对此资源项的变更操作
• 服务器资源的纵向扩缩容通过cloud native iaas工单系统按规范流程操作

cloud native iaas 云中间件及数据库的配置管理

cloud native iaas云数据库PolarDB、云数据库RDS、云中间件Redis、云中间件mq等的配置管理在CMDB信息中除展示了常见的三大核心属性外，还展示了资源ID，资源所属功能、资源所属领域，资源访问域名等信息； 其中的资源ID可唯一的标识一个资源，通过资源ID可快速关联到各CSP平台，链接到该资源； 配置项中“中间件关联应用” 属性还能关联到此中间件所关联到的所有应用，可用于逆向故障排查； 云中间件及云数据库等的配置变更同样使用cloud native iaas工单系统按规范化流程操作