作者|陈佑雄
编辑|林颖
供稿|eBay Network SIG/PaaS Team
本文共10899字，预计阅读时间20分钟
边缘节点，又被称为POP(point-of-presence)节点。通常，边缘节点设备更接近用户终端设备，其主要作用是加快终端用户访问数据中心网络资源的速度。从节点构成上来说，边缘节点一般是由缓存设备和负载均衡设备组成。
用户在访问时，相当于将访问请求发送出去，这个请求会如上图所示路径一步步传递，最后进入数据中心。
这里的边缘节点是分布在全球各地的。它们通常是租用ISP（互联网服务提供商）机房的若干节点和专线，然后在这些节点上部署具有负载均衡功能的软件，最后将这些节点变成用户访问eBay的接入点。
另外，POP节点也提供缓存(caching)功能，将用户访问的内容保存到缓存服务器。当用户请求命中缓存后可以直接返回，这样也能减少网络延迟，并且改善用户体验。
云原生网络(Cloud-native Network)是指：结合云原生的特点，采用云原生部署的方式来构建的网络。这些提供负载均衡功能的云原生网络应用需要运行在Linux容器，比如Kubernetes集群。而在云原生网络实现之前，它们要运行在专门的物理设备上，如硬件负载均衡设备。
通过云原生网络，我们期望边缘节点能够具备以下特征：
1）全球分布(Globally distributed)
从地理分布角度来看，边缘节点能够更加接近我们的客户，遍布全球各地，这样就能得到更低的网络延迟和更好的用户体验。
从运维的角度看，期望节点是易扩展的，这样便于流量迁移和管理，可以更加灵活地管理边缘节点内部的流量。
边缘节点能根据流量模式按需扩展，以有效处理负载。通常硬件设备的带宽是固定的，但是基于云原生网络，我们能够实现总带宽的弹性伸缩。
可抵御已知的网络安全威胁（如DDOS攻击），同时也能够提供高安全性的端到端加密网络。
UFES(Unified Front End Services)是一个eBay进行了很多年的项目（于2017年启动），旨在构建一个基于云原生网络(cloud-native network)的低延迟、高稳定性的网络前端和边缘计算平台。也正是通过这个项目，我们搭建了大量的边缘节点，并且在这些节点上部署了能实现L4和L7负载均衡功能的软件（其中L4的实现是基于IPVS，L7的实现基于Envoy）。这里L4负载均衡主要是指对OSI网络模型中的传输层负载均衡，常见的协议如TCP；而L7负载均衡主要是应用层，常见的协议如HTTP。
UFES项目主要针对于eBay的公网流量。eBay公网流量主要来自下几个领域:
指通过桌面浏览器访问的流量，即主站(www.ebay.com) ，也称之为SEO/dweb域。
指通过手机浏览器访问的流量，即通过手机浏览器访问m.ebay.com，也称之为mweb域。
指通过安卓或者ios的eBay应用来访问eBay的流量，这里主要都是api接口的调用，主要访问的地址是api.ebay.com。
在启动UFES项目之前，eBay的公网流量都是经过边缘路由器(Edge router)来接入边缘节点的。边缘节点是由工作在Active-Standby模式下的Netscaler硬件负载均衡设备对组成的。我们给不同的域名配置了一组专有的硬件负载均衡设备。比如对于桌面端主站，我们在全球配置了十七组设备，这就意味着全球用户都是通过这十七个边缘节点访问eBay主站。这些硬件在负载均衡上面，配置了大量的L7转发规则，比如在桌面端主站上面配置了以下规则：
① www.ebay.com/itm/—>将请求转发到详情页
② www.ebay.com/sch/—>将请求转发到搜索服务
所以在www.ebay.com的后端其实有数百个应用在为它提供服务，这些应用虽然没有通过暴露公网地址的方式直接接收用户请求，但是利用边缘节点设备的转发规则，最终为全球用户提供服务。
因此，基于硬件负载均衡的网络架构为下图2-1所示，其中GTM是一个智能的DNS，能够对后端VIP（虚拟IP）进行健康检查，基于VIP的状态决定是否返回给用户，而Akamai是CDN服务提供商。
图2-1 基于硬件负载均衡的网络架构
(点击可查看大图)
② 接入点VIP数量少，比如在桌面应用端，我们只配置了3个VIP。
③ L7规则多，包括响应规则（如重定向）以及转发规则（如转发到后端不同应用）等，3个大的公网域总共配置了将近4000条L7规则。
由于eBay传统的边缘节点是基于硬件设备基础上的，而这种专门的物理设备除了价格很贵以外，在实际应用中还会遇到以下一些挑战：
① 硬件负载均衡器具有较高的运行和配置成本，且不支持弹性扩容，这就导致在购物季流量过高时，我们需频繁迁移VIP。
② 由于设备工作在active-standby模式，无法提供高可用性，其对故障域处理是的1+1而非N+1，也就是在一个边缘节点不能接受1台以上宕机。
③ 依赖第三方供应商来提供核心前端流量管理功能，配置不够灵活。
④ eBay的应用基于微服务架构，这种微服务的体系结构会导致负载均衡器数量的增加，因此使得eBay拥有超过3,000个的公网VIP。
⑤ 边缘节点全球分布数量有限，而且硬件负载均衡PoP配置需要消耗较多的人工、时间和成本，边缘节点数量无法满足全球所有用户流量需求，特别是在美国以外地区。
正是因为硬件负载均衡设备存在着种种问题，而且公司的方向是将所有的应用都迁移到Tess （eBay的kubernetes），即迁移到云原生，也包括网络的云原生。其中最重要的一个目标便是将边缘节点的硬件负载均衡设备替换成能够支持k8s原生部署的软件实现。
为了满足上述目标，基于云原生网络的边缘节点架构如下图所示，其中边缘节点被拆分成两部分：前端代理(Front Proxy)以及数据中心网关(DC gateway)。
图3-1 云原生网络的边缘节点架构
(点击可查看大图)
前端代理(Front Proxy)是一层软件负载均衡。它连接着用户和eBay，是所有进入eBay流量的前端代理。这一层部署在所有的边缘节点和数据中心，主要代理公网的流量，包括桌面端、手机浏览器端以及原生手机应用端。前端代理的主要功能如下：
① 能够在离用户最近的地方做SSL卸载，减少TLS连接建立的时间。
③ 为公网 VIP 启用任播(anycast)技术。
⑤ 顶层轻量化，大大减少前端代理的上游集群和L7规则。
除上述之外，前端代理还有容灾、故障恢复和流量管理的功能。这是因为这一层的流量会跨数据中心。这就意味着，即使后端应用的某个数据中心出现故障，只需要将该数据中心的VIP停止，也不会对用户造成数据面的影响，包括DNS缓存（TTL和客户端缓存）带来的影响。
这一层在UFES项目早期并没有设计，它的主要是作为数据中心的接入层，将前端代理的流量转发到后端的应用集群。我们在每一个可用区配置一个网关，而所有的转发规则都配置在数据中心网关。这一层的流量也是跨数据中心的，其权重比例为：本数据中心承担99%流量，远端数据中心承担1%流量。
① 支持云原生的L7规则管理系统，核心功能不再依赖硬件设备提供商Netscaler。
② 为公网和内部的4层和L7的流量提供更多的可见性。
③ 基于Envoy，能够提供如授权/身份验证、速率限制等功能。
④ 替换服务公网流量Web层的硬件负载均衡设备，有了数据中心网关后数据流路径如下：
传统的硬件负载均衡设备能够同时管理L4和L7的流量。举个典型的例子，我们可以创建一个TCP协议的VIP，用来管理只有L4流量的场景；另外也可以创建HTTP协议的VIP，用来管理L7规则，支持TLS等等。然而在软件实现上，L4和L7需要分别采用不同的技术实现，这里我们用到的是IPVS和Contour/Envoy。
L4这一层主要负责TCP包的转发，我们在选择L3/L4软件负载时的主要考虑因素如下表所示。对比了IPVS、Netfilter、OVS和EBPF四种软件负载，从技术成熟度以及社区接受度来看，IPVS皆表现较高。
对于L4组件控制面（如图4-1），这里的L4 Director是复刻了google的开源项目“seesaw”并进行了定制，L4 director会在用户空间生成IPVS 服务的哈希表，并基于Linux内核通信的 Netlink 套接字，发送到kernel，更多细节可以参考作者之前一篇博客。
4.2 基于Envoy/Contour的L7负载均衡
L7主要负责L7规则的转发、TLS卸载、限速以及安全相关的授权和认证等等。在选择L7的数据面的时候，主要的考虑因素如下表：
考虑到Envoy能够支持热部署、可观测性、可恢复性、多种负载均衡以及强大的L7支持等特征（如上表所示），并且Envoy是为云原生应用而生，基于Envoy的微服务架构，服务网格是云原生网络的一个发展方向，而且其本身已在eBay生产环境上应用过，这些都促使了我们选择Envoy作为数据面。
由于因为早期的社区方案不是很成熟，我们用的是自定义的Ingres Controller和IngressRoute。而在前两年我们把IngressController换成了社区的Contour，这是因为Contour本身代码相对Istio要简单很多，而且定制起来也比较容易，没有必要再去维护Ingress Controller。
基于Contour的架构图（如上图4-3所示为），Contour作为边缘网关L7控制面，主要功能包括以下几点：
②实现Envoy xDS，将IngressRoute配置推送到Envoy。
4.3 基于IPVS和Contour的边缘节点架构
有了L4和L7的软件实现之后，完整的边缘节点架构图如下图4-4所示：
其中，基于IPVS的L4负载均衡模块主要有以下几个特点：
① 自定义的一致性哈希kernel模块作为IPVS调度器，这保证了同一个五元组会被转发到同一个后端服务器。
③ 可水平扩展，可通过扩容的方式增加集群数量，以提高整体带宽。
④ 支持直接服务器返回(Direct Server Return) ，用户请求会经过IPVS Pod到达后端服务器，服务端直接返回。
⑤ BGP宣告VIP网段到路由器，通过ECMP支持多活。
而基于Contour和Envoy的L7负载均衡模块主要有以下几个特点：
① Contour管理边缘节点L7规则，负责将IngressRoute转换成Envoy配置。
④ 不同领域配置专有L7集群，实现数据面和控制面的隔离。
虽然边缘节点被拆分成了前端代理和数据中心网关，但是它们控制面的架构其实是完全一样的，都是通过L4集群和L7集群组成的。主要区别在于：
① 前端代理分配公网IP作为服务的VIP，而数据中心网关分配私有IP作为服务VIP。
② 两者的L7规则配置是不同的，其中响应规则配置在前端代理，转发规则配置则在数据中心网关。
基于前端代理和数据中心网关的边缘节点部署架构如下图4-5所示。目前我们已经在全球各地部署了超过20个POP：
缓存(caching)是边缘节点提供的另一个重要的功能。它通过在边缘节点提供动态负载缓存功能，以减少由底层网络和后端系统引起的延迟，来改善用户的体验。通过缓存，主要能实现以下几个目标：
① 提高访问速度，在 POP缓存动态页面的静态部分，测试显示延迟减少了500-700毫秒。
UFES边缘节点缓存实现的架构图如上图5-1所示。其中，MTBB(Multi-Tenant Backbone)是eBay的骨干网络。Tracking是一个sidecar，用来管理用户请求的多个调用的状态。EP(Experimentation Platform)服务会给用户请求生成一个ID，后续会基于这个ID判断页面是否缓存在ATS。ATS(Apache Traffic Server)提供缓存功能。
ATS管理缓存对象的全生命周期，包括Hit、Miss、Age、Refresh和缓存对象操作，为了实现缓存的功能，需要定制Envoy过滤器以支持如下功能：
① 识别支持缓存的应用和URL，比如url-path（以“/b”开头被标记为支持缓存）。
② 调用 Orchestrator，根据请求的headers, url 生成 ATSKey。
③ 调用ATS，输入ATSkey，响应是否命中缓存。
④ 修改响应，包括解析修改html内容，修改header和cookie。
前面介绍了很多UFES相关的背景，而UFES更接近于底层。接下来，我们要解决PaaS这一层的问题：
① 如何将硬件负载均衡设备上的L7规则全量迁移到软件负载均衡？
② 在迁移阶段，如何同时对软件和硬件负载均衡上的L7规则进行管理？
这里就需要提供各种自动化的API和工作流来对软件负载均衡进行初始化和管理。
举一个形象的例子，PaaS这一层需要造出一栋几乎和老房子（硬件负载均衡设备）一模一样的新房子（软件负载上的配置），而UFES就像是房子的砖和瓦。同时，PaaS这一层像胶水层一样，需要把各个组件集成到一起，重新打包成一个新的面向用户的功能，但是各种组件的问题也都会在这里放大。
假设每个依赖的组件提供的稳定性是99%，如果有十个依赖组件，那0.99的10次方是大概是0.90，也就只能90%的稳定性。这是PaaS层遇到的问题，也是微服务带来的一个挑战。
Zebra是eBay一套PaaS系统，主要作用是创建应用以及管理虚拟机/Pod集群、负载均衡和DNS。这套系统定义了一套工作流程，并且利用spring quartz进行任务的调度。L7规则的各种自动化也是基于这套系统。
自动化的第一步是需要定义一种资源，用来描述L7规则。这里我们定义了一套IngressTemplate，有点类似k8s里面的Ingress，但是这套IngressTemplate是定义在内部一个基于MongoDB的配置管理系统(Configuration management system，CMS)。
这里我们实现了一套基于antlr4的分析语法器，能够将Netscaler DSL的L7规则转换成我们的IngressTemplate，举个例子，下面为Netscaler DSL的L7规则。
基于antlr4的分析语法器能将上述L7规则转换成Json格式的IngressTemplate（如下图所示）。
这么做的主要目的是为了能够将L7规则与某一种特定的领域专用语言(domain specific language/ DSL)解耦，并且能够将这套IngressTemplate很容易地转换到其它的L7进行实现。另外，Netscaler的L7规则实际上是一个逻辑表达式，而且这种解析应用更加灵活，比如A||B与B||A转换出来的IngressTemplate是一样的。
我们在Zebra上提供了大量的API，用来管理L7规则，主要包括:
① 支持对硬件和软件负载均衡的L7规则创建和删除。
② 支持初始化一个软件负载均衡，相当于把硬件上的L7规则全部拷贝到软件负载均衡。
下图6-1是各个组件之间调用的架构图。其中，WISB(what it should be)有点类似于k8s里面的资源定义，而WIRI(what it really is)是指实际的硬件配置。
软件负载均衡设备通过PaaS自动化配置完成后，还需要做的一件事情是运行流量验证(traffic validator)，并通过自动化的CI运行。
它的工作原理是抓取生产环境下真实的用户访问记录，并提取出URL访问的模式且记录下相应的返回码，然后将同样的URL集合在新创建的软件负载均衡上运行一遍。如果返回码完全匹配，则认为通过验证；否则可能是有某些L7规则出现不匹配，这就需要查找原因并重新配置。
在迁移阶段，软件和硬件负载均衡会同时服务生产环境流量。在这一段时间，如果有L7规则的变更，那么就需要同时配置在软件和硬件负载均衡。同时，为了管理员能够更加方便的管理，我们开发了一个L7管理终端，支持管理员同时操作软件和硬件负载均衡，下图6-2是管理终端的一个界面：
在L7管理终端上提供了多种功能，主要包括以下几点：
① 统一管理软硬件负载均衡。这里通过LBMS，对软件硬件负载均衡设备，提供统一的API适配。这对管理终端来说，对软件和硬件负载均衡操作是完全兼容的。
② 定义多种发布策略。在发布新的L7规则的时候，可以支持单个设备发布，也可以支持分组多设备发布。
现在再回过头来看整个PaaS的集成，其实一开始并不符合云原生的原则。虽然我们定义了WISB，但这本身还是一个命令式(Imperative Programming)而非声明式(Declarative Programming)的编程。这里将IngressTemplate保存在私有的MongoDB(CMS)。整个Zebra系统在某种意义上，变成了一套k8s里IngressRoute的spec builder，因为Zebra最终的输出是通过LBMS创建很多k8s的Service以及IngressRoute。这样导致的结果是，我们需要为了适配不同的场景，而往Zebra堆加很多功能。这些功能虽然也带有流量管理、服务发现机制，但是最终它只是某种意义上的一个迁移的工具，很多功能当某一天迁移结束后也就失去作用了。
另外一方面，这里又涉及到业务驱动和技术驱动的差别。前者见效快，但是长期的投入会比较多；后者见效慢，而且投入会比前者更多，但它会去构建一些核心的和高频使用的组件。正如Jian总说的，越是被高频率使用的组件我们越会有更多的机会去迭代和增强，而且其生命周期也是最长的，这才是最值得长期投入的。
PaaS的集成其实也是一个业务和技术的妥协，早期在技术并不很成熟的情况下先保证业务，后续再逐渐将控制面也迁移到k8s。在eBay的应用上，在k8s的时候也遇到了同样的问题，一开始我们的平台部门还没有适配原生部署，所以我们采取的方式是同化方式（内部称为assimilation），也就是启动一个fat container，这个container和VM行为几乎完全兼容，Pod启动之后并没有部署代码，而是通过fat container里面的Agent去部署应用。目前我们正在面临的问题是如何将这一套同化的方法再迁移到原生部署上。
所以如果能再有机会重新开始一次，我觉得有几点是我们可以重新考虑的：
① 在Tess构建Federation的IngressRoute。如此一来，我们只需要维护一份Federation的IngressRoute，在新增PoP的时候自动同步到新的k8s集群，并且相应的控制器会去配置IPVS和Contour，而不需要每次需要在创建新的POP的时候再去通过Zebra的自动化重新生成IngressRoute spec。
② 构建k8s的控制器来自动发现并且生成IngressRoute。一方面它能初始化L7规则的spec；另一方面，我们也可以利用这个控制器检测实际配置和spec不一致的地方，长期发挥作用。
③ 项目启动之初需要多思考一下终态，只有清楚了终态才能知道什么东西会留到最后。如果确定了技术方向，对于最终的远景我们也需要有比较清晰的认识，并为此做一些长期的投入，再以此为基础去做一些工具集成和功能实现。
为了满足eBay实际的业务需求，原本硬件负载均衡设备上所有我们已使用到的功能，在软件负载均衡上也需要有相应的实现。但是社区并没有我们这么复杂的使用场景，这就需要我们对L7的控制面Contour和数据面Envoy都做相应的定制。
IngressRoute是Contour引入的一个定制资源定义，因为k8s支持的Ingress资源能够支持的用户场景有限，为了适配eBay的用户场景，我们给IngressRoute做了大量的定制：
1）定制apiVersion为contour.ufes.io/v1 beta1
通常每一个VIP会有两个IngresRoute，一个配置了80(HTTP)的L7规则，一个是443(HTTPS)的。这里是一个IngressRoute的示例:
从这个扩展资源中，我们可以看到，我们给IngressRoute增加了很多属性。如additionalProperties，这是用来记录硬件设备上的L7规则名字以及优先级的。另外，我们还定制了安全相关的filter，用来重启或者丢弃用户的请求。在硬件负载均衡设备上，每条L7规则都会有一个名字以及执行的优先级，而IngressRoute上Route配置的顺序决定了执行顺序，所以需要在生成Route的时候根据优先级做好排序。
HTTPMatchRequest其实是Istio VirtualService里面的功能。因为Contour社区只支持简单的Prefix匹配，我们通过引入HTTPMatchRequest，就能够支持更加复杂的规则，比如以下的一些常见的规则：
这里我们也可以看到IngressRoute同时还能支持IngnoreCase，但社区目前还不支持。
3）IngressRouteSpec增加Listener
eBay的每一个公网域通常有多个VIP（如桌面浏览器端分配了3个VIP），需要支持Envoy监听在不同的VIP，这里给IngressRouteSpec增加了Listener:
这样做的目的是为了让Envoy能够监听在独立的VIP，社区默认Envoy会监听在0.0.0.0，这样也就导致我们必须要使用SNI，并且无法对单个的VIP进行管理。这一点对于独立的流量管理非常重要。假如我们使用SNI，也就是将多个VIP的L7规则合并到一个listener 0.0.0.0:443，如果其中某一个VIP出现了问题那我们将无法把这个VIP停止。
下面是使用了独立的listener之后我们可以看到Envoy监听在不同的VIP：
4）支持Weighted Endpoint以及停止Endpoint接收流量
为了实现高可用性，eBay的生产环境流量大部分是跨三个数据中心的，而且需要支持本数据中心99%流量和远端数据中心1%的流量。假设每个数据中心有一个入口VIP，需要支持不同VIP的权重不同，并且能够支持某一个数据中心流量的停止。
UFES的做法是，给前端网关创建一个k8s Service，它的ExternalIP就是公网的IP，而这个服务的Endpoint是由PaaS层维护的，里面通常是三个数据中心网关的私有IP，并且在Endpoint标记如下注释所示:
然后修改Contour的EDS，能够适配Endpoint的annotation并将值推送到Envoy:
最终更新的是Envoy Clusters的upstream hosts状态，如表7.1：
表7.1 Envoy cluster upstream hosts属性
社区的实现是将证书和key都保存在k8s的secret里面，但是这种方案并不能满足我们对于证书保密的要求。我们要求：哪怕是通过加密的方式保存，key不能落盘。而实际上secret也是一种明文的方式保存，通过base64解码就能得到了。
1）Envoy重定向支持prefix_rewrite/strip _query
这种应用场景是，L7规则需要先根据前缀重写URL，再做重定向。这里对Envoy的定制是能够根据收到的请求动态生成重定向响应，我们在重定向下添加了一个新的配置：prefix_rewrite。同时为了删除重定向的查询字符串，我们添加了一个新标志：strip_query，然后再执行重定向。
这个PR已经合并到社区：https://github.com/envoyproxy/envoy/pull/2661
2）支持通配泛域(wildcard domain)作为默认路由
假设Envoy配置了以下两条路由，如果我们去访问http://nomatch.com/api/application_data， envoy会因为匹配不到路由，从而返回404。
在source/common/router/config_impl.cc，相应的改动为：
3）创建Envoy HTTP filter根据 L7匹配执行Drop和Reset
Drop和Reset是已经负载均衡设备上两种很常见的响应行为。顾名思义，它能够将用户的请求直接丢弃(Drop)或者重置(Reset)。这种一般是和安全有关，比如检测到攻击时，我们可以创建一个L7规则快速地将请求丢弃掉，而不会对后端服务器造成压力。
这里主要创建了一个access_control_filter.cc的HTTP过滤器，其主要代码如下：
正是因为有了这个过滤器，我们可以在IngressRoute里面使用reset/drop的服务，用来执行重置和直接丢弃请求的响应。
UFES对于Contour和Envoy的定制和扩展其实不止我提到的这些。有些扩展已经回馈到社区，而有的可能并不适合社区，但是这些都是为了解决了我们生产环境的实际问题。因为社区开源的项目更多的是将不同应用场景和环境下的公共需求加以提取、抽象并且实现。而对于这种定制的需求，只能根据业务的需要进行定制开发，而这也是能够用好开源项目的一个必要条件。
到目前eBay三大公网域的流量已经全部迁移到软件负载均衡设备，每天都能接收几十亿次以上的用户进入数据中心的请求，而且我们已经停止购买边缘节点的硬件负载均衡设备。云原生网络最大的好处是：它能够通过开源软件的方式，实现黑盒硬件所提供的功能，并在性能上没有损失，还能实现弹性扩容。由此可见其好处，是值得长期投入的。
UFES项目在这一方面是eBay的先驱，它本身有很多不完美的地方，比如各种显得有些随意的注释；没有定义完整的资源模型；甚至VIP之前都是人工分配；随着VIP的数量增多以及配置量的增加，控制面也有性能的问题正在解决。一部分的原因是因为在项目启动初期，社区的方案都还没有成熟，比如k8s的Ingress controller至今还没成熟的方案；另一个原因是因为eBay有一些定制的需求也是社区没有考虑到的，但是这个项目还是成功的，它在生产环境上稳定运行将近一两年并没有出大的事故，这在给我们积累信心的同时，也证明云原生网络这条路是有希望的，进而也促进我们决心实施的另外一个项目——旨在替换数据中心的硬件负载均衡设备的基于Istio/IPVS的应用网关。
另外一点是，UFES这个项目是经过多个阶段的迭代，比如第一个阶段只是建立一些基于硬件负载均衡设备的POP，带来的收益是：桌面应用端访问延迟减少了200+毫秒；手机浏览器端减少了160+毫秒。而第二个阶段是在边缘节点实现软件的负载均衡，花费了将近两年的时间，这一个阶段还经历了将边缘节点拆分成前端代理和数据中心网关。第三个阶段是动态内容缓存以及网页内容预取(Content Pre-fetching)。第四个阶段是全面接管公网的VIP以及集成anycast，这个也是我们目前正在做的，这使得公网的流量被全面通过软件负载均衡接管，大大节省了购买硬件负载均衡设备的开销；另外通过任播技术，这样不仅提高了网络的可用性，还减少了网络故障收敛的时间。
这个是目前我们正在进行中的一个项目，有个别的公网应用已经启用了anycast，通过anycast可以带来以下几个好处：
a. 更好的故障恢复能力，通过在多个数据中心配置同一个anycast IP，即使一个数据中心宕了也不会造成数据面的影响，而且故障路由收敛速度更快。
b. 通过应用共享公网anycast IP可以减少IP数量，能够将长尾应用合并。
c.更低的延迟。我们比较了anycast和现在的unicast，整体上用户的访问速度提升了10%以上。
2）将公网流量接入数据中心基于Istio的应用网关。
在UFES项目中我们实现了边缘节点的云原生网络，但是数据中心的应用架构还是基于两层的硬件负载均衡设备。未来的目标是：将数据中心的硬件负载均衡也迁移到云原生网络上。
这个项目的PaaS集成，作者从开始就参与进来，深刻体会了其中的艰辛。一方面是要实现各种自动化和各种集成，开发任务很重。另一方面要承担部分OPS的工作，包括几十个SLB，每个SLB又有若干个VIP需要自动化的初始配置，而且一旦遇到UFES的问题还需要来回多次配置软件负载均衡设备。更重要的一点，还有site incident的“达尔摩斯之剑”，公网流量的管理没有小事，所以能走到现在这一步真的很不容易。
虽然这个项目的执行过程比较艰辛，并且如正文所说的这个项目存在一些不完美的地方，但是从结果看这个项目还是成功的，所有为这个项目的付出都是有意义的，值得在这里记录一下，感谢每一个为这个项目付出的小伙伴。其中包括Qiu Yu大牛（基于IPVS的L4负载均衡主要实现者），他还实现了基于一致性哈希的IPVS调度器的kernel模块，也参与了Contour的定制。还有Daxiong，他接力完成了UFES前端代理和数据中心网关的拆分相关的PaaS集成，并且对接了生产环境流量。还有Ji Yuan，作为L7统一管理终端的实现者，也对这个项目的成功上线做出了重要的贡献。此外还有现在与我一起并肩作战的小伙伴：Zewei（参与第四个阶段的集成）以及Leona（帮忙在维护L7 admin console）。
另外，我希望借这篇文章阐释一下我对PaaS端对端的理解，希望能给大家带来一些启发。PaaS不仅仅是集成，它也提供了一个机会——如何从无到有的构建一个云原生网络的系统。从小看，能够了解每个数据包是如何从客户端经过物理网络、主机网络、Linux内核、容器网络再到达数据中心的后端应用层，最后返回给用户的整个过程；往大的看，可以知道如何在有很多系统依赖的情况下构建一个高稳定性的系统，并且尽可能地利用自动化减少人为操作。
最后，边缘节点的云原生网络实现一路走过来虽然并不是那么一帆风顺，但是放到云计算到云原生变革的这个大背景里，这也是一种技术发展必然的趋势。同时，我们内部实现的架构和采用的技术也一直在迭代演进。目前我们正在实现数据中心基于Istio的云原生网络以及服务网格。这一技术也是充满了挑战，但是作者相信：“长风破浪会有时，直挂云帆济沧海”。
从OpenStack到Kubernetes|如何在大规模产线...
干货|eBay Feature测试环境上k8s的实践
eBay大量优质职位虚席以待
我们的身边，还缺一个你
