如何看待数据中心网络架构变化

随着云计算、虚拟化、SDN等技术在数据中心持续落地，数据中心网络到了不得不改变的时候了。为了满足这些新的技术需求，数据中心网络架构也从传统的三层网络向大二层网络架构转变，也就是新一代的数据中心将采用二层的网络架构，所有的接入设备都连接到核心网络设备上，然后通过核心设备路由转发出去。在数据中心内部完全是一个二层网络，而且为了实现跨数据中心的VM迁移，数据中心之间也可以跑二层，当前是虚拟的二层网络，基于物理三层网络来跑二层。数据中心内部网络架构向大二层转变的趋势已经无法更改，将会有越来越多的数据中心网络架构向这个方向发展。数据中心内部网络建设成为一个大的二层网络，虽然架构上清晰了，简单了，但是却带来不少的现实难题。下面就来说一说，新一代数据中心网络架构变革所遇到的难题。

大二层MAC容量问题

数据中心网络架构向着大二层方向演变，首先带来的就是MAC容量的难题。二层网络根据MAC地址来完成点到点的转发，在数据中心里拥有数千台服务器是再普通不过的了，而如今跨数据中心之间也要实现二层转发，这样就要求数据中心的核心设备MAC容量超大才行。比如一个中等城市宽带网络至少要拥有100万个家庭，要实现所有的家庭宽带上网，若都采用二层的数据中心网络，则需要核心网络设备可以处理1M的MAC容量，这对网络设备提出了很高的要求。目前能够达到1M的MAC容量的网络设备的确有，但是应用并不普遍，32K~256K是最常用的容量规格。采用1M的MAC容量设备，这样的设备往往价格很高，会给数据中心带来沉重的负担，而且这样大规格的设备使用并不普及，设备的稳定性低。很多能够达到1M的MAC容量的设备采用的都是芯片外挂TCAM来实现的，这种方式由于是通过PCI总线来访问外挂器件，访问速度自然没有芯片内快，所以这种方式的MAC学习速度并不是线速的。在一些网络环路、震荡中，这些设备就会表现出MAC学习不稳定，流量有丢包，显示有问题等一系列待解决的问题。所以在大二层的数据中心网络中，如何提升网络设备的MAC容量，是当前网络技术中急需解决的问题。如今通过技术手段达到1M以上MAC容量并不是难事，但在这种网络环境下，要保证网络运行的稳定性，还有很多的技术难题要解决。

环路问题

二层网络最常见的网络故障就是环路问题，在网络规模比较小的情况下，可以通过部署STP/MSTP这些环路协议避免环路的产生。当然STP/MSTP协议有天生的缺陷，阻塞了备用链路，造成网络带宽的严重浪费，后来又出现了TRILL新的二层网络环路协议。TRILL协议可以保证所有的链路都处于转发状态，避免了网络带宽的浪费。不过我们知道TRILL实际上要靠ISIS协议来维持TRILL协议的状态，当网络规模很大的时候，网络设备要处理大量的ISIS协议，这对网络设备是一个不小的冲击。能够拥有1M的MAC容量的网络设备，端口数量要数百个，要保证所有这些的端口的TRILL状态计算准备，并且在有网络震荡的情况下，TRILL协议仍能正确切换，这对网络设备要求很高，尤其要保证 TRILL协议的切换速度。比如像STP协议，在正常切换的情况下，速度都要30秒，而若网络规模比较大，则所花费的时间会更长，达到分钟级别都是有可能的。TRILL协议也是如此，ISIS协议并不是快速收敛的协议，超时时间，切换速度都不比STP协议快，所以在TRILL的二层环路网络中，一旦发生网络切换，那么收敛速度是个问题。数据中心很多业务是非常敏感的，在网络出现丢包或者震荡数秒钟，都会影响到业务，所以当数据中心二层网络规模扩大以后，环路协议的收敛问题突显。有人建议将TRILL的ISIS协议处理提升优先级，比如放到一个单核上处理，通过软件中断的方式处理响应，这样能够大大提升切换的速度，避免受到其它协议的影响，当然这样自然会占用更多的设备资源，而且效果也未知。

广播域过大的问题

大二层还会遇到一个问题就是广播域过大。因为整个数据中心，甚至多个数据中心之间都是二层的，那么一个广播报文会在整个数据中心的设备上进行广播的，显然会占用大量的网络带宽，如果广播流量比较多，可能会造成个别的端口出现拥塞，从而影响业务。在正常的网络中，肯定是广播流量越小越好。对于大二层网络广播域过大的问题，还好有一些解决的方法，而且这些方法目前看是比较符合实际的。比如：默认情况下，禁止广播报文的转发，让广播报文和组播报文一样，通过协议控制转发，只有协议状态计算好之后，才允许广播报文转发，而且是像组播一样，只转发给请求接收的端口，也就是在未来的数据中心里将没有广播的概念，只有单播和组播的概念。对于跨数据中心的二层，这种二层转发实际上是一种逻辑上的二层转发，要通过物理三层转发，是一种封装技术，这样就可以通过软件控制这种情况下，广播报文要不要转发。在默认情况下，跨数据中心的二层广播报文是不转发的，可以通过软件设置让特定的广播报文转发。还有就是对广播报文设置广播抑制比，当端口上的广播流量达到一定比例时，对广播报文进行丢弃。显然，对于大二层广播域过大的问题，目前已经有了一些比较好的解决方法，可以很好地解决这一问题。

尽管数据中心网络架构的演变面临着各种各样的问题，但是向大二层转变的趋势已经无法改变。纵然这样的架构给数据中心带来了新的问题，但是正是有了这些缺陷，也给了网络设备商机会，谁能很好地解决这些问题，谁就能在未来的网络市场上战胜对手，赢得市场。

游戏 行业是阿里云最早聚焦的行业之一，近年来 游戏 行业的变化、云计算产品技术的变化都与日俱进。随着行业业务的变化、技术架构的演进以及阿里云产品的迭代演进，整体的产品技术选型在不同的 游戏 场景、业务场景也不尽相同。本文将聚焦阿里云弹性计算产品在 游戏 行业的方案实践经验。

当前， 游戏 行业的各种场景和行业发展密不可分。简单回顾电子 游戏 的发展，80年代的黑白机，90年代的PC单机 游戏 ，00年代前夕随着互联网的发展网络 游戏 开始盛行，2010年后随着移动设备的逐渐普及，手游在国内开始兴起。

从 游戏 终端来区别，主要有：主机 游戏 （往往是3A 游戏 ）、PC 游戏 、移动 游戏 和网页 游戏 等。目前出现跨平台多端 游戏 ，以及云 游戏 化的趋势。

关于 游戏 的品类区别会有非常多的维度：RPG（角色扮演）、MOBA类、竞技类、FPS（射击类）、休闲类、卡牌类、棋牌类、SLG（策略类）等等。目前有多品类融合玩法裂变的趋势。

随着国内防沉迷、版号因素，近年来 游戏 行业诞生了越来越多的精品 游戏 ，出海全球化乃至区域化，以及整体存量用户增速放缓，长线运营、精细运营以及私域社区等运营方式也在悄然变化。

不同的业务场景技术架构不尽相同，如竞技类 游戏 和卡牌类 游戏 对计算的需求就有所区别，云 游戏 与常规的网络 游戏 架构也有所区别。这里主要从 游戏 服和 游戏 平台、大数据、云 游戏 这四个目前常见的场景简单介绍其架构。

游戏 服，从 游戏 类型来看有RPG、FPS、MOBA、SLG、棋牌、休闲等等；从 游戏 平台来看通常有主机、手机、PC等；从业务发行来看有全球、国内、海外，从部署架构来看有集中部署和分区部署；从技术架构来看， 游戏 行业也有逐渐分层解耦的趋势，但与互联网应用相比，有一定其独特性。

因为 游戏 的强交互性特点， 游戏 技术架构与其他互联网应用相比有一定独特性。 游戏 需要保持会话连接，也就是从一个客户端到服务端的长连接，便于对客户端中玩家的操作、行为等进行及时的反馈以及推送给共同 游戏 或对战的其他玩家,所以 游戏 普遍对网络质量更加敏感，网络质量较差的情况会使长连接断开或重连，引起玩家掉线。 游戏 也需要保持会话的状态，既服务端会保持一份玩家的实体，当玩家进行操作时，下次通信的数据会依赖之前的通信的数据，这也是一些MMO（多人在线）大型 游戏 对网络吞吐性能要求较高的原因之一。再比如FPS、MOBA类等多人对战类 游戏 ，交互性更强，对网络延迟容忍度更低，要求低延迟。因为 游戏 需要比较高密度的记录玩家的操作以及结果，所以有频繁写入数据的特点，这类场景需要较强的IO性能。因为 游戏 强交互性、低延迟的特点，其技术架构也和互联网应用不同，在逐渐分层解耦的同时，需要保证 游戏 玩家的交互效果，同时也会依赖到底层服务器的计算能力。

这些都是 游戏 场景普遍存在的特点：长连接保持会话、保持状态、低延迟网络、高IO吞吐、高计算性能。

游戏 的部署架构会结合 游戏 业务特点、 游戏 运营需求来制定 游戏 服务，有分区分服、全区全服业务逻辑，分区分服还是全区全服，最大的架构差异在于数据是不是一套。而从部署方式看，主要是集中式部署和分区域部署。

集中部署就是不论 游戏 玩家在哪里， 游戏 服务集中在一个区域，适合对网络延迟要求通常不高的 游戏 类型，如休闲类；分区部署是指 游戏 服务器根据 游戏 玩家地域分布，分区域部署，方便就近接入，适合对网络延迟要求较高的 游戏 类型，如MOBA、FPS类。

典型架构

MMO类有高并发特点，大量玩家并发的高计算量负载对服务器的计算能力和稳定性有着极高的要求。同时MMO类 游戏 有着比较强的PVE或PVP特性，对网络延迟的容忍度较低。

其中网关服务器负责所有网络数据包的转发，通常是网络负载较集中的点，对于网络吞吐能力要求较高。单个 游戏 区承载玩家数量高，逻辑服务器通常按照场景地图来划分，规模再大会通过分区的方式实现。

数据中心服务器负责缓存玩家数据并异步入库，保障玩家客户快速获取和写入数据，对于可用性要求较高，需要配合应用层实现数据容错机制。

日志服务器承载了大区所有业务行为的日志收集及处理的压力，对磁盘写入性能要求较高，通常采用多台分组方式实现。

（1）MMO 游戏 服性能与稳定需求，建议使用最第7代ECS实例，根据实际需求选型c计算型（CPU与内存配比1:2）/g通用型（1:4）/r内存型（1:8），Intel Ice Lake 29GHz基频35GHz睿频提供超高性能，能更好地优化 游戏 体验。

（2）异步落库以及日志服务器，对于磁盘读写性能要求高的场景，建议云上使用ESSD PL 0/1/2/3根据业务性能需要选择，避免磁盘读写瓶颈。

（3）在 游戏 日常版本更新中，需要各个地域Region镜像的快速复制，基于ESSD快照异地复制的能力，能够提升镜像复制效率。

（4）分区分服等场景往往需要快速地开服滚服合服，通过CADT云速搭、ESS弹性伸缩、OOS运维编排、ROS资源编排等云上运维工具搭配产品使用，能够提升云上运维效率。

ii FPS、MOBA类 游戏 架构介绍

MOBA类 游戏 主要包括PVP系统、PVE系统、 游戏 平台等几个主要部分，其中PVP战斗是MOBA/FPS 游戏 的核心。

PVP、PVE、 游戏 平台功能部署于同一VPC中，构成 游戏 大区；战斗服务器（往往）单独跨地域部署。

游戏 客户端首先接入到登录服务器中，完成登录认证、计费等 游戏 平台逻辑。为避免单点问题，所以 游戏 平台服务往往需要高可用方案。可利用云上高可用方案，包括便捷的运维工具满足业务高可用需求。

FPS/MOBA竞技 游戏 ，往往对延迟特别敏感，可以想象，竞技类 游戏 中对战的 游戏 场景：玩家操控人物，在地图里步伐飘逸，枪声密集，每一颗子弹都是一次时间加上空间的矢量计算，而且需要在主进程中完成计算，那么算力需求就随着房间玩家数量上升而指数爆炸，5V5的房间和大房间100人（吃鸡）对算力的需求完全不同。

游戏 这部分重算力场景，推荐阿里云7代高主频或七代实例，更高的单核性能提供更好的战斗效果。

战斗房间类 游戏 ，因为业务本身峰谷特性，灵活地使用云上资源的弹性能力，往往会较好地优化整体的资源使用成本。阿里云弹性计算本身提供了非常灵活的付费方式，包括常规的按量实例、包月包年实例、以及通过节省计划/预留实例券去抵扣按量实例资源，兼顾资源灵活使用的同时达到更优的成本。

此外，为更进一步释放开发运维的效率，当前一些 游戏 也采用了容器化技术架构，阿里云的ACK+ECS/ECI弹性容器实例组合搭配使用，更进一步释放了基础资源的灵活性和弹性能力。

业务场景

游戏 平台（不限于FPS、MOBA类）主要提供的服务：官网、客服、注册、登录、充值、兑换、商城、推送、公告、社区、SDK及邮件、短信等公共服务；包括内容审核、视频录制、弹幕、转码、剪辑、RTC这些业务需要的基础服务，以及运维监控、发布平台、测试平台这些运维等平台服务。

这部分更接近于通用的互联网技术架构，以服务为颗粒度解耦，接入->网关->应用->数据库。

技术特点

这往往通常需要构建高可用基础架构来提升稳定性，业务突发期往往需要一定的弹性能力。相比于 游戏 服务这部分容器化就更加普及，也更容易通过云上的比如弹性容器实例去应对流量峰值场景。在视频录制场景，对实时性要求较高时，往往会基于GPU能力构建，这部分阿里云也提供了vGPU/cGPU能力，释放GPU的灵活性。

大数据是当前 游戏 业务经营、 游戏 运营主要的技术手段，主要面向平台数据运营、 游戏 数据分析、广告转化分析、安全运营分析等 游戏 核心运营场景。不同的场景对实时性要求不同，实时查询检索通常是经营分析、客户受理、玩家监测、在线等场景；离线报表通常是玩家行为分析、用户画像、特征挖掘等场景。

总体而言，实时性业务更多是业务查询类、简单计算类任务，比如买量转化的分析；离线类基本是分析类、预测类任务，比如 游戏 玩法分析。

从技术架构来看，得益于开源社区技术栈的高丰富度，大数据具体的技术选择非常之多，整体从存算一体到存算分离，也诞生像数据仓库、数据湖乃至湖仓一体等概念。

从数据架构流程来看，从数据源->数据采集、传输->数据计算、存储->数据应用，其中可选看技术方案也需要因地制宜。

从部署架构来看，不同的 游戏 公司处在不同的数据建设阶段，会有不同的选择倾向，包括完全自建、基于云自建大数据、基于云上托管、以及利用更多云上成熟的产品技术去丰富整体的大数据能力集，而后者也成为越来越多客户的选择。

拿云上大数据方案举例来讲，比如实时计算部分，选择SLS采集、Kafka数据网关通道，通过Flink做数据计算，通过ES或CK做数据分析，通过ADB以及QuickBI做数据应用展示。离线方案通过OSS做冷数据存储，Spark、Hive、HDFS等组件做数据计算存储，通过CK汇聚分析，通过Dataworks做数据应用。

具体计算存储的产品选型，主要根据不同的业务特性以及大数据应用特性来区分，根据数据容量、IOPS、吞吐、读写特点以及性价比来选择。

如刚刚举例的实时计算/近实时计算场景，Flink具备高性能、低延迟特点，所以是计算密集、网络性能高场景，推荐选型七代ECS实例或6代增强实例；如HDFS需要超大存储容量，高吞吐，推荐D系列本地盘实例，如D2S存储型本地盘实例。Remote Shuffle Service等处理结果多的场景，读写处理频繁如大量的join计算，需要综合来看计算、网络、存储性能以及综合成本来选择通用实例（如第7代ECS实例）或i系列本地盘实例。所以，最终在云上的资源选型，在性能满足的前期下，需要评估通过网络传输数据成本高（云盘），还是就地取材计算成本高（本地盘），不同模型、不同量级选择不同。

从内存处理（成本最高、性能最好、存储容量最小）、SSD本地盘、HDD本地盘、ESSD云盘、OSS对象存储（成本最优、性能一般、存储容量最大），逐渐分层解耦，还带来一个好处：充分释放了云上弹性的能力，可以利用更轻巧的弹性计算产品（如SPOT抢占式实例方式，或ECI容器实例）进行大数据计算，达到更好的弹性能力去满足业务需求的同时也能节约更多的成本。

云 游戏 主要分终端和云端。终端部分基于Windows、iOS、Linux等操作系统的终端设备包括手机、平板、电脑、电视机、VR一体机等。云端架构主要是 游戏 应用层、云 游戏 平台层、IaaS基础资源层，应用层包括PC 游戏 、手游、VR 游戏 、H5 游戏 等多种类型的 游戏 应用；平台层云 游戏 必须的运营平台、支撑平台、流化技术平台等；IaaS基础资源层包括基础网络、基于X86架构以及ARM架构的GPU服务器。

云 游戏 落地，在技术上也经历了诸多挑战，为满足端到端高性能低时延，网络调度、指令串流、编解码、多终端的SDK适配等等都是云 游戏 场景中不可避免的技术问题。

对于云端算力来讲，阿里云解决了云端渲染、串流以及编解码问题，并通过全系列GPU产品来满足云手游、端游、VR乃至企业级视觉渲染场景的需求。

总结来讲，阿里云弹性计算通过云上的串流、编码加速、渲染加速等全套的技术帮助 游戏 客户给云 游戏 玩家提供更好的性能体验，通过基于阿里云全球数据中心可以帮助云 游戏 客户覆盖更多的用户，通过GPU多种产品形态和整体的弹性能力，也帮助到 游戏 客户去更快捷更灵活的构建其云 游戏 业务。

阿里云通过多年的技术积累和持续的运营，提供了大规模的基础设施云服务，目前在全球部署了26个地域、82个可用区，通过优异稳定的性能表现帮助 游戏 客户高效稳定地运行 游戏 业务，为玩家提供极致顺滑的 游戏 体验，并通过技术手段不断地帮助 游戏 客户优化用云成本。

国内的业务出海、 游戏 出海也是现阶段大的趋势之一，很多 游戏 公司已经把出海从业务可选项变成了必选项之一。在2022年3月，阿里云上线了韩国和泰国两大Region，能够为本地化的 游戏 业务提供更流畅、更稳定的 游戏 体验，以此希望能在 游戏 客户出海的业务领域，提供更多的帮助。

当然，作为内容与 科技 两大热门领域的交叉领域， 游戏 产业日新月异，架构也随着前端业务的需要不断改变。阿里云弹性计算也针对 游戏 厂商的不同架构，陆续推出了不同的云服务器类型和付费方式，以及云上运维套件，以帮助客户降本增效。

原文链接：http://clickaliyuncom/m/1000336551/

使用的光电交换机。

1、光电交换机通常在输入输出端各有两个有光电晶体材料的波导，波导二间有两条波导通路，这就构成了Mach-Zehnder干涉结构，这种结构可以实现12和22的交换配置。

2、两条通路之间的相位差由施加在通路上的电压来控制。当通路上的驱动电压改变两通路的相位差时，利用干涉效应就可将信号送到目的输出端。

3、光电交换机的主要优点就是交换速度较快，可达到纳种级。