首页 > 其他分享 >同城多机房部署架构

同城多机房部署架构

时间:2024-10-11 14:21:55浏览次数:1  
标签:架构 同城 机房 往返 容灾 微秒 AZ 光纤 延迟

为满足用户对服务持续性和响应速度的高要求,很多企业采用同城多机房部署架构。该架构通过在同一城市内的多个数据中心部署业务,提升系统的容灾能力和性能。

容灾能力

  • 故障隔离:当一个机房发生故障时,其他机房可继续提供服务。
  • 数据冗余:数据在多个机房间同步,防止数据丢失。

降低延迟

  • 地理优势:同城机房间距离近,网络延迟低。
  • 用户体验:提高本地用户的访问速度。

负载均衡

  • 资源优化:根据机房负载情况,动态分配请求。
  • 弹性扩展:快速应对流量峰值,提升系统弹性。

AZ 可用区

在多机房部署架构中,经常听到多AZ部署,这里的AZ是 Availability Zone(可用区)的缩写。

可用区(Availability Zone,简称AZ)是指在同一地理区域内,具备独立电力、网络和冷却系统的物理数据中心。每个可用区都是一个逻辑隔离的区域,多个可用区之间通过高速网络互联。

可用区的特点

  • 物理隔离:避免单点故障的影响。
  • 高速连接:低延迟的网络连接,支持数据同步和负载均衡。
  • 独立性:独立的基础设施,提升容灾能力。

AZ间距离

在多AZ部署的情况下,对可用区(AZ)之间的距离有一定的要求,以确保在平衡高可用性、低延迟和容灾能力时达到最佳效果。

1、灾害物理隔离要求

可用区之间的距离足够远,以确保一个区域内的自然灾害或系统故障不会影响其他区域。这通常意味着它们会分布在不同的建筑或城市,但在同一地理区域内(如同一国家或省份)。

2、网络延迟要求

可用区之间的距离不能过远,以避免过高的网络延迟,因为应用需要在这些区域之间快速同步数据或协调服务。

云服务提供商设计的AZ之间的网络通常具有低延迟和高带宽,以支持这种数据同步。

通常,AZ之间的延迟通常需要保持在单毫秒(ms)级别。

实际距离

在实际的云服务中,不同云服务提供商对AZ之间的物理距离有不同的标准,在数十公里到几百公里之间。

一般情况下,30公里到50公里的范围比较常见,因为它在确保容灾能力的同时,也能提供低延迟的网络连接。这种距离足够应对大多数灾害(如电力中断、洪水等),同时保持了区域内通信的高效性。

更大距离的部署

如果需要更大规模的容灾(如地震、台风等区域性灾害),则通常会考虑跨地域(Region)的部署。这意味着数据中心可能相隔数百甚至上千公里,但这会增加延迟,因此通常用于灾备(Disaster Recovery)场景,而不是日常的多可用区部署。

延迟计算

两个AZ之间的延迟主要由:光在光纤中的传播速度和中间网络设备(如路由器、交换机等)处理时间组成。

可以通过以下步骤计算两个AZ之间的光纤传输延迟。

1、光纤中的传播耗时

光在光纤中的传播速度约为光速的2/3。光速在真空中的速度约为300,000公里/秒,因此光在光纤中的传播速度为:200,000公里/秒。

光纤中的传播延迟可以通过以下公式计算:

传播延迟(秒)= \frac{距离(公里)}{光纤中的传播速度(公里/秒)} 

30公里的光纤耗时

传播延迟(秒)= \frac{30}{200000} ≈  0.00015秒 = 150微秒 

50公里的光纤耗时:

传播延迟(秒)= \frac{50}{200000} ≈  0.00025秒 = 250微秒

2、考虑网络设备的处理延迟

在实际网络中,除了光纤传播延迟外,还有一些额外的延迟来自中间的网络设备(如路由器和交换机)的处理时间。虽然现代设备的延迟通常很小,但这些延迟可能加在一起使总延迟增加几个微秒。

通常,我们可以假设每次路由和交换的延迟在几微秒到十几微秒之间。

如果两个AZ之间的网络相对简单,中间没有很多节点,处理延迟不会显著影响总延迟。

3、计算延迟

在网络通信中,延迟通常指的是往返延迟(Round Trip Time, RTT),即数据从源点发送到目的地,再从目的地返回源点的总时间。

假设网络设备的处理时间(10微秒),往返通讯经过两次网络设备,两倍距离。所以处理延迟也乘以 2。

30公里的总往返延迟

总往返延迟 ≈ (150×2)微秒+(10×2)微秒=320微秒=0.32毫秒

50公里的总往返延迟

总往返延迟 ≈ (250×2)微秒+(10×2)微秒=520微秒=0.52毫秒

考虑往返时间的情况下,30到50公里两个AZ之间的光纤传输往返延迟大约在0.32毫秒到0.52毫秒之间。这是理论值,实际情况可能会因为网络复杂性和其他因素略有不同。

标签:架构,同城,机房,往返,容灾,微秒,AZ,光纤,延迟
From: https://www.cnblogs.com/ghj1976/p/18458292/tong-cheng-duo-ji-fang-bu-shu-jia-gou

相关文章

  • 软件架构风格全解析:从单体架构到微服务的演进
    1.单体架构(MonolithicArchitecture)1.1概述单体架构是一种最传统的软件架构风格,所有功能模块都被打包成一个独立的应用程序。应用中的所有业务逻辑、数据库访问、用户界面和后台处理都在一个项目中完成。1.2特点紧密耦合:系统中的所有模块是紧密耦合的,通常在一个代码......
  • SaaS架构:多租户系统架构设计
    什么是多租户?多租户是SaaS领域的特有产物,在SaaS服务中,租户是指使用SaaS系统的客户,租户不同于用户,例如,B端SaaS产品,用户可能是某个组织下的员工,但整个企业组织是SaaS系统的租户。多租户技术是一种软件架构技术,可以实现多个租户共享系统实例,并且租户间能够实现数据与行为的隔离。......
  • 在微服务架构中实现数据库迁移的最佳实践和挑战有哪些?
    在微服务架构中实现数据库迁移的最佳实践和挑战有哪些?在微服务架构中实现数据库迁移的最佳实践和挑战如下:最佳实践制定详细的数据迁移计划:根据业务需求和时间安排,制定详细的数据迁移计划,确保每个步骤都有明确的目标和时间表。采用事件驱动架构:通过Kafka等消息队列实现服务间......
  • 模拟一个微服务架构项目来学习包括Nacos、EMQX、GateWay、RabbitMQ、Canal、Mybatis-P
    前言介绍下最近做的项目:为什么做这个项目?项目的核心用户目标是谁?面向新能源电车用户给目标用户提供了什么价值?方便快捷充电服务团队的作用?需求分析,概要设计,详细设计,开发,测试,部署,上线我的作用?1-2两个核心业务详细设计(业务流程,接口入参,接口出参,表结......
  • 五十、架构设计经验与技巧(架构设计基本原则)
    架构设计的基本原则是指导架构师在设计和实施系统时的重要参考。这些原则不仅影响系统的质量、可维护性和可扩展性,也直接影响到项目的成功与否。以下是几大基本原则及其在实践中的应用:1.可扩展性(Scalability)定义:系统在负载增加时,能够通过增加资源(如服务器、数据库等)来保......
  • 中大型企业网络架构和建设方案
    1.需求分析(1)用户需求:员工访问:支持内部员工通过有线和无线网络访问企业资源。远程访问:支持远程办公员工通过VPN安全访问企业内部资源。合作伙伴和客户访问:允许外部合作伙伴和客户通过受控渠道访问特定资源。(2)业务需求:核心业务应用:支持ERP、CRM等关键业务系统的高可用......
  • 基于 Nginx 的大型互联网集群架构与实战方案
    1.Nginx负载均衡基础配置首先,搭建一个基础的Nginx负载均衡器,用于将流量分发到多个后端服务器上。步骤1.1:安装Nginx在每台要作为负载均衡器的服务器上,安装Nginx。可以使用包管理工具进行安装,例如在Ubuntu上执行以下命令:sudoaptupdatesudoaptinstallnginx步骤1.......
  • 一文搞懂SaaS业务架构:价值流、业务能力、业务流程、业务对象、组织架构
    1目标与步骤2价值流分析2.1从价值主张到价值流2.2价值流的概念2.2价值流如何识别?2.3价值流阶段如何识别?3业务流程3.1业务流程的概念3.2端到端流程3.3职能流程3.4示例:零售企业的业务流程4业务能力4.1业务能力的概念4.2业务能力的构成4.3业务流程与业......
  • 百度公共IM系统的Andriod端IM SDK组件架构设计与技术实现
    本文由百度技术团队分享,引用自百度Geek说,原题“百度AndroidIMSDK组件能力建设及应用”,本文进行了排版和内容优化。1、引言移动互联网时代,随着社交媒体、移动支付、线上购物等行业的快速发展,对即时通讯功能的需求不断增加。对于各APP而言,接入IMSDK(即时通讯软件开发工具包)能......
  • 排队免单系统源码架构分析
    一、系统概述排队免单系统是一种创新的营销手段,通过用户的消费行为顺序来实现免单奖励。该系统的核心在于设立一个免单池,通常从每笔订单中划拨一定比例(如40%)的资金进入此池,用于后续用户的免单激励。用户下单后,其订单会被加入到一个排队系统中,根据预设的算法(如时间顺序、消费金额......