如何掌握 Windows Server 2012 网卡聚合

Windows Server 2012的推出被称为“云 *** 作系统“，想必这个 *** 作系统在虚拟化领域，在网络和存储层面，在接入和安全层面都会有很有实力的功能体现。今天给大家介绍的网卡聚合能力就是充分利用汇总方式提高服务器整体网络性能，进而实现在高密度业务负载环境，高可用网络环境下的需求，当然除了网卡聚合功能单方面提升消除CPU的瓶颈也是重点，例如Offload卡，SRIOV, RSS，VMQ队列等等技术在Server 2012中你都能找到配套的核心技术支撑。今天这篇博客重点介绍一下Windows Server 2012中网卡聚合的功能。
说到网卡聚合，可能大家并不陌生，而且这个在”虚拟化世界“里尤为重要的功能，原来Windows Server 2008 R2中并不能提供支持，而是需要依靠HP，DELL，Intel，Broadcom等公司自己提供的软件进行设置和支持，但是这是不够的，要知道通过一个硬件厂商提供的聚合功能软件仅能对同种品牌的网卡进行统一的支持，这对于一个要求具有更多选择权和灵活性的数据中心而言是不够好的。当然你知道的，在Windows Server 2012中我们苦等的内置的，虚拟化环境所依赖的功能终于实现了在 *** 作系统中的预置；因此充分了解合理利用这个功能是十分有益的。
那么什么是网络聚合或者Windows Server 2012中定义的网络聚合？在Server 2012中网络聚合有种称谓叫做LBOF（Load Balance and failover)字面上也很好理解，就是负载均衡同时实现故障切换功能的网络通道，熟悉这个LBOF灰常有意义，因为实现和查看网卡聚合状态需要用到的Powershell CMDLET就涉及了这个词汇；有了这个 *** 作系统层面的功能，就可以将不同品牌的同质的网卡进行组合实现：
1 网络带宽捆绑
2 当网络组件出现故障时可以被检测到并自动进行故障转移
举例来说如果你不是配置成“主备”模式而是“双活”模式的网卡聚合，那么两个1GbE的千兆网卡可以实现2Gb的总吞吐，如果是两个万兆网卡就可以实现20Gb的总吞吐以此类推。Windows Server 2012支持多少个网卡进行捆绑呢？答案是32个！这是个绝对足够大的带宽：）
Server 2012支持两种网络聚合模式，在配置网络聚合的时候默认的是选择第一种模式：
交换机独立模式
这种模式最为通用，因为不要求交换机参与网络聚合，因此交换机并不知道在聚合网络中的网卡属于主机中一个网卡聚合组，所以网卡可以连接不同的交换机不过交换机独立模式并不要求聚合组中的网卡连接到不同的交换机。
而且在连接不同交换机时采用的是主备模式，只有在连接在同一交换机时才可以实现负载均衡聚。
交换机依赖模式
这种模式需要交换机参与网络聚合，并且要求所有网络聚合组网卡连接到同一个物理交换机或者以级联多交换机方式实现的对外显示为单一物理交换机的方式；根据交换机支持的模式可以有两种模式选择：
通用的静态聚合模式即IEEE 8023ad
这种模式需要在交换机上静态设置指定汇聚组中的网卡连接。由于这种方式需要静态指定，因此没有动态协商协议机制帮助交换机判断线缆连接的正确与否或是否有其他错误导致聚合失败。
动态聚合模式即IEEE 8021ax或LACP（LinkAggregationControlProtocol 链路汇聚控制协议）
这种模式由于有了LACP协议的支持，可以动态的识别服务器和交换机的连接，进而实现动态地创建聚合组，添加和移除组成员等工作，现在多数交换机都支持LACP即8021ax协议，不过也大多需要在服务器连接的交换机端口中手工启用此功能。
通过图形方法配置，如果在Server 2012中启用了图形界面管理功能，可以利用服务器管理器简单的创建网络聚合。
当然，通过Powershell命令行是个很好的方式，先看看可以针对LBFO进行哪些 *** 作：
创建一个网卡聚合组“NIC Teaming”，将所有本机物理网卡添加到这个组中，并且设置模式为交换机独立模式，负载均衡模式为默认哈希：
看看创建之后的网络设备，是不是多了一个NIC Teaming网卡？
当然，你也可以通过Powershell看到这个网络聚合网卡的状态。

很多做游戏开发的人，估计都或多或少地接过渠道SDK，什么UC，当乐，91，小米，360……据统计国内市场当前不下于100家渠道，还包括一些没有SDK的小渠道。每个渠道SDK接入的方法呢，多是大同小异。但是，正是这些小异，又让SDK的接入，产生了无穷无尽的变数。所以，接入SDK之前，如果你没有经验，或者没有被SDK坑过，那么当你看到这系列文章的时候，你很幸运，你可以避免这一切了。如果你之前被坑过，而且还在继续被坑着，那么现在就是你解脱的时刻。

完成一个SDK的接入并没有多少技术含量，但是能接入100个SDK，而且能做到维护容易，结构清晰，安全可靠，一劳永逸就不是那么容易的事情了。这也是为什么，世面上出现了那么多打包工具的介绍，SDK接入方法的介绍…而且，还各不相同。

本系列文章，我们来给大家复盘一下U8SDK整套聚合SDK框架从无到有，从简到全的一个开发过程。这里我们先介绍下最初的框架整体思路和后来U8SDK在实际使用过程中的方案改进。

开始开发U8SDK之前， 我们大概简单头脑风暴了一下：

1、首先，客户端需要接入多个联运渠道SDK，为了能够使得我们接入的SDK被多款游戏重用，我们不可以在游戏里面直接去接入每个SDK，而是需要将游戏和SDK接入彻底解耦。

2、为了让SDK接入和游戏分离，我们就需要抽象出一个SDK接入框架，屏蔽各个渠道SDK的差异，向游戏层提供一个统一的API调用；这样游戏只需要接入这个框架即可，而无需关心每个具体的联运渠道SDK。

3、然后我们需要实现一个一键打包工具。游戏层接入我们上面抽象出来的统一API之后， Android的话，可以出一个母包apk，iOS的话，可以出一个母工程(xcode工程)；然后通过一键打包工具，就可以打出各个联运渠道的渠道包

4、整套聚合SDK除了客户端部分，还需要服务器端部分，服务端的逻辑分为两个部分：核心业务服务和后台管理系统；其中核心业务服务主要处理各个渠道的登陆认证和支付回调逻辑；后台管理系统主要处理游戏管理、渠道参数配置、用户数据查询、订单数据查询、统计分析等功能。

针对上面这些罗列的点，我们这套聚合SDK框架，应该包含以下几个部分：

接过渠道SDK的同学应该知道， 在对接渠道联运SDK的时候， 最重要的两个功能点是登陆和支付。在聚合SDK框架的设计中，自然也是这两个过程最为重要。接下来我们来设计整个聚合SDK的登陆流程和支付流程。

我们先看登陆流程。如果不使用聚合SDK框架而直接接入SDK，那么渠道联运SDK的登陆流程是什么样呢？我们这里可以看下UC SDK他的登陆流程图：

使用聚合SDK之后，游戏和渠道SDK之间要彻底解耦；所以，聚合Server中我们需要将游戏服务器和渠道SDK服务器之间的直接交互，变成聚合Server和渠道SDK服务器的交互。 我们看下U8SDK中统一登陆流程设计：

我们再看一下整个登陆过程的顺序图，可以更直观地看到这个流程的顺序：

通过新登陆流程和老登陆流程的一个简单对比，我们可以看出：老的登陆认证流程，对于每一款游戏，游戏服务器都需要和每个渠道SDK服务器进行交互；但是使用聚合SDK之后，游戏服务器只需要和U8 Server 进行交互就可以了，全部由U8 Server完成第三方SDK的登陆和登陆认证 *** 作。

接下来，我们再来看支付流程。如果不使用这套框架，游戏中直接接入联运渠道SDK，支付的流程我们以UC SDK为例来说明：

同样的，使用聚合SDK之后，游戏和渠道SDK之间要彻底解耦；所以，聚合Server中我们需要将游戏服务器和渠道SDK服务器之间的直接交互，变成聚合Server和渠道SDK服务器的交互。 我们看下U8SDK中统一支付流程设计：

我们通过对比两个支付流程图可以清晰地发现：新的流程中，通过聚合Server将游戏服务器和渠道SDK服务器彻底解耦；每个渠道SDK功能变化，都不影响游戏服务器。我们再发个顺序图，可以更直观地看下整个流程：

通过上面的分析，我们大概已经清楚，聚合SDK框架中需要实现的功能以及相关流程。那么接下来，我们就会具体的来实现每一个部分：包括抽象层SDK接入框架，一键打包工具，聚合Server，渠道SDK的接入等。

我们在B站录制了视频教程，如果您对U8SDK手游联运聚合SDK感兴趣， 可以看下： U8SDK视频教程
同时，如果您也对手游聚合SDK开发感兴趣，也欢迎关注U8SDK技术博客： >