Uber的成长速度远远超出了IPv4的承载能力，为了更好地支持业务扩展，Uber的基础架构需要跟上用户增速的步伐，必须使用IPv6。2016年，Uber开始推行IPv6数据中心架构，通过对现有基础架构进行调整来促进业务的扩展。本文介绍了为适应Uber工程任务的成长，设计这一全新网络过程中所获得的最佳实践，以及通过对基础架构进行更新以支持IPv6过程中，Uber工程部门学到的经验。 2014年初，Uber宣布落地100个城市。而在2016年初，Uber已经遍及全球超过400个城市，不仅提供驾乘，还提供了其他类型的交通运输服务。与此同时，2015年新年前夜，我们达成了10亿次行程的里程碑，并很快于2016年6月达成20亿次行程。随着我们将服务扩展至更多城市，这个数字还会继续飞速攀升，我们也会继续以可靠的交通服务服务于全球用户。然而为了继续提高Uber服务的覆盖面，我们需要确保工作能够顺利应对IP协议方面遇到的一些挑战。
Uber目前的基础架构建于Internet协议版本4（IPv4）地址标准的基础之上，包含多个数据中心，使用了少量网络入网点（POP）和云服务。然而Uber的成长速度远远超出了IPv4的承载能力，为了更好地支持业务扩展，我们的基础架构需要跟上用户增速的步伐，必须使用下一代IP：Internet协议版本6（IPv6）。
2016年，Uber开始推行IPv6数据中心架构，通过对现有基础架构进行调整来促进业务的扩展。本文中，我们将介绍为适应Uber工程任务的成长，我们在设计这一全新网络的过程中获得的最佳实践，以及通过对基础架构进行更新以支持IPv6过程中，我们学到的经验。
根据互联网协会（ISOC）的介绍，IPv4总共43亿个地址已于2011年2月全部耗尽。IPv4地址总数超过40亿个，远远比不上全球移动设备总数。再考虑到物联网（IoT）设备的飞速增长等因素，我们很快将发现自己开始面临IP地址“饥荒”。
2011年，全球五大区域性互联网管理机构（RIR）中的三家，包括亚太网络信息中心（APNIC）、Réseaux IP Européens（RIPE），以及拉丁美洲和加勒比网络信息中心（LACNIC）已彻底分配完了自己所有可用IPv4地址。2015年9月24日，美国互联网号码注册机构（ARIN）也宣布自己的全部IPv4地址已耗尽。
早在1996年就已制定的Internet协议版本6（IPv6）是目前最新版的Internet Protocol（IP）地址标准，提供了大量可解决IPv4所面临诸多弊端的功能，如更大的地址空间、一种多播基础规范，以及无状态地址自动配置（SLAAC）。IPv6可容纳超过340涧（Undecillion，10的36次方）个地址，这一数量已经远远超过目前全球所有用户，当然也包括Uber自己对IP地址的需求。
APNIC制作的一个地图（见上图）显示了全球不同国家目前的IPv6部署，很多国家目前的部署依然为零，而比利时已经超过了56%。互联网协会在2011年进行的全球IPv6使用情况调查发现，自从2012年起，全球主要ISP运营商，尤其是美国的运营商在部署IPv6方面开始加快步伐。北美运营商目前的IPv6部署范围从27.93%（Cox Communications）到84.36%（Verizon Wireless）各异。
调查还发现，整个互联网上的IPv6流量正在稳步增加，然而依然远低于IPv4流量。更重要的是，2017年4月，Google称其用户中使用IPv6的比例已达16%，依然使用IPv4的比例为84%；类似的，Web信息公司Alexa称截止2017年3月8日，全球排名前1000位的网站中，只有不到20%的用户在使用IPv6。
专为2014年美国计算机协会大会撰写的Measuring IPv6 Adoption一文预测说：“到2019年，已分配的IPv6前缀数量将约为IPv4的.25-.50，而届时IPv6与IPv4流量的比例约介于.03到5.0之间。换句话说，IPv6流量依然只在总流量中占据很小的零头。”这些结论建议，按照目前的增速，全球对IPv6的接受速度过慢，已无法适应整个世界对网络连接快速增长的需求。
目前Uber运维着数万台服务器，整个网络共承载了超过8百万个IPv4地址。
2014年之前，Uber的数据中心托管在第三方。为满足我们对容量的需求并为用户提供更可靠的服务，我们在2014年建立了自己的首个北美数据中心。2015年，Uber对北美数据中心进行了扩展，在美国东西海岸建立了更多数据中心；2016年，Uber建立了几个网络POP点，并将其扩展至云中。随着2017年来用户数量持续激增，IPv6部署已开始成为我们后续扩展过程中的关键一环。
对我们来说，为了维持大规模架构的可靠性，在整个网络中部署IPv6主要有三个原因：
更“慷慨”的IP分配：过去几年来，我们的网络规模增速飞快，数据中心内服务器机架数已达数千个。我们会从自己的Request for Comment (RFC) 1918 IP空间内为每个机架分配一个/24 IP子网，而目前机架中仅剩48台服务器。
资源局限：增长到目前这样的规模后，我们现有的10.0.0.0/8 IPv4子网中已经有超过50%的地址被用于内部用途。如果不过渡至IPv6，我们的RFC1918（互联网工程任务组（IETF）有关私有IP地址分配方式的备忘录）地址空间很快就会耗尽。
IP地址重叠：按照传统，Uber的网络中为自己的资源定义了自己的IP地址。当Uber开始与其他公司合并时，不同机构的两个内部网络中会出现一些重叠的IPv4地址。
经过全面研究、测量以及其他分析后，我们意识到为了支持IPv6部署，我们的基础架构还有三大领域需要进行更新：
首先，我们将介绍Uber数据中心网络中上述三方面内容的构成，随后将介绍如何面向IPv6的部署做准备。
Uber的网络架构包含三个主要部分，接下来分别介绍下。
Uber使用了统一且一致的硬件，这样可以更容易地实现模块化、可伸缩的数据中心设计。每个设备通常会使用相同型号的硬件，因此可以很容易地根据需求进行伸缩。我们的网络设备可支持通过100G/50G/25G以太网下行链路连接至服务器。
以Uber的系统规模来说，网络的构建、管理和运维必须使用自动化工具。我们的网络数据中心可使用零接触供应工具自动构建，日常网络管理工作中可通过内部开发的自动化工具管理网络配置和IP地址，此外如果哪里出现问题，智能监视工具可以向我们发出通知。
我们数据中心的设计符合IETF RFC 7938所定义的Clos设计，“在大规模数据中心内部使用BGP进行路由”，该设计方式决定了我们需要使用边界网关协议（BGP）作为动态路由协议。按照网络架构，我们使用了对分（Bisectional）带宽，可快速收敛（Convergence）并且故障域很少。此外我们还通过构建网络过程中使用的功能集实现了不同供应商产品的互操作性，如下所示：
在Clos设计的基础上，我们将整个数据中心划分为模块化的Pod和集群。每个Pod包含相同数量的服务器机架，每个集群包含多个服务器Pod。因此整个网络可拆分为多个小规模但完全一致的单元，所有Pod之间统一使用高性能网络进行互联。Uber的数据中心包含多个集群，所有集群连接至我们的边缘骨干网络，进而连接至互联网。
为了向Uber的网络提供足够的带宽，包括向Hadoop等主要的内部“东西”流量提供支持，我们的集群架构使用了一种1:1无闭锁（Unblocking）网络模型，例如下图展示了我们设施内部的IPv4网络架构：
为了在维持冗余的同时尽可能让每个网络层实现最大化的带宽共享，随后我们还在网络设计中引入了一种Fabric plane的概念。另外，1:1的无闭锁超额开通（Oversubscription）率意味着任何服务器主机均可在维持自己端到端上行带宽的同时与这个IP设施网络内的其他任何主机通信。
为了在这种网络架构中部署IPv6，我们为每个服务器机架和集群指定了要分配的IPv6地址，其中服务器机架会被分配一个/64 IPv6子网，集群会分配并汇聚至子网/n，其中n
由于我们的数据中心网络是模块化的，使用了模板化的配置，并且我们的Clos设计自上至下只使用了一种协议：外部边界网关协议（eBGP），相比在从IPv4迁移至IPv6过程中需要重新配置协议的网络设计，我们可以快速简单地为所有机架分配原生IPv6地址。我们数据中心集群的每个组件，例如机架子网、Pod子网、环回、带外（Out-of-band）子网，以及点对点子网均使用了相同的IPv6分配过程。这些自动化的IPv6地址生成工具使用了与我们的IPv4地址分配架构类似的逻辑。
最后，我们的骨干网络所用的诸如BGP和IS-IS等路由协议可以很轻松地通过更新支持IPv6，在运维方面不会产生太多额外的工作量。
为了顺利部署IPv6，还需要对整个网络对软件的支持情况进行更新，尤其是可提升IPv6流量的软件更是需要重点处理。为软件实现IPv6的支持需要不同团队通力协作，涉及到Uber的多个团队，包括安全工程团队和站点可靠性工程团队。
一些工程师所接受的培训只介绍过如何编写仅支持IPv4的代码，因此他们针对IPv6兼容性开发的应用程序和工具也能支持IPv4。IPv4和IPv6地址无论地址长度、前缀，以及表现形式等方面都有很大差异，例如在从纯IPv4代码迁移至可支持IPv6代码的过程中，我们遇到了一些常见的应用程序问题，包括：
代码将前缀长度设置为常见的IPv4前缀，例如/24，无法适应IPv6前缀的长度。
会将“a.b.c.d”拆分为”（“a”、“b”、“c”、“d”）元组（Tuple）的代码将无法识别IPv6地址，因为拆分是以分号“:”而非句号“.”为依据的。
需要将“主机：端口号”，例如“a.b.c.d:8080”拆分为“a.b.c.d”，“80”的代码遇到“[2002:a:b:c::ff]:8080”之后会出错。同理，需要将“a.b.c.d”，“80”组合为“a.b.c.d:8080”的代码遇到“2002:a:b:c::ff:8080”会创建出无效的IPv6地址。
使用regex匹配IPv4地址的代码在收到IPv6地址后会给出无效的结果。
通过硬编码方式指定尺寸的列将IPv4地址存储为“varchar(16)”的数据库，会由于“a.b.c.d\0”问题而无法存储IPv6地址。
Uber的基础架构使用haproxy在不同地区进行路由。我们广泛使用诸如haproxy.cfg yaml等配置（config）文件将不同IPv4地址与对应的主机名存储在一起。所有服务的配置文件也需要仔细检查，并根据不同用途进行更新，以便在为所有主机启用IPv6后支持IPv6地址。
我们并未使用硬编码的方式指定IPv4地址，而是在代码中使用主机名，随后通过DNS解决过渡期遇到的问题。目前我们正在对开发者进行培训，告诉他们如何使用诸如getaddrinfo(3)等IPv6相关支持工具促进整个过渡进程。
大型网络设备和服务器硬件供应商多年来一直在积极地为IPv6提供着支持，并且已经顺利实现了大量IPv6特性。然而考虑到生产环境中使用IPv6的历史并不长，并且大家普遍缺乏相关运维经验，随着越来越多的组织开始在生产环境中部署IPv6，大家陆续发现了很多bug。IPv6的质量保证（QA）需要努力与IPv4看齐。
随着越来越多的组织将服务部署在云端，Amazon AWS、Google GCP，以及Microsoft Azure等云供应商也加快了对IPv6的支持步伐。
Uber目前正在以设计文档，包括IPv6寻址机制和特性RFC为指导，对IPv6部署进行实验室测试。在全面将IPv6部署到生产环境之前，为了发现任何可能存在的问题，还需要在准备环境中进行深入的负载测试。
我们预计可以通过全面部署IPv6立刻获得下列收益（包括但不限于）：
前端：前端将可以直接为原生IPv6流量提供服务。
组织合并：面对相互重叠的IPv4地址，IPv6为我们提供了更具伸缩性的解决方案。
车辆上下客：目前，Uber为自有车辆提供的车载设备底座会被解析至一个/24 IPv4子网。当前的这种设计是为了预留IPv4资源同时确保不同工程项目一致的配置。然而IPv6可以通过设备底座为车辆上下客网络架构提供一种更具伸缩性的解决方案。然而需要注意，仅在用户的iOS或Android软件能够支持的情况下才可以在上下客网络中使用IPv6。
企业内部的IPv6部署需要大量规划，绝不是一种“要么全有，要么全无”的实现。为了对网络连接以及技术创新的飞速增长提供更广泛的支持，我们鼓励开发者在应用程序层面编写能同时支持IPv4和IPv6的代码。同时我们也希望您能与我们一起在自己的技术圈里推动IPv6的更广泛部署。
随着多方的不断努力，早期“尝鲜者”所组成的社区所产生的统计结果和指标也将帮助我们进一步优化IPv6的相关设计和性能，等到IPv4彻底耗尽那天再着手进行就来不及了。通过携手努力，我们将能共同打造一个更好的互联网世界。
原文地址：https://eng.uber.com/ipv6/
今日荐文
点击下方图片即可阅读
今年，架构师关注的技术点有何不同？从云计算、大数据、微服务、容器，到现在的人工智能，架构师应该怎么做？这里推荐一场会议，为你总结了100+国内外技术专家现阶段的架构实践，8折即将截止，点击“阅读原文”，看看对你有何启发。
