首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏云计算文章

    架构分析和选择策略

    1.传统中心的架构 半径是衡量方案所能承受的灾难影响范围的指标。不同灾难的影响范围是不同的,而距离也会影响到技术的选择。 中心的架构按照源备端之间的距离,可分为本地、同城双活、两地三中心。 1.1本地 本地一般指主机集群,当某台主机出现故障,不能正常工作时,其他的主机可以替代该主机,继续正常对外提供服务。 但共享存储的同构成本和远距离高可用接管成本过高,存在较大存储故障风险,且只支持一对一架构。 双机双柜是一种不依赖共享存储而实现的高可用保护架构,采用主备的高可用保护模式。 云中建立的高可用、高容错架构可以提升RTO和RPO,基于公有云平台或者开源的私有云技术,也可以简便快速灵活地构建节点并将数据迁移或者复制到云端,提升灾难恢复的速度。 随着IT基础架构逐渐云化,也面临着云化转型,不断涌现出更多的云产品和方案。

    3.8K30编辑于 2022-04-29
  • 来自专栏腾讯云中间件专家服务

    客户案例—zookeeper迁移方案

    在至少有一个Leader存在的前提下,进行Zookeeper的在线增量、在线减量、在线迁移 在全过程中ZooKeeper不停止服务 注意事项 首先,当我们要从3台扩充到5台时,应保证集群不停止服务。 3台不停止服务的最低限度是2台(X/2+1),而5台的最低限度是3台。 我们应该保证,集群中最低有3台ZooKeeper是启动的。 -kafka-ds-03 10.1.24.114 idc02-kafka-ds-04 JDK jdk1.7.0_67 ZooKeeper zookeeper-3.4.6 Myid 根据IP自增为1-5 然后只要将现在的5台再缩小到3台且不包括原本myid为1-2的机器,就完成了迁移 将5台缩小回3台 修改idc02-kafka-ds-02 根据前面的注意事项,我们此时5台集群中启动的数量不得少于3台, 因此我们需要先修改3-5号机器的配置文件为3台,再关闭1-2号机器 关闭 12345 [hadoop@idc02-kafka-ds-02 bin]$ .

    2.3K51发布于 2021-07-26
  • 来自专栏开元说说

    系列(六)——数据存储建设

    数据存储建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢? 当前CBS架构和业内分布式存储系统类似,主要分为元数据管理(Master),数据存储(Cell),前端接入(Driver)三个部分组成。 详细架构如下: 1.元数据管理:主要负责集群管理功能,例如路由、卷元数据,集群故障探测以及恢复等管理功能 2.driver接入:主要包括client和agent两部分,client作为块设备在用户侧呈现 1.2 对象存储(COS) COS将数据分散存储在城市中多个不同的数据中心,其中某数据中心故障了,多AZ存储架构依然可以为云上客户提供稳定可靠的数据服务,云上数据可靠性是12个9,即99.9999999999% COS分布式存储系统架构多AZ架构为分层结构主要如下: image.png COS目前具备多AZ属性,如果对于核心数据,成本允许前提下,建议开启跨地域复制功能来进一步加固数据可靠性。

    4.6K73发布于 2021-11-18
  • 来自专栏云容灾云灾备

    什么是云?与传统备有何不同?

    不仅提供数据备份功能,还结合计算、存储、网络等云服务能力,允许企业在云端快速部署环境,并进行自动化业务恢复。二、传统 vs. 云在云出现之前,企业通常采用传统方案,如自建异地备中心或租用备机房。 高可用性(High Availability)云基于云计算的多区域、多数据中心架构,可提供跨地域的数据冗余备份,确保即使在某一区域发生故障,企业仍然能够切换到其他可用区继续运营。 例如,AWS、Azure 和华为云等云厂商都提供多可用区(AZ)架构,支持跨区域业务切换,以降低单点故障风险。2. 例如,AI 可以分析历史数据,智能调配备资源,以确保最优的恢复时间目标(RTO)和恢复点目标(RPO)。5.

    47210编辑于 2025-08-06
  • 来自专栏开元说说

    系列(三)——云网络建设

    IDC时代,业务对网络参与较少,主要依赖数据中心网络建设程度;当到了云的时代,云服务商将底层网络能力产品化后,云上客户更多参与网络建设,提升业务稳定性。 本文从云网络概述,云网络复杂度以及典型案例来介绍云网络建设。 1.云网络概述 云网络概述主要分为云服务商基础设施网络架构和云产品两部分,让云上客户更加深入了解云网络,用好云网络。 1.1 云服务商网络架构 本节从业务建设角度来着重说明以下几个问题: 1)云服务商不同可用区云底层网络是完全独立吗? ,相见3.1 3.VPC之间网络互通建议采用云联网,保证网络维护简单,网络架构清晰。 image.png 3.2 混合云网络 混合云网络分为两个部分: 1)idc和云机房之间线路,主要线路分为专线和VPN。

    5.8K93发布于 2021-08-09
  • 来自专栏开元说说

    系列(九)——异地数据冷备建设

    2.3 数据库备份服务数据库备份服务拥有一套完整的数据备份和数据恢复解决方案,具备实时增量备份以及快速的数据恢复能力,同时具备异地能力。 异地数据冷备案例3.1 异地冷备方案以某在线商城为例,涉及数据产品为mysql,reids以及cos,结合云平台的能力,具体方案架构如下:图片方案要点说明:数据备份:基于数据恢复的rto时长,mysql

    10.4K164编辑于 2022-09-19
  • 来自专栏开元说说

    系列(八)——同城数据冷备建设

    为了让企业能更好用好云平台的数据安全能力,本文重点云平台数据备份冷备能力,以腾讯云为例,主要从以下两个维度介绍:同城数据冷备能解决企业什么问题,达到怎么样业务效果? 如下图所示:图片数据备份覆盖度,目前数据产品均有数据备份能力,常见例如mysql,redis,ckafka,es,pg等等2.2 同城冷备份方案同城数据冷备方案主要依赖于云平台能力备份能力,对现有业务架构没有任何改造 ,方案架构如下:图片该方案核心要点说明:数据备份:云侧数据库mysql和redis在控制台设置数据备份参数,数据备份存储在COS,具备地域级别,RPO依赖于数据库备份周期以及时间。 指标详细说明能力具备同地域(不同可用区)数据备份能力,不具备不同地域的能力。 3.演练能力建设,增加平时运维成本以及自动化工具开发功能。

    8.2K113编辑于 2022-09-15
  • 备知识总结:与备份区别、备技术、体系规划

    灾难恢复(Disaster Recovery)阶段定位:灾难发生后的系统重建与关系:现代系统集成恢复功能二、与备份的协同关系1. 功能互补性2. 典型故障应对案例1:数据库误删操作系统同步删除→需从备份恢复案例2:机房级火灾系统接管业务→备份用于数据追溯三、企业备体系规划策略1. 风险评估矩阵2. RTO/RPO指标选择金融行业:RPO<5分钟,RTO<30秒(中科热备同步复制技术)制造业:RPO<1小时,RTO<4小时(异步复制+本地备份)3. 应用层虚拟化技术:VMware Site Recovery Manager容器化方案:Kubernetes跨集群调度中科热备创新:混合云架构设计五、中科热备解决方案实践1. 政务云建设省级政务云平台:采用中科热备多云备方案满足等保2.0三级要求六、备体系演进趋势智能化监控:AI预测性维护(中科热备智能运维平台)绿色备:液冷技术降低PUE值量子安全:后量子加密技术集成零信任架构

    80010编辑于 2025-09-16
  • 来自专栏devops

    架构实战】多机房架构设计方案

    一、为什么需要多机房单机房部署存在诸多风险:硬件故障:服务器、交换机、存储设备故障电力中断:UPS电池耗尽、发电机故障网络故障:光纤被挖断、运营商故障自然灾害:火灾、水灾、地震等不可抗力人为失误:运维操作失误导致服务中断多机房的目标 :RTO(恢复时间目标):接近0RPO(恢复点目标):数据丢失接近0二、多机房架构模式1.主备模式(Active-Standby)展开代码语言:TXTAI代码解释主机房(Active)←同步复制→备机房 log.info("DNS切换完成:{}",targetDc);}}3.切换流程展开代码语言:TXTAI代码解释1.检测到主站点不可达2.自动/手动触发切换3.停止向主站点写入数据4.等待主站点数据同步完成5. 解决方案:强一致性场景使用同步复制最终一致性场景使用异步复制+补偿机制重要数据采用"写入确认"机制七、总结多机房是保障业务高可用的终极方案:架构选型:根据业务需求选择主备、双活或多活数据同步:根据数据特性选择同步方案流量调度 :DNS+应用层双重保障故障切换:自动化健康检查+快速切换实施建议:优先实现数据层的多机房部署核心系统采用双活架构建立完善的监控和告警体系定期进行故障切换演练思考题:你们系统目前的方案是什么?

    5900编辑于 2026-04-09
  • 来自专栏民工哥技术之路

    备知识总结:与备份区别、备技术、体系规划

    现在的系统都包含着灾难恢复的功能,所以本文的讨论除了包括方面的内容,还包括了 灾难恢复的部分内容。高性能、高可用平台架构的演变过程。 系统在企业中给与数据安全系数相当高的保障,但是系统倒是是什么,他们是什么意思?恐怕连正在使用备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释备份到底是什么。 不可少 那么建设了备份系统,是否就不需要备份系统? 不能替换备份 系统会完整地把生产系统的任何变化复制到端去,包括不想让它复制的工作,比如不小心把计费系统内的用户信息表删除了,同时端的 用户信息表也会被完整地删除。 如果是同步,那端同时就删除了;如果是异步,那端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份,来恢复被错误删除的信息。

    13.3K21发布于 2021-01-12
  • 来自专栏腾讯云中间件的专栏

    微服务高可用架构设计

    导语 相对于过去单体或 SOA 架构,建设微服务架构所依赖的组件发生了改变,因此分析与设计高可用架构方案的思路也随之改变,本文对微服务架构落地过程中的几种常见容高可用方案展开分析。 另一方面,微服务架构也离不开中心化的组件实现服务治理、应用部署、监控等功能,微服务场景下主备、多活等高可用方案的设计需要通盘考虑。 在分析复杂的架构前,我们首先应当明确问题的定义,拆解问题,分解子问题,从不同维度分开讨论才能获得一个清晰的结论。 切换策略:如南方城市整体故障,入口出做 DNS 切换南方用户访问 IP 至北方。 单元化 一般如果数据量过大,单纯使用数据库 Sharding 模式无法解决问题,可以考虑使用单元化架构。 部署单元设计:考虑设计,单元与数据库分片绑定,同城单元双活,异地部署备单元。

    2.2K71编辑于 2023-09-09
  • 来自专栏信息化漫谈

    云上架构设计与方案

    双活、备,能帮到我们! 一、单数据中心架构的隐患 单数据中心的常见架构如下图所示,如果在该数据中心在极端情况下,出现网络全阻、设备掉电全阻等情况,业务可能发生全阻。 四、两地三中心的应用双活架构架构实际是以上两种方式的结合。双活架构一般是发生是两个数据中心相邻距离不远的场景。如果对于金融级的客户,还会考虑异地的备。则采用以下的架构。 五、数据备级的方案 对于以上的方案,投入的代价较大,例如需要支付双活数据中心的高速通道费用、相同配置的云主机费用。 业内的实际方案较多,有基于硬件的备一体机,也有纯软件实现的方案。 1、例如下图,本地通过备一体机进行数据的压缩、加密、存储,同时在云端也进行一份备存储。 3、对于普通企业客户,可以选择数据级的备方案。

    5.8K10发布于 2020-03-10
  • 来自专栏开元说说

    系列(七)——混合云公网出口建设

    本文结合云平台公网能力,从网络平台角度来分析建设可行性。 入口流量通过F5或者api网关来承载流量,出口流量通过自建NAT集群来访问公网。 整体公网出口方案如下: image.png 2.1.1 云平台切换方案。 正常情况下,业务流量通过NAT访问公网,如上路绿色线条标识。 2.1.2 IDC切换方案 正常情况下,IDC业务流量通过NAT访问公网,如上路绿色线条标识。 5.方案实现较为复杂,不确定因素较多。 IDC公网出口方案 (推荐) 1.方案简单,更多依赖云平台能力 2.方案落地快捷。 3.人力成本低,不需要自建系统。

    4.1K124编辑于 2021-12-29
  • 来自专栏开元说说

    系列(四)——业务应用层建设

    例如,核心业务模块和非核心业务模块高度耦合,从资源成本上来考虑,实际上并不是所有业务均需要做建设,需要加入人力成本对业务进行改造;如果对于延时敏感业务,无法接受跨区延时,需要投入更多人力来进行架构和业务上改造 综上所述,本文从云平台视角出发阐述应用层业务建设,主要分为方案设计考虑纬度、复杂度以及云上客户案例三个方面。 1.应用概述 1.1 应用部署 应用是否满足跨地域/可用区部署? 1)业务完全能接受跨区延时,不同的可用区应用部署规模(1:1),各承载50%的业务流量; 2)业务并不能完全接受跨区延时,为了做业务做了部分妥协,两个可用区业务部署的规模(5:1),主要业务承载在主可用区 切换强依赖于调度系统以及配置系统稳定性。这里稳定性主要包括系统能力和性能;遇到大规模故障,大量信息配置变更请求调度系统和配置系统要能扛住洪峰,是保障这个方案的根基。 2.应用复杂度 计算应用层,主要考虑以下两个方面: 哪些节点执行任务。 这里要区分清楚哪些节点执行核心业务,这里会引入不同的复杂度。

    4.3K72发布于 2021-09-04
  • 如何配置YashanDB实现高可用架构

    在现代企业的信息系统中,数据库的高可用性与能力是保障业务连续性和数据安全的关键。实现高可用架构对于减少系统故障时间、保障数据一致性以及抵御各种灾难至关重要。 YashanDB作为一款高性能且具备丰富部署形态的数据库解决方案,提供了多种技术和机制来支持稳定、可靠的高可用架构。 本文将基于YashanDB的核心架构和功能,详细阐述如何有效配置系统以实现高可用及目标。 制定完善的备份恢复策略,结合全库备份、增量备份、归档备份及基于时间点的恢复,提高能力。定期监控实例状态和运行日志,利用故障诊断架构及时发现和修复潜在风险。 结论与展望随着业务对数据可靠性、连续性的诉求日益增长,构建稳定的高可用架构已成为数据库系统的核心竞争力。

    17410编辑于 2025-09-15
  • 来自专栏数通

    同城和异地的区别,你知道多少?

    单元化(Sharding) 是异地双活(及多活)架构中的重要设计。 多维度区别对比 特性维度 同城双活 异地双活 网络延迟 较低(通常≤5ms) 较高(通常≥50ms) 同步模式 同步复制为主(如MySQL半同步复制) 异步复制为主 数据一致性 强一致性或最终一致性 最终一致性 存储配置 通常1:1配置,基于实时同步 可能采用非对称配置,或利用纠删码等技术减少冗余 典型架构 共享存储或数据库主从模式 单元化架构(按用户/业务分片) 成本 专线成本较高,但存储配置可能更简单 异步复制带宽成本相对较低 ,但架构复杂度和改造成本高 主要优势 高可用、数据零丢失(RPO=0)、故障切换迅速 城市级、更好的用户体验(异地用户就近访问) 主要挑战 距离限制(同城)、脑裂风险、专线成本 数据延迟、一致性难度 2、等级要求:同城双活可应对机房级故障。若需防范城市级灾难(如地震、大规模停电),则需异地双活。 3、成本预算:同城双活专线成本较高,但架构相对简单。

    40710编辑于 2025-10-11
  • 来自专栏采云轩

    前端接口

    我细细细细分析。 原因就是接口挂了,拿不到数据了。那把数据储存起来就可以解决问题。 思考 存哪里? 第一时间反应浏览器本地存储,想起了四兄弟。 cookie localStorage sessionStorage indexDB 数据生命周期 服务器或者客户端都可以设置、有过期时间 一直存在 关闭页面就清空 一直存在 数据储存大小 4KB 5MB 5MB 动态,很大大于250MB 与服务器通信 每次都带在header中 不带 不带 不带 兼容性 都支持 都支持 都支持 IE不支持,其他主流都支持 考虑到需要存储的数据量,5MB 一定不够的,所以选择了 接口我们也是刚弄不久,有许多细节与不足,欢迎沟通交流。 接口本意是预防发生接口服务挂了的场景,我们不会很被动。原来是P0的故障,能被它降低为 P2、P3,甚至在某些场景下都不会有用户反馈。

    77910编辑于 2023-11-30
  • 来自专栏ICT售前新说

    知识知多少

    为什么要做? 你知道吗?自然灾害、设备故障、人为因素等都会造成业务中断。如今数字化时代,IT系统故障更会对公司业务造成难以估量的巨大经济损失。 1 数据统计 “2/5的公司在经历大灾难后再也不能恢复运作,另外1/3在2年内也接着倒闭。”---高德纳咨询公司 “93%的公司在遭受严重的数据丢失后5年内倒闭。” 体系介绍 1 数据中心 集团公司通过两地建立三个数据中心,通过双活、冷备等方式,实现两地三中心架构。 2 体系建设 系统类型 --- 策略 核心业务系统 --- 两地三活 关键平台系统 --- 同城双活 非关键系统 --- 异地冷备 3 技术方案 异地冷备 恢复能力 RTP≤1h RPO≤5min 演习要求 每年进行演练,所有核心业务与平台系统均要参演。 异地备恢复、同城双活切换、一键式自动化启停等恢复方式不断创新,要求演习规模逐年扩大和恢复效率逐年提升。 - End - ----

    1.8K20发布于 2021-04-30
  • 来自专栏ICT售前新说

    数据中心精讲(常见的建设模式)

    当前,市场上常见的模式可分为同城、异地、双活数据中心、两地三中心几种。 同城 同城是在同城或相近区域内(≤200KM)建立两个数据中心:一个为数据中心,负责日常生产运行;另一个为灾难备份中心,负责在灾难发生后的应用系统运行。 异地 异地主备中心之间的距离较远(>200KM)因此一般采用异步镜像,会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患,还能够防范战争、地震、水灾等风险。 异地备中心是指在异地的城市建立一个备份的备中心,用于双中心的数据备份,当双中心出现自然灾害等原因而发生故障时,异地备中心可以用备份数据进行业务的恢复。 ,所以称为“双活”和“多活”;后者是生产数据中心投入运行,备数据中心处在不工作状态,只有当灾难发生时,生产数据中心瘫痪,备中心才启动。

    3.3K20发布于 2021-11-30
  • 来自专栏开元说说

    系列(十)——数据热备能力建设【基础篇】

    异地明确数据热备能力,实时明确RPO指标接近于“零”。尤其是实时,对于RPO指标提升,为此需要企业投入更多的成本。 2)备实例,建议采用云平台的PAAS服务,更好的兼容DTS同步服务。2.2 平台热备方案2.2.1 数据库备方案目前数据库对于异地备份能力进行封装,来简化云上客户操作成本,提升RTO。 2.2.3 中间见实时备份方案ckafka云平台在数据同步已支持跨地域,但是对于ckafka版本有要求,为专业版本。 方案关键因素详细说明范围地域级别RPO/RTORPO几乎接近为零;RTO为小时级别,进行1:1业务部署,依赖于业务部署和数据恢复自动化能力。 3.演练能力建设,增加平时运维成本以及自动化工具开发功能。

    6K143编辑于 2022-09-26
领券