近年来，为了满足不断增长的业务需求与集约化建设要求，金融机构逐渐开始进行数据中心的云化建设。作为国内第一家互联网银行，数据中心底层基础网络平台该如何搭建，以及拥有银行与互联网双重基因下的互联网银行，在网络的构建过程中，如何将互联网的敏捷、灵活及银行网络的稳健、业务模型相结合，以搭建最适合于互联网银行需求的网络平台呢？通过调研互联网、银行同业发展趋势，结合WeBank自身业务需求，我们希望构建出具有互联网银行自身特点的高可靠、高性能网络平台。
——摘要
互联网银行发展趋势
2017年2月SDxCentral发布了2017下一代数据中心研究报告(2017 Next Gen Data Center Networking Report)。这份报告系统介绍了下一代数据中心网络的发展趋势、关键功能、典型案例、行业标准。
下一代数据中心对网络的关键需求
1、简单化、标准化和模块化
（Simplification, Standardization and Modularity）
网络运营者希望能够删减不必要的路由/交换功能，利用标准服务器提供网络优化，采用较少商用芯片数量构建更为简单的网络矩阵，同时将L4-L7的功能迁移到标准服务器上。其中LinkedIn、Facebook、Microsoft、Google等巨头已经开启模块化数据中心Pod之路，每个Pod都包含了标准化的网络架构，大规模利用成本低廉的商品化交换机。模块化的节点更易部署和替换，也提升了横向扩展能力，随着这种云服务商的带动，大型企业级市场也有这种趋势。
2、可编程能力（Programmability）
为满足业务敏捷型和灵活性需求，网络可编程能力必不可少。上层业务必须能够实时控制底层网络，进行编排和优化。无论这些业务采用基于XML/JSON的RESTful接口，还是用P4编程或者Openflow协议控制，都需要网络设备本身能够“被集成”，与数据中心融为一体。
如今已经有越来越多的企业级网络产品可以被云管理平台(比如Openstack、VMware vRealize suite、Cloudstack)集成部署。网络被系统配置管理是大势所趋，甚至这种响应被要求是实时的。
3、自动化和DevOps/NetOps
（Automation and DevOps/NetOps）
可编程性让网络集成到编排系统成为可能，但是系统需要被部署、被监控、被更新，并非一劳永逸。传统情况下，网工最爱命令行CLIs，很多厂商提供过图形配置界面，但是很少能广泛应用的，大量的设备还是被“命令行”管理着。但是，DevOps正在对网络行业产生影响，或者说我们需要NetOps来拯救。基于自动化配置工具(Ansible/Puppet/Chef等)，网工们也可以像管理服务器一样去管理网络基础设施。
4、可视化与Troubleshooting
（Improved Visibility and Troubleshooting）
跨数据中心流量暴增以及Overlays的存在，让网络可视化变得尤为重要。可视化有理于快速定位网络延迟或者洞察流量突发。还需要具备对流量数据的收集和分析能力，用于排障、优化和安全防范，如果只有海量告警事件日志，网络运营只能抓瞎。另外，由于数据中心网络正在演进为基于ECMP的leaf-spine三层Fabric，保障所有数据的可达性非常关键，不要让“大象数据流”阻挡了“老鼠数据流”，“可视化”有助于让我们了解整个交换矩阵发生了什么，甚至细化到每个交换机端口的缓存利用率。
由此可见，在下一代数据中心发展路线上，数据中心网络、尤其是互联网数据中心对网络的架构的可扩展性、高性能、可靠性、灵活性要求越来越高。
通过云计算发展，我们来看数据中心网络发展。网络可扩展和云计算发展密切相关。在云计算刚起步阶段，所有政府、企业、银行开始构建自己私用云，主要用解决计算资源池化问题。在这个阶段，数据中心网络架构设计普遍存在较大收敛比，从机架(Rack)，到集群(Cluster)，再到数据中心(DC)，随着网络层级往上(从接入、汇聚，到核心)，每一层总的汇聚带宽越来越低。在这种背景下，应用开发者通常需要考虑将相关业务部署在一起，以提高局部性，降低网络汇聚层或者核心层的拥塞。当云计算进入全面爆发阶段：Serverless computing时，在大数据和AI应用驱动下，应用开发者越来越希望关注于业务本身的逻辑，而不是底层服务器、网络。用户希望只关注于怎么写应用，而不用考虑业务如何部署，是否需要批处理或缓存。这些超大规模的分布式应用越来越希望，网络是个full bisection bandwidth的网络，任意两台服务器之间带宽是一样的，不管他们是在一个Rack里面，还是分布在不同的Rack。只有这样，才能支持any service anywhere，应用才可以非常灵活的部署和弹性扩展。在云计算的上述演进过程中，网络是如何一步步地演进以解决可扩展性问题，提供full bisection bandwidth呢？我们以Google为例，因为它在这方面一直走在业界前面，得益于搜索引擎这个超大规模分布式应用的驱动。
Google数据中心网络架构演进
图上显示的是Google数据中心网络的演进与创新。2004年，Google设计了4 post cluster架构，提供2Tbps的总带宽，这个受限于当时市场上最高端口密度的1G交换机（512 x 1GE）。由于每个ToR下行接40个服务器，上行只有4Gbps（10:1的收敛比），高带宽的应用只能尽量部署在一个ToR下面。从那个时候，Google开始面临一个问题：不管花多少钱，他们都无法从市场上买到足够大的商业交换机来满足他们快速增长的带宽需求。因此，他们决定自己做数据中心交换机硬件。从2005年到2012年，Google自研框式交换机经历了五代，一直在不停地提高数据中心内部的双向带宽，以满足应用扩展性的需求。在这个演进过程中，Google一直保持以下的设计原则：基于商用交换机芯片和Clos拓扑，搭建满足任意带宽需求的框式交换机。其背后的观察是，基于同一颗交换机芯片，可以基于Clos拓扑任意扩展一个交换机集群的规模。
从Google数据中心网络演进看，DC网络带宽在不断变大，且持续增长。需要通过Clos架构加上商用交换机构建集群化交换机网络。基于拓扑任意扩展交换网络集群规模。
再看Facebook，Facebook设计了Pod级别的模块——Altoona。Altoona设计可借鉴之处在于，你可以使用小型开放交换机构建你的数据中心，这个架构可以让你扩展到任何规模，而不需要改变基本构建块。
Facebook IDC网络架构
特点：无阻塞、高速Farbric、集群化、
Sacle out、多平面
在Facebook数据中心网络中，我们看到更多架构可扩展，通过小型开放交换机搭建自己数据中心网络集群，在网络高性能方面，通过Facebook数据中心数据研表明，互联网数据中心在以下几个方面，特点明显：
以Hadoop等固定行为模式业务为例，可以看到跨Cluster流量较小，大数据集群计算流量基本在网络模块内完成消化，数据中心东西向流量明显增加。分布式应用有较多跨Cluster流量。其中80% 的流量被少数的elephant flows占据(流量大但数量少)、20% 的流量被众多mice flows占据(流量小但数量大)。
Elephant flow：大流量，持续时间长，比如视频流量, 文件传输等，其特点是对丢包对整体性能影响较小、对延迟不敏感。
Mice: 小流量，持续时间短
比如HTTP Request/Response, Map-Reduce Application对丢包对整体性能产生严重影响、对延迟敏感。
通过Google、Facebook数据中心网络，我们可看到互联网数据中心网络流量模型与传统企业数据中心相比较为复杂，要求数据中心网络遵循如下设计原则：
1、数据中心内网络设备需拥有较大Buffer，能满足业务流量一定的突发；
2、较高网络收敛比，满足模块内东西流量互通需求，集群化网络通过CLOS架构以实现模向无限扩展、EBGP+BFD构建三层underlay网络；
3、标准BGP路由协议，故障快速收敛，网络自愈能力；
4、通过轻量sflow实现对数据中心流量可视化；
5、网络配置、管控自动化、网络朝Netops演进；
6、 当数据中心IDC Module发展到一定规模的时候，不再依赖大框网络设备。将大设备拆分小型化交换机来组建集群网络。在整个网络架构上更趋于分布式。
金融银行同业网络发展趋势
在大数据、云计算、AI、FinTech浪潮下，传统金融机构也逐步开始搭建基于云计算平台私有云，业务系统逐步云化、以实现高弹性、可扩展性，满足互联网场景需要。另外，政策方面，《中国银行业信息科技“十三五”发展规划监管指导意见》（征求意见稿）要求银行积极开展新系统架构转型，稳步开展云计算应用，主动实施架构转型，探索构建私有云平台，采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化 等技术，建立资源池，形成资源弹性供给、灵活调度和动态计量的私有云平台。
银行在朝着互联网化的路上，逐步优化、创新。
2015年招商银行宣布建立了银行业第一张SDN网络，实现了网络资源自动化调配。
其SDN网络架构如下：
1、标准化：
采用业界通用的Spine-Leaf模型进行组网，可实现网络的模块化建设，为未来IT基础架构建设提供标准化模型；
2、高可靠性：
物理网络为纯三层网络，无二层网络，可靠性更高，使得网络更易于部署与平滑扩展；
3、灵活性：
在物理网络之上构建了一层虚拟Overlay网络，各类IT资源统一接入Overlay网络。Overlay网络的好处是虚拟、弹性，并可根据业务需要可自定义；
4、解耦合：
Overlay网络的部署，实现了服务器的接入位置、IP地址与物理网络的解耦合，实现了网络资源与物理网络设备的解耦合；
5、自动化：
通过SDN控制器，对Overlay进行集中部署管理，实现了IT资源的自动化分配和弹性扩展，提高了网络快速部署和灵活扩展能力。
除了工商银行、招商银行外，国内大部份商业银行、银联等金融机构纷纷拥抱SDN\云计算改造底层基础网络，皆在适配互联网时代发展。
整个行业目标趋势可以归纳为3点：
1、IT基础设施与物理资源解耦；
2、全堆栈的自动化；
3、以应用为中心的数字化运营。
We、WeBank、
当银行遇上互联网
通过Google、Facebook网络架构特点来看，互联网行业网络架构，在高带宽、微突发、横向可扩展Scale Out、大规模组网故障时快速收敛方面特点突出。当银行遇上互联网，互联网银行数据中心网络架构，会是什么样子呢？过去、今天发生了什么。2014年我们按两地三中心架构模式，投产了同城两生产中心，单个生产中心ServerFarm物理服务器不到1000，同城两个生产中心总计不到2000台。随着业务持续发展，业务扩容、新业务系统投产上线，要求基础架构快速供给服务器、网络资源。IDC建设速度步骤明显增快。1.0架构上，Serverfarm、ECN、DMZ、MGT专区刚好满足当时的业务系统上线所需要资源需求。1.0版本在扩展性、性能上需要更进一步提升。至2018年底，在深圳我们将会投产第五个数据中心，同城多个中心，这也是我们与传统银行比较大的差别所在。这个差别也决定了我们架构的特殊性、偏互联网化，其间我们IDC架构版本，从1.0->2.0->2.5 迅速迭代，以满足生产数据中心网络建设需求。随着应用同城多中心多活架构改造升级、DB多中心集群跨机房同步等需求，对底层跨机房网络质量、容量上提升了更高要求。2016开始规划同城MAN网络建设，2017年通过架构、建设方案评审。2018建设同城DWDM波分传输网，投产CoreRoute，该项目我们将其命名为MDTP(多平面数据传输平台)，主要是解决两个层面的问题：第一层解决底层裸光纤质量问题，提供传输层面多平面保护，第二层纯IP网络切分平面。其实银行的架构与互联网架构很明显差别在于逻辑分区上，银行有许多的边界功能区，而互联网架构则仅有一个ServerFarm专区。所以在同城建立MAN网络的时候，我们一定要细分到每个IDC的逻辑区的多平面问题，这个是平面化如何构建的问题，其实在传统金融机构，两地三中心架构里，网络通讯流量在机房模块内会完成消化，极小部份会出现跨机房。但在互联网银行、我们实际生产运营过程中发现，跨机房流量已成为主要生产业务流，且随着应用多IDC多活后，应用分片落在不同IDC内。需要把同城IDC看成一个大集群，或者说多DC as a Computer，未来多数据中心它一定是一个整体。我们需要做的工作，就是将这个Computer I/O设计好，能够满足业务对跨机房通讯要求。MDTP就是这样一个IDC互联Farbic，我们计划18年底完成深圳同城IDC架构逻辑区多平面架构升级改造、建立高速互联的Farbic，底层光网+数据通讯层实现多平面。
前面讲到，国外互联网数据中心的成熟架构、国内传统银行数据中心网络架构特点，从本质上互联网与银行架构不能直接做加法。需要根据自身业务场景、需求综合评估，从IDC架构、城域网、骨干网架构等方面取其互联网架构高效、敏捷、可扩展性特点，而银行生产网络更注重“稳定运行“。所以，在互联网银行的生产IDC网络架构上不能盲目互联网化，更要把根基打牢靠。应根据其实际业务需求确认，并按需求进行配套设计，我们看IDC内逻辑分区架构。
ServerFarm生产业务区
主要生产业务区，部署数据中心内重要核心应用、公共平台组件、大数据等，网络架构上我们采用了尽可能简单的方式设计，路由协议上标准化、选用TOR低延时交换机、网络层次尽可能扁平化，采用CLOS架构搭建。高吞吐、低延时、故障快速收敛，是ServerFarm网络高速运转的首要条件。underlay路由协议选用大规模互联网数据中心采用的EBGP+BFD来构建，将BGP引入数据中心内，主要看重其路由稳定、大规模组网的可扩展性，摒弃设备绑定私有路由协议、底层铺设BGP路由可满足未来ServerFarm规模持续扩展，不出现协议层面的瓶颈。整个专区的设计与Google、Facebook的思路是一致的，尽可能保持架构简单、协议标准、保持可横向扩展能力。
外联接入区（ECN）
伴着业务应用多中心多活需求，分布式ECN网络接入需要分布式部署，构建同城ECN分布式接入集群。解藕专线接入与IDC所属关系，ECN传输资源要求可跨机房进行调度， 以解决单机房运营商传输资源上联带宽不够，而导致业务无法快速上线的情况。业务同事申请专线资源时，无需关注专线物理接入所在机房，同城专线资源可在各种机房进行灵活调度。
互联网接入区
两地三中心银行架构中，当主数据中心发生切换时，其对外的互联网出口切换需要改换IP地址，对外发布域名需全量修改A记录来进行公网流量切换。当同城数据中心成集群化部署时，这个大Computer在切换时，如需要改换IP，对于上层应用来讲将带来极大的挑战，与此同时集群化的IDC互联网出口质量也变得非常重要。因此，我们的公网IPV4 地址需要有与三大运营商互通能力，一定要避免跨运营商互访。同时要求能按运营商属性进行跨地域精细化调度，避免因为运营商省出口故障导致全网瘫痪情况出现。另外当IDC出现故障时，需要能快速引导DMZ 入口流量切换至同城备份机房，恢复公网流量，避免通过域名暂停A记录方式完成切换，从而变向解决运营商LDNS刷新缓慢的问题。将应用复杂切换的工作转于底层IP层路由快速切换实现。真正实现当一个IDC异常时，流量可快速实现跨机房切换。
在云计算、大数据、Fintech业务快速发展及推动下，我们摒弃了传统架构、结合互联网扁平化、可扩展、高性能特点，搭建我们新一代基础网络平台，在一定程度上满足了生产业务发展需要，解决了数据中心底层网络可扩展性、构建了低时延网络传输平台、ECN资源同城模块内灵活调度能力、域域网MAN跨机房Fabric能力、互联网出口灵活调度能力。
站在业务系统的视角看，应用系统的SOA组件化、微服务架构、呈现出大量可拼装的应用、复用和通用业务组件，系统边界变得模糊，带来了安全架构的变化；基于开发平台、计算资源类型进行分区成为主流趋势；应用推动了云管理平台的建设，要求计算、网络、存储、安全能够进行业务编排和自动化交付，大Fabric架构和Controller的应用已经成为全IT基础架构的云服务交付的关键支撑。
未来、WeBank网络平台
如何更好支撑金融业务？
网络做为银行业务系统稳定运行的基础平台，在满足业务快速发展的前提下，还需要进一步结合自身业务对网络架构需求、运维需求、流程自动化等方面对网络进行适配，并进行规划设计。在实际的网络运营过程中，我们发现有如下几个场景：
运维方面
我们通过ECC的告警及历史case处理情况，大部份业务应用报Connect Timeout、网络抖动、或者业务成功率下降、业务耗时增加。往往第一时间，我们会想到，网络到底有没有问题，是否存在网络性能瓶颈、网络端至端有没有丢包或出现质量问题。站在产品运维、开发的视角看，业务应用自身是否健康、“血管”是否出现堵塞，我们在哪里可以抽血化验下？站在网络运营角度看，需要拥有一个实时网络流分析平台，提供“验血”能力，提升网络可视化能力，快速定位应用或网络故障。
网络架构方面
当一个城市出现集群化的IDC的时候，必定需构建城域网来承载集群化IDC跨机房通讯。当业务规模在不断发展扩大，在异地多活的业务需求下，跨地域的互通，也需根据业务需求进行分流设计，提供差异化网络服务，针对跨地域金融业务流，网络平台提供一张专为金融业务流设计的金融精品骨干网，满足异地多活的业务需求。
网络灵活性
当业务发展到一定规模，系统逐步云化，应用容器化、VM资源在各机架上切片分布。物理母机故障或应用迁移时，希望原有分配的IP地址不再发生改变，网络提供跨机架迁移IP漂移能力。基础网络平台需要支撑应用灵活性。
安全策略快速部署
互联网银行的应用发布迭代速度快、新业务快速上线、网络策略变更频繁、防火墙集中化部署问题。要求在安全策略在实施上能够跟上业务上线速度、防火墙的安全策略切片需转换成分布式防火墙模式部署，从而满足业务安全策略需求。
为了更好支撑好业务发展，结合业务对网络需求、互联网、银行同业发展趋势及架构创新。定义了标准网络平台框架模型：
未来，异地多活数据中心投产、大规模数据中心建设的背景下、未来的网络服务需要解决如下4个问题：
数据中心东西向流量可视化问题
大规模数据中心网络分布式防火墙策略自动化能力
异地多活数据中心双平面骨干网构建（金融精品网）
大规模数据中心IDC网络虚拟化能力
数据中心东西向流量可视化问题
思科发布的白皮书报告显示，2020年全球数据中心东西向流量占比将超过80%，而早期数据中心的流量80%为南北向流量。随着云计算的到来，越来越丰富的业务对数据中心的流量模型产生了巨大的影响，如搜索、并行计算等，当需要大量的服务器集群系统协同完成工作时，导致服务器集群内部的流量变大，数据中心网络流量由“南北”为主转为“东西”为主。
由于数据中心网络流量由“南北”为主转为“东西”，特别金融业务系统各子系统与消息总线互通高频调用。任何一个业务系统的超时，都与数据中心内网络的健康质量相关联，到底哪条Flow正常、哪到哪丢包、哪到哪延时高？在整个数据中心交换网内，我们如何能清晰透彻看到这些问题？我们需要清晰看见东西流量下Flow的状态与关联，以便能从基础网络平台中定位到与网络与之相关的性能问题或故障原因。提升网络运维灵活性，也可避免事后在生产上进行网络数据包实时捕捉采集。
大规模数据中心网络分布式防火墙策略
自动化能力
银行网络架构设计需遵循监管信息科技指引对数据中心网络进行层次化安全防护。从外部不可信区域访问内部可信生产业务区需穿越外部边界防火墙与内网核心隔离防火墙，且进行异构设计。从目前各部门的业务策略需求请求情况分析，边界进入数据中心内网核心防火墙访问ServerFarm区策略占据全年防火墙策略开通量90%。网络架构逻辑区实现多平面架构改造及园区多平面改造后，有效降低了内网核心隔离防火墙策略量，但从长远看，随着业务量增涨，内网的安全防护除了升级相应更高性能、超大容量防火墙外。更实际的目标，还是需要将防火墙分布式化部署，将安全策略切片至每台Server上，这其实是云计算底层安全实现方式。基于SDN的理念，构建X86集群控制器，实时管控分布式防火墙组件，实现集中管控与策略分发，解决集中化防火墙容量问题。另一个是业务运维、开发最关心的是防火墙策略开通的时效，互联网银行与传统银行最大不同之一是业务系统上线周期短、快速迭代。每周3天集中发布系统版本，紧急策略开通需求多、防火墙策略要求能快速完成开通，支撑业务上线。未来我们计划将提供防火墙策略自助开通服务平台，通过内置行内流程审批平台流转至自助服务平台，审批完成后，防火墙定时（变更时间内）下发策略脚本作业，针对紧急需求，可人工介入领导审批后，快速下发防火墙策略。从而彻底满足策略服务的快速开通。
异地多活数据中心双平面骨干网构建
（金融精品网）
目前两地三中心架构中，同城生产中心与异地容灾中心可通过单独的广域区互联直联，租用运营商专线实现。也可以通过云计算骨干网络实现互联互通，主要数据流类型为，同城生产中心单向同步数据至异地灾备中心。数据流方向固定，网络平面单一，但可扩展性差。随着异地多活生产中心建立。异地两大数据中心集群内各逻辑专区多平面、跨异地IDC管理网多平面、ECN跨地域调度、关键生产交易流跨地域互通，均需一张轻载、多层次业务骨干网络来进行承载。通过构建自主可控金融精品骨干网，满足金融业务场景需求。
大规模数据中心IDC网络架构虚拟化能力
当我们在设计一张超过5000台服务器规模的数据中心网络架构时，我们可能仍然采用标准的路由协议、三层两边倒叉架构来建设，基于CLOS架构可扩展性来满足数据中心规模的不断扩大。标准的路由协议、标准的设计架构保证了底层基础网络的稳健。但随着数据中心增多、机器数量过万甚至更高时，虚拟机如何进行动态迁移、如何灵活调配服务器资源。或者服务器进行维修和升级时，均需要保证虚拟能平滑迁移。而要实现虚机迁移业务不中断，则需要保证虚机迁移前后IP地址保持不变，且虚拟机的运行状态也必须保持原状，目前稳定运行的三层架构是否可支撑呢?答案是NO，因为在整个虚拟机迁移前合需要在同一个二层域内才行，因为一旦服务器迁移到其它二层域，就需要变更IP地址，TCP连接等运行状态也会中断，原来这台服务器所承载的业务就会中断。与此业务相关的服务器也需要变更相应的配置，所以虚拟机的动态迁移只能在同一个二层域中进行。在我们实际生产运营过程中，服务器过保替换、ECN外联区机器故障下线、核心应用，在实际物理服务器故障时，业务应用需重新发布版本来迁移业务应用。网络、系统部门常被应用部门虐的死去活来，网络一直被其它业务产品部认同不够灵活，不够敏捷。那么应该这个如何搭建这个二层网络。
首先，我们需要摒弃传统大二层网络的技术思路，在传统金融机构中，通常会采用冗余设备、冗余链路来保障业务，不会因为单点、单链路故障而中断，而二层网络的核心问题就是冗余设备与链路带来的环路问题和环路产生的广播风暴，传统统数中心用来规避二层环路的最主要技术是VLAN和STP。 VLAN和STP在本质上解决不了广播风暴问题，在大规模数据中心构建设计，一定要摒弃这种架构。出现全局故障对整个银行生产网可以说是灾难性的。
在传统二层技术不足以满足生产稳定性要求的时候，我们的二层网络是否可以构建在三层网络基础上呢?保证底层underlay网络稳定性，underlay层使用标准的路由协议与架构去支撑。在交换网基础上虚拟构建Farbic，在稳定三层基础网络上之构建大二层overlay网络，实现网络虚拟化。
在大规模数据中心建设、应用异地多活背景下，互联网银行业务快速发展，需要基础网络平台在架构、性能、自动化、可视化等方面持续创新，进一步提升基础网络平构健壮性。在未来3年，我们将基础网络平台在架构、自动化、网络虚拟化、可视化等方面发力创新。
END
网络架构设计、建设、运营是一个复杂的系统工程。我们希望我们所构建的基础网络平台，像一条高速公路，可以保证咱们的应用在上面能高效、稳定、畅通运行、不添堵、有序、绿色出行。最后网络的健壮，还需要大家不断的提问与建议。
