展开

关键词

异地架构

异地的代价: 系统复杂度会有质的变化。 成本大大增加。 架构模式 1. 同城异区 部署在同一个城市不同区的机房,用专用网络连接。 这就出事儿了,所以这类数据不会做跨城异地,只能用同城异区架构,因为同城的网络环境要好很多,可以搭建多条互联通道,成本也不会太高。 跨城异地设计技巧 1. 保证核心业务的异地 思维误区:要保证所有业务都能异地。 只保证绝大部分用户的异地 思维误区:要保证业务 100% 可用。 物理规律决定了异地无法保证100%的业务可用。 内容整理自《从0开始学架构

2.1K21

谈谈异地架构

应用场景 顾名思义,异地架构的关键点就是异地、,其中异地就是指地理位置上不同的地方,类似于“不要把鸡蛋都放在同一篮子里”;就是指不同地理位置上的系统都能够提供业务服务,这里的“”是活动 单纯从异地的描述来看,异地很强大,能够保证在灾难的情况下业务都不受影响。那是不是意味着不管什么业务,我们都要去实现异地架构呢? 其实不然,因为实现异地架构不是没有代价的,相反其代价很高,具体表现为: 系统复杂度会发生质的变化,需要设计复杂的异地架构架构模式 根据地理位置上的距离来划分,异地架构可以分为同城异区、跨城异地、跨国异地。接下来我详细解释一下每一种架构的细节与优缺点。 基于这个分析,跨城异地架构设计复杂度最高的一种,接下来将介绍跨城异地架构设计的一些技巧 技巧1:保证核心业务的异地 “异地”是为了保证业务的高可用,但很多架构师在考虑这个“业务”时

2.4K41
  • 广告
    关闭

    腾讯云服务器买赠活动

    腾讯云服务器买赠活动,低至72元1年,买就送,最长续3个月,买2核送4核、买4核送8核

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    同城双与异地架构分析

    服务是高可用架构重要实施手段,本文介绍了一些业界常用的手段例如同城双、两地三中心、异地架构设计方案并详述了各种方案的优缺点。 1、场景 架构的关键点就是指不同地理位置上的系统都能够提供业务服务,这里的“”是指实时提供服务的意思。 单纯从描述来看很强大,能够保证在灾难的情况下业务都不受影响,是不是意味着不管什么业务,我们都要去实现架构呢? 其实不是,实现架构都要付出一定的代价,具体表现为: 不同方案实现复杂度不一样,随着业务规模和容灾级别的提升,方案会给业务系统设计带来更大复杂度。 四、异地 异地指分布在异地的多个站点同时对外提供服务的业务场景。异地是高可用架构设计的一种,与传统的灾备设计的最主要区别在于“”,即所有站点都是同时在对外提供服务的。

    3.8K50

    机房架构,究竟怎么玩?

    机房架构,什么是理想状态下的“同机房连接”? ? 该机房架构,并没有做到100%的“同机房连接”,通常称作伪机房架构。 伪机房架构,有“主机房”和“从机房”的差别。 伪机房架构,是一个实践性,落地性很强的架构,它对原有架构体系的冲击非常小,和单机房架构相比,仅仅是: (1)跨机房主从同步数据,会10毫秒延时; 画外音:主从同步数据,本来就会有延时。 (2)跨机房写,会10毫秒延时; 小结: (1)理想机房架构,是纯粹的“同机房连接”,仅有异步数据同步会跨机房; (2)理想机房架构,会有较严重数据一致性问题,仅适用于具备数据聚集效应的业务场景 ,例如:滴滴,快狗打车; (3)伪机房架构,思路是“最小化跨机房连接”,机房区分主次,落地性强,对原有架构冲击较小,强烈推荐; 临时性机房架构,是机房迁移过程中的一个过渡状态,机房迁移步骤又该如何

    77511

    从 单体架构 到 异地

    异地活到底是什么?为什么需要异地?它到底解决了什么问题?究竟是怎么解决的? ---- 文章目录 系统可用性 单机架构 主从复制 不可抗力 同城灾备 同城双 两地三中心 异地双 异地 系统可用性 让我们从最基础的开始往上垒。 单机架构 早期发展的架构模型,如果你的业务量比较少的话可以用这个。客户端请求进来,业务层读写数据库,返回结果。 不要看不上这个架构,我个人觉得目前这个架构在跨界领域还是应用面比较广的。 这种方案我们把它叫做「同城双」。 ---- 两地三中心 我们的架构随着风险等级的提升在不断的升级,现在也该到了可接受的最高的风险等级了吧:天灾人祸。 == ---- 异地 理解了异地双,那「异地」顾名思义,就是在异地双的基础上,部署多个机房即可。

    12930

    混合云的架构指南

    作者 | 董晓聪 吕亚霖 策划 | 褚杏娟 在之前的《如何正确选择多云架构?》一文中介绍了混合云(广义的多云)的诸多架构以及各自的优势,本篇会重点来介绍下混合云下的架构。 背 景 企业选择混合云的技术诉求中,主要因素还是稳定性和成本 & 服务,而对这两点的极致追求就是架构。 稳定性 业务探索阶段追求效率,技术上一般会选择单云单架构。 但是,更彻底的方案还是不同云各自进行服务等量部署,做到真正的,随时可以做到流量和容量的调度。 挑 战 架构的优势很明显,但背后面临的挑战也是巨大的。 编后语 一路走来,笔者对作业帮混合云架构的建设感受良多,其不单单是容器集群的管理和流量调度,更是一整套贯穿资源和应用的企业架构整体解决方案。 上述为作业帮混合云架构的综述,后续文章会逐渐为大家介绍架构中 IaaS、PaaS、SaaS 的技术细节以及迁移新云的 SOP,请大家持续关注。

    10230

    分布式系统架构-----异地架构

    分布式系统架构-----异地架构 背景 最近公司在搞异地,特来写篇文章来学习和回顾一下。 异地看字面意思 :不通的地方部署服务。 这些自然灾害我们是不可避免的所以我们得从架构层面解决这种突发问题。 异地架构 1. 什么是异地架构? 异地:不同的地理位置,:不同的地理位置的服务都能独立提供服务。 异地的目的也就是容灾,容灾的话我们也可以理解为某个地方服务出现了灾难性故障,而服务仍然能正常提供服务。 2. 系统性能,因为异地活会部署在不同的城市,所以距离就会带来延迟(距离越远,耗时越久)。 3. 常用的几种方案 同城异区 同城异区指的是将业务部署在同一个城市不同区的多个机房。 应用 在背景也讲了我们公司也做了异地的方式数据跨城异区。一个集群部署在广州南沙,一个部署在广东佛山。

    11410

    详解:淘宝高可用异地架构

    p=299 导读:异地,作为一种高可用部署架构,成为大中型互联网公司的选择。像大家熟知的大型互联网公司,如阿里、腾讯、百度、网易、新浪等等都已经完成了异地的技术重构。 这种架构下,读写分离是很好的,单写读,减少冲突又提高了效率。 实际上,异地双和异地已经很像了,双的结构更为简单,所以在程序架构上不用做过多的考虑,只需要做传统的限流,failover 等操作即可。 但其实双只是一个临时的步骤,最终的目的是切换到。 按照业务进行单元切分,已经需要对代码和架构进行彻底的改造了(可能这也是为什么阿里要先从双再切到,历时3年)。比如,业务拆分,依赖拆分,网状改星状,分布式事务,缓存失效等。 /eleme-arch 《阿里异地与同城双架构演进》 https://www.sohu.com/a/158859741_444159 《阿里云 数据库异地解决方案》 https://help.aliyun.com

    59511

    机房机房平滑迁移架构方案全集(上+中+下)

    放假前三天,写了三篇长文,关于机房机房平滑迁移架构与方案的。可能是临近放假,又亦或疫情的影响,阅读都比较低,现将“上中下”汇总成全集,一窥全貌,欢迎错过的同学补课。 上篇 《机房平滑迁移架构方案目标》,主要包含三块内容: (1)单机房架构的核心是什么? (2)机房迁移架构方案的设计目标是什么? (3)为什么说,想要平滑的实施机房迁移,临时性的机房架构不可避免? 中篇 《机房,常见架构实践》,主要包含三块内容: (1)什么是理想机房架构? (2)理想机房架构,存在什么问题,适用于什么业务场景? (3)什么是伪机房架构?适用于什么业务场景? 希望通过这三篇,大家能够对机房架构机房平滑迁移架构与方案,有一个初步的了解。 任何脱离业务的架构设计都是耍流氓。

    79441

    云原生环境下对“架构的思考

    当公司规模较小时,一般情况下公司的架构会像下图所示。 当公司的业务达到了一定的规模,一般情况都会再选一个云服务商形成“多云”来保证系统的稳定性、高可用。有幸参与过某公司的双云方案的落地,这里聊聊这种多云的方案的一些思考。 为什么重要? 特别当 B 站故障后,各路文章出来解读,如何实施(很多的文章当个乐子看即可)。像这种比较基础的服务故障,往往恢复时间都是不确定的,确实是解决问题的有效手段,能大大提高我们系统的容灾能力。 是高可用架构设计的保障,根据等级的要求不同,还有同城双,异地双,两地三中心,三地五中心等。对的要求越高,投入的资源也就会越高。这里就不再详细讲述这些名字背后的技术细节了。 结论 其实很多的公司的最终都因为各种原因沦为了“伪”。

    35330

    荔枝FM架构师刘耀华:异地IDC机房架构

    机房架构存在的原因 ? 单机房一旦死机,断电、维护根本无法挽回整个数据,想离线读取等都不行。当一个机房不可用,所有的业务就都不可用。 大陆的网络和国外的网络有一定的隔离性,如果没有做机房的连通性,数据的传输和实时性就会有问题。 ? 跨机房的作用是为了备份,一个机房的数据放在另一个机房是异地。 而数据版本,类似于乐观锁,导致其他人和我方数据冲突的机会并不是那么,只要在提交的时候发现版本不一样,更新一下,汇总数据就可以了。 这让每一步都胆战心惊,错一个字母或者一个空格都可能会出现不可预估的后果。 ? 架构师相当于产品经理,用户相当于程序员,产品为用户服务。 分享人:刘耀华,荔枝FM架构师,负责荔枝FM服务端系统架构设计与实施,以及数据中心异地方案的设计。对服务端系统架构进行分布式集群、高可用、负载均衡等有多年经验与心得。

    1.1K61

    本地读写的数据存储架构设计要义

    本地读写示例 本地读-本地写的数据存储架构是最难实现的数据模式之一。这一模式也常被称为“双”或者“主”,对于不同行业大容量低延迟的事务类应用而言,这是一种必备的能力。 也有一些企业选择自己实现定制化的复制方案来达成的目标,对于强烈依赖低延迟的用户尤其如此。忽略方案的差异性,人们需要对一些通用的风险与权衡进行仔细考量。 在这样的情况下,值得评估一下的数据存储方案是否符合用户场景的需要。 本地读取-全局写入的方式提供了可用性和一致性之间的平衡,是一种可选的方案。 一旦决定采用的数据存储方案,并且接纳了最终一致性的理念,接下来需要重点考虑的就是采用合适的技术,以缓解和减轻一致性问题所产生的影响。 采用事件流进行复制 在架构下,数据的异步复制通常采用事件流的方式实现。好处如下: 写入操作的顺序将得以保留。这对很多用户场景来说是必须的。

    38221

    真·异地架构怎么实现?使用PolarDB-X!

    异地是近几年比较热门的一种系统架构。一般来讲,要做到异地,是一个系统性的事情,需要接入层、应用层、数据层都做一些事情。 同时有一些场合我们可能会把两地三中心等容灾架构也算作了异地(单纯的应用层),本文所讲的异地,是指所有数据中心的数据库都会承担写流量的"真·异地"。 今天我们这篇文章重点来说一下,对于一个分布式数据库,在异地架构中,起到了一个什么样的角色;对于其中的问题,解法是什么。 因此我们依然要遵循异地架构下应用本身需要做流量的分区的原则,确保数据库的请求不会高频率的飘来飘去。 总结 异地,是一个非常吸引人的架构。真正的实现异地,对系统的整体设计是一个很大的挑战,涉及的领域方方面面。选择合适的数据库层方案,能让整个过程事半功倍。

    23730

    架构设计 7-高可用架构设计之异地

    代价很高 系统复杂度会发生质的变化,需要设计复杂的异地架构。 成本会上升,毕竟要多在一个或者多个机房搭建独立的一套业务系统。 跨城异地 跨城异地距离较远带来的网络传输延迟问题,给异地架构设计带来了复杂性,如果要做到真正意义上的,业务系统需要考虑部署在不同地点的两个机房,在数据短时间不一致的情况下,还能够正常提供业务。 只保证绝大部分用户的异地 核心思想:采用多种手段,保证绝大部分用户的核心业务异地! 可恢复性:可恢复性指数据丢失后,是否可以通过某种手段进行恢复,如果数据可以恢复,至少说明对业务的影响不会那么大,这样可以相应地降低异地架构设计的复杂度。 简单的说,异地,是富家子的操作,追求最后的 0.00001 的收益。大厂可以搞搞,小厂如果不是对可用性有特别特别高的需求还是算了吧。 reference 从 0 开始学架构

    8420

    京东JDHBase异地实践

    为了保障业务稳定不间断运行,我们构建了JDHBase集群的异地系统。主要介绍在我们在异地系统的实践。 JDHBase异地架构 JDHBase服务端与客户端交互主要包含三个组件:Client、JDHBase集群、Fox Manager。 我们对可靠性要求比较高的业务做了异地备份。 ? Active Cluster:正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster,同时保证数据不丢失,但是会有延迟。 实际生产中,我们根据两个建群间的Replication,构建了集群间的Replication拓扑,使得集群互为主备。 一个集群上会承载多个业务,不同的业务的备份也会散落在不同的集群上,形成集群间的拓扑结构。 ? 3 Client ?

    70841

    物联网模式下的数据中心架构认识与实践

    大家好,我是架构君,一个会写代码吟诗的架构师。今天说一说物联网模式下的数据中心架构认识与实践[通俗易懂],希望能够帮助大家进步!!!      如何保证服务的持续可用性,是每个互联网架构师一直坚持不懈追求的目标。在不同行业、不同场景下都有不同的解决方案。今天就与大家聊聊特来电在物联网模式下的数据中心架构上的认识和实践。      基于此我们规划设计了特来电云平台的系统架构。总体思路是分为三步走:      第一步:中间件、技术平台要进行适应性改造,以支持多数据中心、Set化的架构。 第三步:架设多个数据中心、多个服务单元,按照地区对流量进行切割,真正实施架构。核心思路: 建立数据中心,每个数据中心多个服务单元。 至此,我们终于在架构上迈出了最坚实的一步。这标志着,我们不仅仅具备了完善了技术架构,而且这个架构是可以复制的、的,终于有可能把整个系统可用性做到100%。

    22750

    MySQL机房的初步设想

    这是学习笔记的第 2043 篇文章 今天和同事聊了下两地三中心的一些理解,后续会在MySQL和Redis方向的高可用架构方案上做一些东西。这算是一个讨论的开始吧。 首先需要明确下概念的边界,我们初步的共识是:同城双,异地灾备。 而要实现同城双,在整个方案中则是重中之重,同时要实现双,必然需要和业务架构结合起来,而找到一个适中的平衡点。 我们可以在行业里看到很多的伪双的设计,从设计上来说也没有问题,但是会存在一些局限性。 我们主要从数据延迟和数据冲突来展开,如下是一个IDC架构的设计方案,可以把两个不同的业务整合起来,做到schema级别的隔离,然后业务侧可以实现写。 ?

    82840

    TBase-手工创建数据

    今天这篇文章主要是实操,给大家演示如何利用SQL语句手工创建数据。 实验描述: 利用数据同步mc.public.test_repl到postgres.public.test_repl的数据。 x.relname = 't1' and c.relnamespace = n.oid) and (indisunique = true or indisprimary = true )) 原因: --数据使用的是逻辑复制原理

    16430

    饿了么的异地架构设计是什么样的?

    读者能够从中了解到做异地的大方向,为实现自己的异地,或者是容灾备份提供参考。 背景:为什么要做异地? 所有有些公司的方案,会选择同城机房,把同城的几个机房当成一个机房部署,可以在不影响服务架构的情况下扩展出多个机房,不失为一个快速见效的方法。 与同城的方案不同,异地的方案会限制机房间的相互调用,需要定义清晰的服务边界,减少相互依赖,让每个机房都成为独立的单元,不依赖于其他机房。 设计:异地的实现思路和方法 我们的异地方案的,有几条基本原则,整个方案都是这些原则的自然推导。 进过反复讨论,我们的架构通过遵循以下几条基本原则,来满足这两个核心特性: ? 业务内聚:单个订单的旅单过程,要在一个机房中完成,不允许跨机房调用。

    77941

    做容灾,双、同城、异地、多云,到底应该怎么选?

    准确点,就是物理距离上的时延问题,这个无论是双,还是同城、异地,都绕不开的痛苦问题。 讲到这里,我想就不用讲了,时延这个问题解决不了,就是扯淡,至于同城和异地,我想看明白的读者,也知道怎么选择了,其实一样,还是取决于时延。 我们可以得出的几个结论: 不管怎么选择容灾方案,我们自己的业务系统,从自身架构上,一定要支持单元化,一定要支持数据同步才行,如果这都不支持,讲双,就是特么的扯淡。 一个合理的建设节奏应该是,同城双—异地双—两地三中心(同城双+异地),因为你要解决的问题的复杂度和难度也是在逐步上升的,不可能一蹴而就。 现实情况,比我写的要复杂的,推荐大家看两个成功案例,一个是毕玄的异地数据中心,一个是饿了么异地,几个关键字google一下就有了,里面涉及到的场景化的细节对大家理解这件事情的复杂度会有更帮助

    1.8K40

    相关产品

    • 数据传输服务

      数据传输服务

      腾讯云数据传输服务(DTS)支持 多种关系型数据库迁移及 NoSQL 数据库迁移,可帮助用户在业务不停服的前提下轻松完成数据库迁移上云,利用实时同步通道轻松构建高可用的数据库容灾架构,通过数据订阅来满足商业数据挖掘、业务异步解耦等场景需求。 

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券