跨大西洋其实有南北两条路：面向拉美用户的欧洲内容，放毕尔巴鄂和放阿姆斯特丹差在哪

西班牙节点不等于只给西班牙用户用

把内容放到西班牙毕尔巴鄂，就等于只给西班牙用户看——这是跨大西洋出海方案里最常见的一个误判。它把一个地理标签当成了路由结论：机房在哪个国家，就被认为只服务哪个国家的访问者。真正决定访问路径的，是这条流量的上游——它走的是哪条跨洋海缆、在哪个登陆站上岸、上岸之后又连到谁的网络。

举个具体的场景。一个七成用户在巴西的葡萄牙语短视频站，把源站放在阿姆斯特丹，请求大概率要先沿北大西洋走廊抵达欧洲西北角，再一路南下穿过整个西欧；而如果把源站放在毕尔巴鄂近郊，流量走的是跨大西洋南线，上岸之后往南欧与伊比利亚分发。两者差的不是「荷兰还是西班牙」，差的是两条完全不同的水下走廊、两个不同的登陆站、以及上岸后两段完全不同的内陆回程。

同样的误判也发生在反向：有人看到「拉美用户」四个字，就把节点往美国迈阿密堆，理由是与拉美地理最近。但拉美侧的国际出口大部分本来就汇向北美东岸，真正该问的是汇到东岸的哪一个登陆站、这个站能不能直接跨接欧洲方向的缆。这两个问题的答案，跟迈阿密还是阿姆斯特丹这种城市名几乎没有关系。

所以本文判断的落点只有一个：选欧洲节点时，要看「上游那条跨洋缆是谁的、从哪上岸、连到谁」，而不是看国别。国别只是这条链路最后几十公里的标签。

用户到底在哪个方向：拉美、伊比利亚、北欧与北美东岸的来源分层

在讨论上岸点之前，先把用户按「方向」而不是按「国家」分一次类。同一个国家名在不同出海方案里的权重差别很大，真正影响链路选择的是四个方向群体：拉美、伊比利亚半岛、西欧与北欧、北美东岸。

拉美方向以巴西、阿根廷、智利、哥伦比亚、墨西哥为主。这一组的共同点是本地国际出口高度依赖北美东岸，多数流量在到达欧洲之前会先出现在美国的某个登陆站。也就是说，拉美用户的欧洲访问，天然包含一次「跨大西洋南线或北大西洋走廊」的转接。

伊比利亚半岛方向是西班牙与葡萄牙。这一组最容易被误当成「西班牙节点的唯一服务对象」，但它同时是南欧分发的中转位置——从毕尔巴鄂上岸的流量，往南可以进马德里，往北可以进法国，往东可以进地中海沿岸。

西欧与北欧方向以荷兰、德国、英国、法国北部和北欧国家为主。这一组的用户最贴近北大西洋传统走廊的登陆结构，历史上跨洋缆也确实长期集中在这一带的上岸点。如果业务的重心在这一组，把内容放在阿姆斯特丹、伦敦方向的合理性会明显更高。

北美东岸方向是美国东部与加拿大东部用户。这一组经常被忽略：他们既不是欧洲用户，也不是拉美用户，但因为跨洋缆的登陆站就在东岸，他们实际上是最容易「顺路服务」的一群人——前提是内容所在的节点与这个登陆站之间的回程足够短。

分层之后还有一个容易被跳过的变量：时区。拉美主要城市与伊比利亚半岛相差约四到五小时，与西欧北欧相差也在同一量级，与北美东岸相差约两到三小时。这意味着不同用户群的晚高峰并不会完全重合，带宽曲线往往是双峰甚至多峰的。按单一峰值叠加去估带宽，会把成本抬高一截；按完全不叠加去估，又会在重叠时段压垮出口。这个曲线的形状，直接决定后面「服务器与带宽怎么配」那一节的结论。

实操上，分层不要靠猜。用应用日志或 CDN 日志按 ASN 与城市导出访问量的 Top-N，再把这些 Top-N 归到上面四个方向，你会得到一张方向权重表。这张表才是选上岸点的输入，而不是「我们主要做欧洲市场」这类模糊判断。

跨大西洋的两条路：北大西洋传统走廊与南线弗吉尼亚海滩—毕尔巴鄂

跨大西洋并不是一条走廊，而是两条。北边那条是长期形成的传统走廊，上岸点集中在美国东北部与英国、荷兰一带；南边那条在很长一段时间里几乎是空白——MAREA 是 1999 年以来第一条建在北大西洋以南的跨大西洋缆，这句话本身就说明，此前近二十年新增的跨洋容量几乎都堆在北线。

MAREA 连接美国弗吉尼亚海滩与西班牙索佩拉纳（毕尔巴鄂近郊），全长约 6,605 公里，8 对光纤，初期设计容量 160 Tbps，商用后约半年内提升到 200 Tbps（SubTel Forum 海缆年鉴第 57 期记为设计容量 209.6 Tbps）。它 2017 年 9 月 21 日宣布建成，2018 年 2 月投入运行、2018 年 4 月商用，由 Microsoft、Facebook（现 Meta）与 Telefónica 子公司 Telxius 建设，Telxius 负责运营并批发容量。2019 年 1 月，AWS 与 Telxius 签署 IRU 协议使用 MAREA 的一对光纤。

项目动机里有一条值得单独记：2012 年桑迪飓风造成的网络中断。这解释了为什么南线会被提出来——不是为了地理新鲜感，而是为了给北大西洋走廊之外再留一条故障时不一起失效的路径。这个动机对选型的意义非常直接：如果你的备份出口和主出口都落在北线的不同缆上，那么一场针对同一片海域或同一批登陆设施的事件，可能同时打掉两者。

北线并不是没有新东西。Google 的 Dunant 缆连接弗吉尼亚海滩与法国圣伊莱尔德里耶，2021 年投用，容量 250 Tbps，采用 12 对纤的空分复用。这条缆同样从弗吉尼亚海滩出发，但上岸点在法国而非西班牙——把它和 MAREA 放在一起看，你会发现「弗吉尼亚海滩」这个登陆站比「毕尔巴鄂」这个城市名更能说明问题：同一侧的入口可以在不同欧洲国家落地，选择权在上岸点，不在国别。

把节点放进比选清单时，通常还要横向对照亚洲侧与其他区域的交付能力。以国内交付方为例，一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。需要说清楚的是，伊比利亚方向属于欧洲本地上岸资源的范畴，是否由某一交付方直接提供，必须以该方官网当期公开信息为准，本文只在行业部署层面讨论路径选择本身。

谁持有哪对纤：MAREA 的容量分配决定了故障域边界

海缆选型里最容易被忽略的一层是「纤对归属」。MAREA 的 8 对光纤中，Microsoft 与 Meta 各持 2 对，Telxius 持 3 对。你从服务商那里买到的容量，一定落在这 8 对中的某一部分之上，而这部分属于谁、由谁的设备点亮，就决定了你的故障域。

这层判断之所以关键，是因为容量不等于可用性。同一条缆上，不同纤对的线路设备、光转发器、供电与运维责任方可能并不相同。某对纤做计划内升级时，同缆的另一对纤未必受影响；反过来，某对纤的设备故障，也可能与邻居无关。所以「我用的是 MAREA」这句话，对可用性的说明力其实很弱，真正要问的是「我用的是哪一对、由谁运营、升级窗口怎么通知」。

MAREA 还是首个在海底线路上采用开放线路系统（OLS）的系统。OLS 的含义是线路设备与光转发器解耦，可以独立向不同厂商采购传输设备。这件事对租用方的实际价值在于：容量升级不必整系统替换，颗粒度可以做得更细，升级节奏也不必被单一厂商的供货周期锁死。换句话说，这条缆的设计从一开始就给「后续提速」留了口子。

这也能解释为什么 2019 年 AWS 会通过 IRU 协议从 Telxius 那里使用一对光纤。超大规模方拿到的是确定的、长期的、可自控的容量权；而普通租用方拿到的通常是转售容量。两者的差别不在带宽数字，而在优先级、可控性和可预期性——出问题时，谁有资格决定抢修顺序和流量调度，往往由这一层决定，而不是由合同上的带宽数字决定。

弗吉尼亚海滩为什么成了新的跨洋入口：从纽约/新泽西到 Ashburn 的回程

弗吉尼亚海滩登陆点此前并非跨洋缆的主要入口，原先的入口集中在纽约/新泽西一带。这个变化值得单独拆开看，因为它改变了「跨洋之后还有多远」这个成本项。

该站有直达 Ashburn（Data Center Alley）的回程。这一句的分量在于：跨洋流量上岸之后，不需要先北上到纽约都市区再南下，而是在很近的距离内就进入大型数据中心集群。对内容分发类业务来说，上岸点到计算集群的距离直接决定三件事——新增跳数、内陆回程的单位成本、以及这一段是否容易在峰值期被挤。

对选型而言，由此可以得到一个很实用的判据：评价一个欧洲节点，不要只看它在欧洲的位置，还要看它在美洲那一侧对着哪个登陆站，以及那个登陆站离集群有多远。两个都叫「欧洲节点」的方案，一个的上岸点直连 Ashburn，另一个的上岸点还要再绕一百多公里的都市区回程，长期成本与稳定性不会一样。

这个判据也解释了为什么南线出现之后，北美东岸用户反而更容易被顺路照顾：入口在美国东岸南部，集群就在旁边，欧洲内容从欧洲回传东岸的路径反而变短了。如果你同时有欧洲用户和美国东部用户，「欧洲节点 + 南线上岸」可能比「欧洲节点 + 美国节点双份部署」更省一层架构复杂度，前提是回程与容量能满足两边的峰值叠加。

上岸之后的第二程：Derio 枢纽接入马德里、巴黎、伦敦、马赛

上岸不是终点。索佩拉纳只是缆的落地点，真正的分发能力取决于上岸之后的内陆回程。Telxius 在欧洲与美洲运营 26 个海缆登陆站与数据中心，其旗舰设施是毕尔巴鄂的 Derio 通信枢纽与数据中心，把 MAREA 接入马德里、巴黎、伦敦、马赛等欧洲枢纽。

这段话里藏着选型时最常被漏掉的成本项：如果你的目标用户在巴黎，那么「毕尔巴鄂节点」的实际路径是索佩拉纳上岸、经 Derio、再经内陆到巴黎。这一段内陆回程的跳数、带宽与峰值表现，跟跨洋那一段同样重要，而且更容易被忽略——因为人们的注意力都在海缆上。

具体怎么判断？把目标城市按内陆距离分层。马德里在伊比利亚半岛内部，从毕尔巴鄂过去是半岛内回程，路径最短；巴黎需要跨比利牛斯山进入法国；伦敦更远一档；马赛则要横穿到地中海沿岸。同一个「毕尔巴鄂节点」，对马德里用户和对伦敦用户的实际体验不会是同一个量级。

因此有一个反直觉的结论值得写出来：如果你的用户高度集中在荷兰、德国或英国，即便内容本身是西语或葡语，把源站放在毕尔巴鄂也可能不是最优——上岸优势会被内陆回程吃掉一部分。反过来，如果你的用户在西班牙、葡萄牙、法国南部和拉美，内陆回程短，上岸优势才完整保留下来。判断标准不是「离欧洲中心近不近」，而是「离你的用户群近不近」。

还要提醒一点：内陆回程的拥塞往往发生在交换点而不是链路上。从公开网络条件和常见部署逻辑来看，欧洲主要枢纽之间的互联在晚高峰会有排队现象，实际延迟仍需按运营商、线路和具体机房测试确认。签合同前要一段真实时段的双向 traceroute，比看拓扑图有用得多。

拉美方向同样汇入弗吉尼亚海滩：BRUSA、SAM-1、Tannat 的走向

这一节是整篇文章的核心论据：面向拉美方向的欧洲出口与面向北欧方向的欧洲出口，之所以能被说成是两条不同的故障域，关键就在于它们汇到了同一个登陆站，而北线根本不经过这个站。

Telxius 的拉美方向缆系包括：BRUSA（里约热内卢、福塔莱萨—圣胡安—弗吉尼亚海滩，约 11,000 公里，160 Tbps，巴西直连美国的第一条缆）、Tannat（巴西—阿根廷间新增容量）、SAM-1（环绕拉美的约 25,000 公里环路），另有 Junior、Mistral、PCCS、Unisur。

把这些缆的终点叠在一起看，会发现它们与 MAREA 汇到同一个弗吉尼亚海滩登陆站。这意味着一件很有价值的事：拉美用户的流量上岸之后，可以在同一个登陆站完成向南线上的跨接，直接跨大西洋去欧洲，而不必北上纽约、也不必绕道其他登陆站。同站跨接省掉的不只是距离，还有一次跨运营商的转接和一份额外的不确定性。

这个结构同时回答了一个长期让人困惑的现象——拉美用户访问欧洲内容为什么有时绕美国。答案不是路由配置错了，而是结构性的：拉美侧的国际出口本来就指向北美东岸，欧洲方向的跨洋缆也主要在美国东北部与弗吉尼亚海滩一带上岸。只要这个结构不变，「先到美国、再跨大西洋」就是默认路径。想改变它，不是改 DNS 或换 CDN 就能解决的，得换上岸点，或者接受这条路径并把缓存前移到登陆站那一侧。

从容量侧看，BRUSA 约 11,000 公里、160 Tbps，SAM-1 是约 25,000 公里的环路，规模都不小。但容量大不等于你的流量不会被排队——拉美侧本地运营商的出口与国际段往往是两个瓶颈，前者才是很多巴西、阿根廷用户体感差的真正原因。欧洲这一侧做得再好，也救不了用户最后一公里的接入质量，这一点必须提前写进预期里。

开放线路系统与 800G 相干可插拔：升级由谁承担

选跨洋路径时还要看一件事：这条路的后续提速由谁掏钱、由谁施工。这决定了你未来三到五年的扩容是不是被动的。

2026 年，Telxius 与 Nokia 开始在其欧洲、美国与拉美陆地传输网部署 ICE-X 800G ZR/ZR+ 相干可插拔光模块（IP-over-DWDM）；此前双方在 BRUSA 上完成过 400Gb/s 单波长、超过 5,600 公里的联合演示。这两条信息放一起看，指向的是同一个趋势：相干光模块正在从机房里的大型转发器，缩小成可以直接插进路由器端口的可插拔器件。

IP-over-DWDM 对租用方的实际意义有三条。第一，中间的电层设备减少，链路上的故障点变少，功耗与空间占用也下降。第二，扩容颗粒从「整波分系统」变成「单个端口的模块」，扩一小档不再需要大工程，成本曲线更平滑。第三，升级的主动权部分转移到网络运营方手里，租用方能在合同期内拿到更快单波长的概率提高。

但它也有代价：单波长速率越高，对光纤质量与放大段的要求越苛刻，长距离链路上的可用余量不是无限的。BRUSA 上那次 400Gb/s 超过 5,600 公里的演示，恰恰说明长距高单波长需要在实际缆上验证，而不是按规格书推。选型时如果服务商承诺「后续可平滑升到某速率」，问一句这个速率是否在该链路上实测过，比看宣传材料更可靠。

把这节和前面 OLS 那节连起来看，MAREA 这条路的共同特征是：解耦。OLS 解耦了线路设备与转发器，IP-over-DWDM 解耦了路由与波分。解耦越多，单点升级越快，但也越依赖运营方的技术判断。你选择的其实不是一条缆，而是一个运营方的升级能力。

六条路径的横向对照：上岸点、运营方、回程与容量现状

下面这张表把本文涉及的几条路径放在同一组维度上对照。列的顺序刻意按「上岸—服务方向—内陆回程—容量—待确认问题」排列，因为判断一条路径是否适合，永远是从上游往下走，而不是从节点所在城市倒推。

读这张表的正确方式是从右往左。左边四列描述的是「这条路是什么」，右边一列描述的是「你签之前必须问出口罩下的问题」。多数人在选型时只核对左边四列，把右边一列留到出事之后再问——那是这张表最该被用好的地方。

服务器与带宽按用户侧配：出口方向、峰值时段与冗余倍率

路径定下来之后，配置才有意义。这一节按「用户侧」而不是按「机型档位」来讨论，因为同一个配置在双峰流量和单峰流量下的表现完全不是一回事。

先看出口方向。如果主出口走南线，那么服务伊比利亚与拉美用户的这一段是顺的，服务北欧用户的这一段要额外付出内陆回程。带宽规格的估算要按「最差方向」而不是「平均方向」来做：你的端口必须扛得住峰值时刻最差那一群人的并发，而不是扛得住日均。这一点在视频与下载类业务上尤其明显，因为这类业务的峰值倍率远高于 API 类业务。

再看峰值时段。前面说过，拉美、伊比利亚、北欧、北美东岸的晚高峰并不重合。错峰意味着同一个物理端口可以被多群人分时使用，端口利用率能做得比较高；但也意味着监控阈值不能按单一峰值设——否则第一波拉美高峰刚过，系统告警已经麻木了，欧洲高峰来得时候没人看。告警要按方向分群设，这是很多人部署完才发现的问题。

CPU 与内存的优先级，取决于内容是不是要现场加工。纯静态与小文件分发，瓶颈在出口带宽与文件系统的随机读，CPU 与内存可以压得很低；带转码、带实时封包的业务，CPU 核数与单核性能会成为第一瓶颈，内存则主要用于缓存与连接表。判断顺序是：先看业务有没有「每请求都要算」的环节，有就把 CPU 排在带宽前面，没有就把带宽排在 CPU 前面。这个顺序搞反了，钱会花在永远跑不满的核上。

存储这一层，系统盘与数据盘要分开考虑。系统盘只装操作系统与运行环境，容量不用大，但可靠性要够；数据盘放内容本体，热数据建议放在 NVMe 上，冷数据下沉到对象存储或大容量机械盘。热数据的判定标准是访问频次而不是文件大小——跨洋场景里尤其要注意，回源一次跨洋的成本远高于本地，所以热数据命中率提高几个百分点，省下的回源带宽往往比升级一次磁盘更划算。

冗余倍率怎么定？按「单点失效时还剩多少」倒推，而不是按「平时用多少」乘以一个经验系数。如果你只有南线一个出口，那么南线中断时你剩下的不是 50%，而是 0；如果你的架构是南线主、北线备，那么冗余倍率取决于北线在切换瞬间能接住多少流量。多数情况下，备份侧不需要和主侧同规格，但它必须能接住最关键的那部分流量——通常是登录、支付、下单这类写请求，而不是视频流。

IP 与防御也别漏。跨洋场景里，IP 段的来源与宣告方式会影响部分区域的可达性，尤其是拉美侧某些本地运营商对境外段的处理并不一致。防御则要看清洗容量是不是在就近节点——如果清洗中心在欧洲西北角，而你的用户在南欧与拉美，攻击流量绕一圈再回源的延迟会很明显。这两项都属于「签之前问清楚、签之后很难改」的内容。

关于价格，本文不给出具体数字：跨洋容量与欧洲本地端口的报价随合同期、容量、方向变化很大，且公开资料中没有可引用的确定价格，一律以官网实时报价或实际合同为准。

数据库与应用要不要分开放两个国家

这是一个很容易被「上云就自动解决」的说法带偏的问题。结论要先说：能不分开就不分开，必须分开时，分的是读而不是写。

原因是延迟的物理约束改不了。应用与数据库之间的每一次交互都要走一个往返，如果这个往返跨了一次国内陆甚至跨了一次海，那么应用层再怎么优化都会被打回原形。从公开网络条件和常见部署逻辑来看，欧洲主要枢纽之间的往返在几十毫秒量级，跨大西洋则明显更高；实际延迟仍需按运营商、线路和具体机房测试确认。一个原本设计成每页几十次数据库查询的应用，跨洲部署之后响应时间会成倍放大——问题不在网络，在架构。

所以正确的边界是：写库跟随主要写用户群。如果你的付费用户主要在巴西，主库放在伊比利亚或西欧都会让每一笔写入多跨一次洋；如果付费用户主要在西班牙，主库放在毕尔巴鄂侧就近即可。写路径是不可妥协的那一端，它决定了主库的位置。

读副本可以跨向部署。欧洲用户读欧洲副本，拉美用户读拉美侧或北美东岸侧的副本，副本之间通过异步复制追赶。这里要接受的是复制延迟——从常见部署逻辑看，跨洋异步复制的延迟通常在秒级，具体数值取决于链路与写入量。业务设计上必须容忍这个窗口：用户刚提交的内容，在另一个方向的副本上可能要过几秒才可见。把这种不一致当成 bug 去修，是跨区域部署最常见的返工来源。

如果你考虑的是「应用放一个国家、数据库放另一个国家」这种对称拆分，要特别小心。对称拆分带来的不是冗余，而是两条都变长的路径：欧洲用户访问欧洲应用，应用去拉美读库；拉美用户访问拉美应用，应用去欧洲读库。除非你的业务本身就是读写分离得非常干净的类型，否则这种拆法几乎总会变慢。

还有一层是数据位置。欧盟境内对个人数据的跨境传输有明确要求，把包含个人信息的库放在欧盟境外，或者让境外节点直接读写欧盟境内的数据，都需要提前评估合规边界。合规这件事在跨洋场景里尤其容易被忽略，因为大家的注意力都在延迟和成本上。评估要前置到选型阶段，而不是等部署完成再补。

本文不讨论的三类问题：海缆容量采购合同、跨大西洋带宽报价、伊比利亚本地宽带接入

为了让讨论保持在一个有用的范围内，有三类问题本文刻意不展开。

第一类是海缆容量采购合同。IRU、容量权、批发条款这些属于大容量采购的范畴，合同结构与普通服务器租用、端口租用完全不同，讨论它对绝大多数内容出海团队没有参考价值。本文只在需要说明故障域时，提到 AWS 与 Telxius 在 2019 年 1 月签署的 IRU 协议这一事实本身。

第二类是跨大西洋带宽的报价。公开资料中没有可引用的确定价格，本文不给出任何具体数字，也不做估算表。涉及价格的地方一律写「以官网实时报价或实际合同为准」。如果你需要预算口径，正确的做法是向服务商按方向、容量、合同期分别询价，而不是拿行业传闻去套。

第三类是伊比利亚本地宽带接入。本地家庭宽带、企业接入、本地运营商的城域覆盖，与「从哪个登陆站上岸」是两个不同层面的问题，混在一起谈会让判断失真。本文讨论的是跨洋段与欧洲内陆骨干这一段，本地接入质量请按目标城市的运营商实际覆盖情况单独评估。

已知风险：故障域、修复周期与容量权三条线

风险这一节按三条线展开，每条都给出问题、原因、判断与规避动作。

第一条是故障域重叠。问题：准备了备份，但备份和主用一起失效。原因：跨大西洋的入口其实分南北两片，如果主备都落在同一片海域的登陆站上，一次区域性事件可能同时影响两者——2012 年桑迪飓风造成的网络中断正是 MAREA 立项的动机之一，这个例子说明区域性事件是真实存在的设计输入，不是理论风险。判断方法：把主备两条路径的上岸点标在地图上，如果它们在同一片海岸线或同一个登陆站，就不算互为备份。规避动作：主用南线时，备份明确落在北大西洋走廊的上岸点，并且验证过切换后的内陆回程确实可达。

第二条是修复周期。问题：海缆断了，多久能好。原因：水下段的修复需要专用船只与作业窗口，且同期若有多条缆报障，作业资源会排队，周期往往以周计，而不是以小时计。判断方法：不要把「有备份缆」理解成「断了立刻切」，要理解成「断了之后备份能长期顶住」。规避动作：备份侧的容量要按长期承载来买，而不是按应急几分钟来买；同时把降级预案准备好——降低码率、关闭非核心功能、静态化部分页面，比临时找容量现实得多。

第三条是容量权。问题：峰值时段你的流量被排队，但合同上写的带宽并没有少。原因：你买的多半是某一对纤之上的转售容量，而纤对归属方（MAREA 上 Microsoft 与 Meta 各持 2 对、Telxius 持 3 对）在拥塞时优先保障自己的需求，这是容量权的差别，不是带宽数字的差别。判断方法：签之前问清是波长级还是以太网转售、属于哪一对纤、有没有拥塞时的处理条款。规避动作：把「峰值可用」而不是「标称带宽」写进验收标准，用真实的峰值时段数据去验收，而不是用闲时测速。

第四条容易被漏掉：内陆回程与本地接入。问题：跨洋段很好，用户体感仍然差。原因：链路端到端分成四段——用户本地接入、拉美侧国际出口、跨洋段、欧洲内陆回程。前三段任何一段弱，第四段再强也没用。判断方法：分段测，不要只看端到端。规避动作：把缓存与静态内容尽量前移到离用户近的那一侧，欧洲源站只承担回源与写入。

第五条是单点登陆站。问题：一个登陆站承担了太多方向。原因：弗吉尼亚海滩同时汇聚了 MAREA 与 Telxius 的拉美缆系（BRUSA、SAM-1 等），同站跨接带来效率，也带来集中度。判断方法：确认同站跨接是光纤直连还是经第三方回程，以及该站是否有第二路由。规避动作：关键业务的写路径至少要有一次不经过该站的路径，验证过可用即可，不一定要常态跑流量。

部署顺序建议：从流量画像到双出口切换

顺序错了，后面每一步都要返工。下面这套顺序是按「先确定方向、再确定规格、最后确定冗余」排的，每一步的输出都是下一步的输入。

第一步做流量画像。从应用与 CDN 日志导出访问量的 Top-N，按 ASN 与城市归到拉美、伊比利亚、西欧北欧、北美东岸四个方向，得到方向权重表。同时导出分时曲线，确认峰值是单峰还是多峰、重叠多少。这一步的输出是一张表，不是一份感觉。

第二步定上岸点。方向权重表里谁占大头，就先满足谁：拉美与伊比利亚占大头，南线优先；西欧北欧占大头，北大西洋传统走廊优先；两边都不小，就按双出口设计，而不是先上一个再补。注意这一步不要被城市名带偏，判断的是上岸点与登陆站。

第三步验内陆回程。向上游服务商要目标城市的双向 traceroute，重点看上岸之后到目标枢纽的跳数与路径是否稳定，不要只看跨洋段。伊比利亚、法国、英国、荷兰分别测，差异会比你预期的大。

第四步定规格。按「最差方向 + 峰值重叠」估算端口，按「有没有每请求都算的环节」决定 CPU 与内存的优先级，按访问频次而不是文件大小决定热数据放在哪一层存储。这一步里，一万网络的标准化服务器方案可以作为配置基线的参考：把业务拆成计算、存储、出口三个部分分别对齐规格，避免用一套通用机型去覆盖所有方向的需求；具体机型与当期带宽报价以官网实时信息或咨询确认为准。

第五步小规模灰度。用 GSLB 或任播把一小部分流量导到新方向，观察至少一个完整的高峰周期，重点看错误率、首字节时间与回源量，而不是只看平均延迟。平均值会把尾部问题藏起来。

第六步切换与回滚。切换要能一键回滚，回滚路径要提前跑通一次。双出口架构下最常见的事故不是切换失败，而是切过去之后发现回滚的 DNS 记录早已过期。

第七步补监控与告警。告警按方向分群设阈值，不要用一个全局阈值覆盖四个方向的用户群。监控要包含回源带宽与副本延迟两项，这两项是跨区域部署最先出问题的地方。

面向拉美与欧洲双方向时最常被问到的六个问题

毕尔巴鄂是不是只能服务西班牙本地？

不是。节点所在国家只描述机房位置，不描述流量来源。从毕尔巴鄂近郊索佩拉纳上岸的 MAREA，另一端是美国弗吉尼亚海滩，而弗吉尼亚海滩同时汇入了 Telxius 的拉美缆系 BRUSA 与 SAM-1，也就是说拉美方向的流量可以在同一站跨接过来。真正限制服务范围的是内陆回程：从 Derio 到马德里最短，到巴黎、伦敦、马赛依次变长。用户集中在马德里与拉美时优势最完整，集中在荷兰德国时要重新算这笔账。判断标准永远是用户方向，不是国别标签。

MAREA 和北大西洋缆断了会互相顶替吗？

不能自动顶替，但可以作为备份路径的前提是存在。MAREA 是 1999 年以来第一条建在北大西洋以南的跨大西洋缆，上岸点在弗吉尼亚海滩与西班牙索佩拉纳，和北大西洋走廊的上岸点在地理上分开，这正是它可以作为另一条故障域的原因。但「存在备份缆」不等于「断了立刻切」：水下段修复需要专用船只与作业窗口，周期以周计，所以备份侧必须按长期承载来准备容量，而不是按应急几分钟准备。切换能力也需要提前演练，否则真正出事时会发现 DNS 或路由根本没有自动化。

拉美用户访问欧洲内容为什么有时绕美国？

因为这是结构性路径，不是配置错误。拉美侧的国际出口主要指向北美东岸，而跨大西洋缆的登陆站集中在美国东北部与弗吉尼亚海滩一带，流量自然要先到北美东岸再跨洋。改变它的办法不是改 DNS 或换 CDN，而是换上岸点——让拉美流量在与欧洲缆同站的地方完成跨接，比如弗吉尼亚海滩。如果暂时不能换，退而求其次的办法是把缓存前移到登陆站那一侧，让欧洲源站只承担回源与写入，减少跨洋往返次数。

欧洲内部回程要不要单独算？

必须单独算，而且它经常被低估。跨洋段只解决「上岸」，上岸之后到目标城市还有一段内陆路径：索佩拉纳经 Derio 到马德里是半岛内回程，到巴黎要跨境，到伦敦更远一档，到马赛要横穿到地中海沿岸。同一节点的实际体验在不同目标城市之间可以差出很大的量级。做法是在验收前要目标城市的双向 traceroute，分别测伊比利亚、法国、英国、荷兰，用真实时段的数据判断，而不是看拓扑图或宣传材料。内陆段的拥塞通常发生在交换点而不是链路上，这一点也要一起看。

应用和数据库能不能分开放两个国家？

技术上可以，但代价往往是变慢。应用与数据库之间每次交互都要一个往返，跨境之后这个往返会被拉长，一个每页几十次查询的应用会把延迟成倍放大——问题在架构而不在网络。比较可行的拆法是分层：主库跟随主要写用户群，读副本按方向部署，副本间异步复制。代价是复制延迟带来的可见性窗口，业务必须容忍刚提交的内容在另一个方向几秒后才可见。对称拆分（欧洲应用配拉美库、拉美应用配欧洲库）通常是最差的一种，除非读写分离做得非常干净。

公开资料里没有报价时怎么估预算？

不要估，要问。跨洋容量与欧洲本地端口的报价随方向、容量、合同期变化很大，公开资料里没有可引用的确定价格，任何估算表都只是猜测。可行的做法是把预算拆成四个独立项分别询价：欧洲侧的计算与存储、欧洲侧的出口端口、内陆回程、备份路径容量。分开问的好处是能看清哪一项在涨价，也能在预算不足时精确砍掉一项而不是整体降级。行业参考值只能作为量级判断，必须标注口径，最终一律以官网实时报价或实际合同为准。

选毕尔巴鄂之前，先回答你的用户在哪个方向

回到最开始那个误判。把毕尔巴鄂理解成「西班牙节点」，会让人用国别去推导用户群，进而导出错误的结论；把毕尔巴鄂理解成「跨大西洋南线的欧洲上岸点」，判断就回到了正确的变量上：跨洋缆是谁的、从哪上岸、上岸之后连到谁。

南线这条路的确定性特征是清楚的：MAREA 由 Microsoft、Facebook（现 Meta）与 Telxius 建设、Telxius 运营并批发容量，8 对纤里 Microsoft 与 Meta 各 2 对、Telxius 3 对，2018 年 2 月投运、4 月商用；它是 1999 年以来第一条建在北大西洋以南的跨大西洋缆，也是首个在海底线路上采用开放线路系统的系统；弗吉尼亚海滩一端有直达 Ashburn 的回程，而 Telxius 的拉美缆系 BRUSA、SAM-1 也汇到同一个登陆站。这些特征共同指向一件事：面向拉美方向的欧洲出口，和面向北欧方向的欧洲出口，本质上是两条不同的故障域。

所以结论不是一个城市名，而是一个判断顺序。先看用户方向权重，再定上岸点，再验内陆回程，最后才谈规格与冗余。如果你的用户主要在拉美与伊比利亚，南线的优势是结构性的；如果主要在西欧与北欧，北大西洋传统走廊更直接，内陆回程也更短；如果两边都不小，那就别在单个节点上做取舍，直接按双出口设计，并把「主备是否真的跨故障域」作为验收的第一条。

最后再提醒一句：路径选择解决的是结构性成本，解决不了本地接入质量。拉美用户最后一公里的体验、欧洲用户的家庭宽带状况，属于另一个层面的问题。把它们分开评估，判断才不会被单一变量绑架。

本文的 MAREA、Telxius 与对照系统资料来源

MAREA 海缆信息：缆长约 6,605 公里、8 对光纤、初期设计容量 160 Tbps 及商用后约半年提升至 200 Tbps、2017 年 9 月 21 日宣布建成、2018 年 2 月投运与 4 月商用、建设与运营方构成、纤对分配（Microsoft 与 Meta 各 2 对、Telxius 3 对），来自 SubTel Forum 海缆年鉴第 57 期关于 MAREA 的条目，该年鉴同时记录其设计容量为 209.6 Tbps。

MAREA 技术属性与建设动机：作为 1999 年以来第一条建在北大西洋以南的跨大西洋缆、首个在海底线路上采用开放线路系统（OLS）的系统、以及 2012 年桑迪飓风造成网络中断作为项目动机之一，来自 SubTel Forum 海缆年鉴与 Telxius 公开项目说明。

Telxius 设施与拉美缆系：在欧洲与美洲运营 26 个海缆登陆站与数据中心、毕尔巴鄂 Derio 通信枢纽与数据中心接入马德里/巴黎/伦敦/马赛、BRUSA（里约热内卢、福塔莱萨—圣胡安—弗吉尼亚海滩，约 11,000 公里，160 Tbps，巴西直连美国的第一条缆）、Tannat（巴西—阿根廷间新增容量）、SAM-1（环绕拉美约 25,000 公里环路）以及 Junior、Mistral、PCCS、Unisur，来自 Telxius 官方资料。

传输网升级：2026 年 Telxius 与 Nokia 在欧洲、美国与拉美陆地传输网部署 ICE-X 800G ZR/ZR+ 相干可插拔光模块（IP-over-DWDM），以及此前在 BRUSA 上完成 400Gb/s 单波长超过 5,600 公里的联合演示，来自双方公开发布的技术合作信息。

容量协议：2019 年 1 月 AWS 与 Telxius 签署 IRU 协议使用 MAREA 的一对光纤，来自双方公开的协议公告。

对照系统：Google Dunant 缆连接弗吉尼亚海滩与法国圣伊莱尔德里耶、2021 年投用、容量 250 Tbps、采用 12 对纤空分复用，来自 Google 公开的项目资料与 SubTel Forum 海缆年鉴。

登陆站背景：弗吉尼亚海滩此前并非跨洋缆主要入口、原先集中在纽约/新泽西、该站有直达 Ashburn（Data Center Alley）的回程，来自 Telxius 及行业公开资料。本文未引用任何未公开的测速、延迟、丢包或价格数据，涉及体验与成本的部分均标注为行业部署逻辑或「以实际合同为准」。