aws是bgp机房吗，云服务器ECS是什么？
（转自阿里云，自己一直在用阿里云产品，非常稳定，侵删）
云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备，让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器，实现计算资源的即开即用和弹性伸缩。阿里云ECS持续提供创新型服务器，解决多种业务需求，助力您的业务发展。
为什么选择云服务器ECS
选择云服务器ECS，您可以轻松构建具有以下优势的计算资源：
无需自建机房，无需采购以及配置硬件设施。分钟级交付，快速部署，缩短应用上线周期。快速接入部署在全球范围内的数据中心和BGP机房。成本透明，按需使用，支持根据业务波动随时扩展和释放资源。提供GPU和FPGA等异构计算服务器、弹性裸金属服务器以及通用的x86架构服务器。支持通过内网访问其他阿里云服务，形成丰富的行业解决方案，降低公网流量成本。提供虚拟防火墙、角色权限控制、内网隔离、防病毒攻击及流量监控等多重安全方案。提供性能监控框架和主动运维体系。提供行业通用标准API，提高易用性和适用性。更多选择理由，请参见云服务器ECS的优势和应用场景。
产品架构
云服务器ECS主要包含以下功能组件：
实例：等同于一台虚拟服务器，内含CPU、内存、操作系统、网络配置、磁盘等基础的计算组件。实例的计算性能、内存性能和适用业务场景由实例规格决定，其具体性能指标包括实例vCPU核数、内存大小、网络性能等。镜像：提供实例的操作系统、初始化应用数据及预装的软件。操作系统支持多种Linux发行版和多种Windows Server版本。块存储：块设备类型产品，具备高性能和低时延的特性。提供基于分布式存储架构的云盘、共享块存储（公测中）以及基于物理机本地存储的本地盘。快照：某一时间点一块云盘或共享块存储的数据状态文件。常用于数据备份、数据恢复和制作自定义镜像等。安全组：由同一地域内具有相同保护需求并相互信任的实例组成，是一种虚拟防火墙，用于设置实例的网络访问控制。网络：专有网络VPC：逻辑上彻底隔离的云上私有网络。您可以自行分配私网IP地址范围、配置路由表和网关等。经典网络：所有经典网络类型实例都建立在一个共用的基础网络上。由阿里云统一规划和管理网络配置。更多功能组件详情，请参见云服务器ECS产品详情页。
以下为云服务器ECS的产品组件架构图，图中涉及的功能组件的详细介绍请参见相应的帮助文档。产品定价
云服务器ECS支持预付费、按量付费、预留实例券（邀测中）、抢占式实例等多种账单计算模式。更多详情，请参见计费概述和云产品定价页。
管理工具
通过注册阿里云账号，您可以在任何地域下，通过阿里云提供的以下途径创建、使用或者释放云服务器ECS：
ECS管理控制台：具有交互式操作的Web服务页面。关于管理控制台的操作，请参见常用操作导航。ECS API：支持GET和POST请求的RPC风格API。关于API说明，请参见API参考。以下为调用云服务器ECS API的常用开发者工具：命令行工具CLI：基于阿里云API建立的灵活且易于扩展的管理工具。您可基于命令行工具封装阿里云的原生API，扩展出您需要的功能。OpenAPI Explorer：提供快速检索接口、在线调用API和动态生成SDK示例代码等服务。阿里云SDK：提供Java、Python、PHP等多种编程语言的SDK。资源编排（Resource Orchestration Service）：通过创建一个描述您所需的所有阿里云资源的模板，然后资源编排将根据模板，自动创建和配置资源。Terraform：能够通过配置文件在阿里云以及其他支持Terraform的云商平台调用计算资源，并对其进行版本控制的开源工具。阿里云App：移动端类型的管理工具。关于如何使用阿里云App，请参见App用户指南。Alibaba Cloud Toolkit：阿里云针对IDE平台为开发者提供的一款插件，用于帮助您高效开发并部署适合在云端运行的应用。部署建议
您可以从以下维度考虑如何启动并使用云服务器ECS：
地域和可用区地域指阿里云的数据中心，地域和可用区决定了ECS实例所在的物理位置。一旦成功创建实例后，其元数据（仅专有网络VPC类型ECS实例支持获取元数据）将确定下来，并无法更换地域。您可以从用户地理位置、阿里云产品发布情况、应用可用性、以及是否需要内网通信等因素选择地域和可用区。例如，如果您同时需要通过阿里云内网使用云数据库RDS，RDS实例和ECS实例必须处于同一地域中。更多详情，请参见地域和可用区。
高可用性为保证业务处理的正确性和服务不中断，建议您通过快照实现数据备份，通过跨可用区、部署集、负载均衡SLB等实现应用容灾。
网络规划阿里云推荐您使用专有网络VPC，可自行规划私网IP，全面支持新功能和新型实例规格。此外，专有网络VPC支持多业务系统隔离和多地域部署系统的使用场景。
安全方案您可以使用云服务器ECS的安全组，控制ECS实例的出入网访问策略以及端口监听状态。对于部署在云服务器ECS上的应用，阿里云为您提供了免费的DDoS基础防护，此外您还可以使用阿里云云盾，例如：通过DDoS高防IP保障源站的稳定可靠。更多详情，请参见DDoS高防IP文档。通过安骑士保障云服务器ECS的安全。更多详情，请参见安骑士文档。学习路径
您可以通过ECS学习路径图快速了解产品，由浅入深地学习运维云服务器ECS。
相关服务
使用云服务器ECS的同时，您还可以选择以下阿里云服务：
根据业务需求和策略的变化，使用弹性伸缩（Auto Scaling）自动调整云服务器ECS的数量。使用容器服务（Container Service）在一组云服务器ECS上通过Docker容器管理应用生命周期。通过负载均衡（Server Load Balancer）对多台云服务器ECS实现流量分发的负载均衡目的。通过云监控（CloudMonitor）制定实例、系统盘和公网带宽等的监控方案。在同一阿里云地域下，采用关系型云数据库（Relational Database Service）作为云服务器ECS的数据库应用是典型的业务访问架构，可极大降低网络延时和公网访问费用，并实现云数据库RDS的最佳性能。云数据库RDS支持多种数据库引擎，包括MySQL、SQL Server、PostgreSQL、PPAS和MariaDB。在云市场获取由第三方服务商提供的基础软件、企业软件、网站建设、代运维、云安全、数据及API、解决方案等相关的各类软件和服务。您也可以成为云市场服务供应商，提供软件应用及服务。更多详情，请参见云市场文档。如何实现分布式系统的高可用性？
职场新兵的指南：关于高可用系统建设的一些思考
在参与公司几个多数据中心项目的容灾架构设计后，积累了一些高可用和多数据中心容灾的一些思考，希望总结和分享出来和大家一起学习。可用性衡量指标我们做软件系统核心是服务于业务，构建高可用系统本质也是为了让业务的服务质量提供，因为在构建高可用系统之前，我们需要根据业务特性确认我们系统需要怎么样的高可用级别，也就是需要一个指标度量我们系统的可用性。可用性度量的指标有以下几个：MTBF（Mean Time Between Failure），平均故障间隔，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。MTTR（Mean Time To Repair），故障的平均恢复时间，也叫平均故障时间。这个值越小，故障对于用户的影响越小。但 MTBF 和 MTTR 这两个指标中的故障不仅仅是IT系统宕机故障，也包括了性能问题和人为的错误。甚至USITS一项关于大型互联网服务的研究发现，运维配置错误是导致服务中断的首要原因，而硬件故障（服务器或网络）仅导致了 10-25% 的服务中断，但如何避免人为错误并不在今天的讨论当中。所以，在针对数据中心的容灾，我们可能用到更多地是RTO和RPO这两个指标：RTO(Recovery Time Object)，恢复时间目标，RTO是反映数据中心业务恢复的及时性指标。RPO(Recovery Point Objective)，复原点目标，指数据中心能容忍的最大数据丢失量，是指当业务恢复后，恢复得来的数据所对应时间点，RPO取决于数据中心数据恢复到怎样的更新程度，反映数据中心恢复数据完整性的指标。一般我们对现有系统做可用性改造时，可以先看看现有系统的基准值是多少，然后根据业务目标，确定要提升到多少来改善。高可用改造层级在和业务确定好可用指标后，接下来就需要对系统做高可用改造，从容灾级别可以分为三个层面：基于Region(地理区域)的高可用架构同城多Zone的高可用架构单Zone多实例的的高可用架构注：这里Region表示地区，一般是指行政单元比如地级市，Zone表示可用区，指电力和网络相互独立的物理区域从软件架构的角度来看，针对可用性改造可以分为四个部分：DNS服务负载均衡(LB)应用服务数据库/中间件其中，DNS服务和负载均衡都是无状态的，数据库和中间件则是有状态的，而应用服务根据业务逻辑不同可能是无状态也可能是有状态的。单机房多实例的的高可用架构这种架构是最简单的，一般这种架构只有一个LB网关，通过LB转发到下游的应用服务，应用服务可以通过服务发现的方式做成多副本从而实现多活，比如可以用k8s部署应用服务，配合存活探针检查和k8s的service服务发现，可以轻松实现无状态应用的多活。如果你的服务不基于k8s部署，也可以基于微服务框架部署在多台主机上实现应用多活，只要实现服务发现、存活探针检查和自动的流量切换就可以了。但对于有状态的，比如数据库和中间件，仅仅依赖服务发现和流量切换并不能解决问题，因为数据在多副本之间需要做同步。因此针对数据库或中间件的高可用方案基本都是需要专门设计，因为除了流量切换还要解决数据同步问题。这部分在后面数据库和中间件高可用解决方案在单独展开。同城多机房的高可用架构同城多机房（多AZ）容灾一般通过 BGP 实现单IP多线网络，然后机房之间通过专线相互打通物理网络，当出口流量出现故障时，可以通过 BGP 在路由层切换报文转发表来实现线路切换。架构图如下：在数据链路正常的情况下，机房1，2会分别向路由宣告自己的路由表：机房1：地域AS -> 运营商AS -> 机房1 AS机房2：地域AS -> 运营商AS -> 机房2 AS在机房1出现故障和运营商边缘（接入）路由器断开的时候，机房2会向运营商AS宣告连接机房1的最短路径从而让流量转发给自己：地域AS -> 运营商AS -> 机房2 AS -> 机房1 AS如果对路由器BGP协议不是很了解的可以参考BGP的wiki基于地理区域的高可用架构如果我们要做基于地理区域级别的高可用，那么我们需要DNS智能路由和跨地域的云连接。DNS智能路由DNS服务结合存活探测可以实现跨地域流量切换。当存活探测发现后端 LB 不可用的时候，可以直接修改DNS解析，使其失效。但需要注意 DNS 协议切换一些延迟，生效时间在15分钟~30分钟（RTO），因此 DNS 一般只用于跨地域的 LB 的高可用，只有当整个地区的 LB 不可用的时候才会被启用。我们知道跨地域的故障可以根据智能DNS协议来切换流量到不同的LB中，那么DNS服务本身是如何做高可用的呢？DNS 服务做高可用一般是基于 Anycast 和路由协议来实现，比如 BGP 或 OSPF。和同城多机房的高可用架构一样，通过路由协议实现单IP多线的网络架构来实现容灾切换。Anycast 网络允许网络上的多台服务器使用相同的 IP 地址或一组 IP 地址, 通过 BGP 的路径选择算法改变路由的选择，从而使失效的DNS服务器节点下线，或者实现智能路由。不过 DNS 服务做了高可用并不一定就万无一失了，2021年10月4日的 facebook 全球死机事件就是 BGP 配置错误导致了 facebooK 的 DNS 全部失效了。所以，像开头说的，高可用系统架构只是解决了系统硬件故障，但人为配置错误并不能避免。云连接跨地域的云连接可以是基于骨干网的专线，也可以是VPN。通过云连接将处在不同地域的子网连接起来构造一个互联互通的企业网。专线相比VPN网络传输会更稳定些，安全性更高，但价格也会更贵，成本更高。数据库及中间件的高可用方案数据库和中间件的容灾是一种典型的有状态服务应用的场景，其核心是数据复制和同步。前面说到的两个指标 RTO 和 RPO 就是围绕数据容灾来描述的，如果我们是双活架构那么RTO就是0，如果是主备那么RTO就是主备切换所需的时间；如何我们的数据复制采用完全同步的方式，RPO就是0，如果采用异步复制，那么RPO就是数据复制之间的时间差，如果是快照，那么RPO就是快照产生备份数据和。数据复制数据复制按照leader可以分为三种：单领导者（single leader，单主），多领导者（multi leader，多主） 和 无领导者（leaderless，无主）。单主和多主都属于主从架构，从节点通过复制主节点的日志或变更流(change stream)来同步数据，但在使用场景上两者存在比较大的不同，多主架构一般被用于地理位置上的多数据中心的容灾和就近服务，而单主架构一般用于单数据中心，因为多主架构给整个系统带来的复杂度是很高的，我们需要处理数据冲突，这会给整个系统带来复杂性并降低性能。架构设计核心是要解决问题，因此本质上是一种取舍和balance，在架构设计的时候要视业务和场景而定。单主架构单主架构就是我们常说的主从架构，是分布式架构中最简单的架构，只在 leader 节点做读写操作，follower 节点提供读操作。从库复制主库通常通过变更日志实现，这种变更日志既可以是预写日志(WAL)，也可以是复制逻辑日志。常用的数据库的数据复制:Kafka的kafaka MirrorMarkerMySQL的 binlog 主从复制PostgreSQL的 WAL 主从复制多主架构多主架构在主从数据同步逻辑上和单主架构是一样的，区别核心在多个主节点写入数据的时候如何进行数据同步。一般引入多主架构其中一个原因是解决跨地域数据同步问题，比如在单主架构下，一个在广州的用户在写入数据需要需要传输到北京的主节点上，那么性能就会比较差了。另一个原因则是多主的故障容忍要大于主从，比如在两个主节点的情况下，其中一个节点出故障的时候另一个节点并不会受到影响，只会影响一半的用户，而主从架构在从节点切换完成之前是全用户故障的。我们可以先从最简单的，两个主节点来讨论。在双主的结构下，核心要解决的就是写入的时候的数据冲突问题，如下图所示：在解决数据冲突的时候通常会采用以下的一些办法：最简单的方式就是采用同步的方式写入数据，即数据写入成功需要等待其他主库解决冲突之后，这样就将多个主库写入变成串行执行了，也就失去了多主库的核心。通过分库的方式来避免冲突，比如请求通过统一的路由让a用户数据都读写在A库中，而b类数据读写在B库，其实这样本质类似于将数据库以多分区的形式存放在多个地区，只是a库会通过数据复制在同步到b库。只保证所有副本最终一致性，通过全局唯一ID或全局时钟确定最后更新的数据才写入。但是这种方法在异步的情况下会导致一部分中间数据丢失。除了要解决数据冲突，多主在数据复制的时候还需要解决节点复制传播的顺序，也就是复制拓扑(replication topology)。对于多主复制，常见的复制拓扑主要有三种：环型拓扑架构(circular topology)，即一个数据节点将数据复制给相邻的节点，依次循环一周。星型拓扑架构(star topology)，所有节点围绕着一个中心节点进行数据复制和交互。全拓扑架构(all-to-all topology)，即所有节点相互之间都会进行数据的复制和交互，常见的比如 gossip 协议。在多个主节点进行数据复制和传播的时候，由于会经过多个节点，节点之间需要识别携带其他节点的变更信息，比如每个节点添加有一个唯一ID标识其已经过的节点，这样才不会造成无休止的死循环无休止的传播。无主架构在无主架构中每个节点都可以对外提供服务，从设计理念上可以看出无主架构天生就是为可用性而生，不过知道CAP理论的都知道，可用性和一致性不能兼得，无主架构是个典型的AP模型，其牺牲了强一致性用最终一致性代替。无主架构中最出名的是 AWS 的 Dynamo，像 Cassandra 这种采用和他类似的无主架构的都被成为类Dynamo。Dynamo 采用Gossip协议来做复制数据，任何一个节点收到数据后会向其他节点异步地复制数据。那么 Dynamo 是怎么保证数据最终一致性的呢？Dynamo 使用 W + R > N 这个公式保证，R代表最少读取的节点个数，W代表最少写入的节点个数，N为数据副本数，这里的副本数并不是实际的物理节点，因为 Dynamo 使用的一致性 hash。比如N有3个节点，R是2，W也是2，那么客户端向集群写入数据的时候只有在2个节点写入成功后才会返回给客户端，这个过程是同步的，剩下的两个节点则是异步的，在读数据的时候，必须读到2个节点，并取2个中最新的数据，可以看出这样肯定可以读到最新的数据。当出现数据冲突的时候 Dynamo 通过引入向量时钟解决数据冲突：向量时钟通过带上其他节点的向量时钟来确定偏序关系，按图上例子三个节点P0，P1，P2，初始三个节点都是(0,0,0)首先，P0写入在 a 写入数据，P0 的向量时钟为(1,0,0)当P0把时钟信息传播到 P1 的时候，对应的是时间点 b，P1 的向量时钟是(1,1,0)，这时候 P1 节点如果有个c写入，那么他的向量时钟是(1,2,0)，c的向量时钟里面的元素均大于等于 a，所以我们可以知道 c 时刻大于 a。这时候 P1 把时钟信息传播 d，向量时钟是(1,2,1)，写入数据 e 的数据时钟是(1,2,2)，这个信息传回 P0 后变成 g 时刻，向量时钟是(3,2,2)在这里我们可以看到，a -> b -> c -> d -> e -> g 这个逻辑顺序是成立的，而在向量时钟上表现就是后一个所有元素都大于或等于前一个时间点。但 f 和 c, e 的先后顺序关系是不确定的，在没有全局时钟的情况下你并不能知道谁先谁后，而在向量时钟上表现就是 f 不是所有元素都大于等于 c 或 e。因此，其实向量时钟表示为:if V(a) > V(b) then a -> b
V(a) > V(b), 表示a向量的所有坐标元素大于b向量的所有对应坐标的元素，a->b 表示 a 到 b 存在事件顺序。向量时钟只能解决最终一致性（收敛）问题，如果数据在达成最终一致性之前产生版本冲突，Dynamo 会将冲突版本返回给客户端，由业务自行判断。除了交由客户端判断，我们也可以采用“最后写入胜利（LWW, last write wins）”的策略，在数据生成的时候通过带上时间戳，最后比较两个版本的时间戳谁新以谁为准。Dynamo 检测数据不一致用的 MerkleTree，MerkleTree 是通过一个 hash 树来计算每部分的数据，父节点是子节点数据的 hash，只要有一块数据变动了，最上层的根节点的hash就会改变，然后可以通过逐层递归的方式找到目标节点，查询时间复杂度是o(log(n))，如下图：更多详细的 Dynamo 可以参考原论文，这是国外老哥的一篇论文笔记：数据复制的几种方式前面说了数据复制的几种架构，那么具体数据复制的形式有哪些呢？这里根据数据库复制数据的主体不同分为四类：基于语句(statement)的数据复制基于逻辑日志(行)的数据复制基于预写日志(WAL)的数据复制基于触发器的复制基于语句复制直接基于数据库的语句进行复制，MySQL 5.1 版本前都是基于语句进行复制，基于语句的主从复制下 MySQL 会将 SQL 变更语句写入 binlog 中，然后同步给从节点让其更新，基于语句的复制主要简单，而且传输数据量少，但其可能会存在不安全语句，而且每次更新都只能串行，特别是某些语句比如 INSERT ... SELECT 会因为锁比行复制慢更多。PostgreSQL 的 pgpool-II 也是一种基于语句复制工具，但其本身相当于数据库的 Proxy，而不是数据库自身提供的CDC。复制逻辑日志(行)逻辑日志是针对语句复制提出来的，因为基于statement的复制存在诸多问题，比如事务没办法并行复制，只有等待一个commit才能复制另一个，性能差。因此另一种，是以行为颗粒度基于逻辑日志的数据方式，经典代表就是 MySQL的binlog(row)格式。其对数据库表的写入记录：对于插入的行，日志包含所有列的新值。对于删除的行，日志包含足够的信息来唯一标识被删除的行，这通常是主键，但如果表上没有主键，则需要记录所有列的旧值。对于更新的行，日志包含足够的信息来唯一标识被更新的行，以及所有列的新值（或至少所有已更改的列的新值）。复制预写日志(WAL)很多数据库在写数据的时候为了磁盘顺序读写优化和事务性会引入预写日志(write ahead logs,WAL)，因此一些数据同步方案会尝试利用 wal 特性来做数据复制和同步。比如 PostgreSQL 9.0之后的 PITR(Point in Time Recovery) 就是基于 WAL 做主从复制。 PostgreSQL 的预写日志复制传输提供两种：存档式(archive)和流式(streaming)。存档式就是等一个WAL文件写完后，再拷贝从节点；流式则是写完一条WAL记录就通过TCP直接传给从节点。存档式存在数据延迟较大，流式则再主节点崩溃时从节点存在丢失数据的可能。PostgreSQL Archive ReplicationPostgreSQL Streaming Replication基于触发器的复制上面讲的那些复制方式都是数据库系统提供的，比如基于语句和逻辑日志的复制是在数据库的 server 计算层来做，预写日志(WAL)则是在存储层做，而触发器是数据库系统系统的将自定义的程序注册进数据库让其在数据变更时自动触发。由于是由外部程序对变更进行捕捉，因此他的灵活性是最高的，像多主复制的冲突解决方案大部分都是基于触发器实现，比如 PostgreSQL 的 bucardo 就是基于 pg 的触发器来做多主的数据复制。小结整篇小作文洋洋洒洒写了近一万字，从系统架构、各层级组件的高可用到数据复制拓扑，希望可以给大家一个相对比较完整的视角去认识高可用系统的建设。参考文献BGP协议2021年Facebook死机事件Designing Data-Intensive Application阿里云服务器是如何实现每台服务器都是公网IP的呢？
针对每一个问答都本着绝不大胆胡说，只管小心求证的态度，疯评科技来解答您的提问。
刚好跟阿里有BGP对接业务，对他们的IP地址数量还是有点数的。
阿里云服务器的公网IP当然都是在中国互联网络信息中心申请来的，只要你业务足够大，用得上，在地址还没有枯竭前，大量申请，这都不是什么难事。阿里十多年前就在开始做云计算，肯定知道需要大量的IP地址数量的，那个时候应该就在大量储备的。
另外还要强调下，从运营商处获取的IP地址那个只是转租而已，你并不是拥有者，别想错了。真正自己拥有IP地址是从CNNIC来申请的，刚好前几年我们申请了8个C类IPv4地址和一段/32的IPv6地址。
看看2016年后普通企业都能申请到大量IP地址，可想阿里这种有多少IP地址了。
阿里到底有多少IPv4的地址数呢？阿里到底有多少IPv4地址数呢？ 在通过中小企业BGP业务中，跟阿里的BGP对接中接收到的地址数量来看，是非常庞大的，这当然肯定只是整个阿里地址数量的一部分了。
我们一起看看到底有多少吧
上面只是最新的阿里收到的路由条目，实际上在之前并没有这么多，因为是动态路由，所以可以肯定，阿里的路由会是逐渐变多的，下面看看我监控的阿里的路由数量，
可以看到在三个月前只有322条，说明什么了？ 阿里增加IP地址数量了，这可能是早就申请好的，没有启用，现在业务增加了，再进行启用的部分。
关于阿里云服务器的公网IP在你购买了阿里云服务器后，只要你想要公网IP，就会自动分配给你，
如果你想长期保留这个公网IP，就可以申请弹性公网IP，哪怕换了云服务器，都可以用这个公网IP，如果不需要长期保留，换云服务器公网IP就变换了。
一般来说，阿里云会进行类似分区的方式，一个区内，所有云服务器都可以进行相互访问（当然是需要用户解除安全规则才可以），都在一个局域网，这个大局域网内会有设备进行分配公网IP，普通公网IP池就类似一个DHCP的公网池，你服务器解绑后就自动释放出来了，弹性公网IP就是在你用的时候一直绑定到你的服务器，哪怕中间释放，再绑定，还是那个IP，专用。很显然，普通公网IP地址数量只要保持跟用户一样多就够了，因为有用户退出就可以动态释放，弹性公网IP就要至少是一个用户一个，还有些用户需要多个的，这些数量是很多的。
但无论如何，公网IP数量肯定是管够的，毕竟做开始做云计算，阿里就可以预见到IP地址的重要性了。
关于NAT
从这台云服务器中可以看到，网卡上只配置有私网IP，而上面看到的公网IP并没有在网卡上，因此，这个公网IP就是通过一对一的方式映射在云账户的这个网卡上的。
但这里NAT也只是这种一对一的方式，不会出现多个云服务器通过NAT共用一个公网IP的情况。
阿里云首先通过储备大量的公网IP数量，跟运营商建立BGP连接，进行全网广播即可。在每个云节点地址数量管够，然后再通过一对一的NAT映射方式，将公网IP分配给用户。
你有何看法呢？欢迎留言探讨！
