昨天，我们通过一个案例，对基于大数据的RoCE诊断优化有了感性的认识。我们发现，综合分析来自INT，ERSPAN和gRPC监测到的网络节点信息，是可以先于业务质量的劣化，感知到隐患的存在的。因此，工程师们给这样的解决方案起了一个名字——先知网络。
由于先知网络具有提前预知网络隐患的特性，用户可以利用这一特点，提前规划云平台承载的业务分布。
让我们先看一个栗子。
我们知道，在DevOps时代，应用的发布有蓝绿发布、滚动发布、金丝雀发布等方式。
由于拥有DevOps基础的网工同学实属凤毛麟角，在这里简要介绍几种发布方式：
蓝绿发布的方式如下图：
蓝绿发布的时候，先将新版本应用容器(蓝色)拉起，再将流量切换到新版本，停止旧版本容器 (绿色) 运行。
其流量分布如下图：
为了避免蓝绿发布占用资源过多的弊端，DevOps平台提供者们又开发了滚动发布、金丝雀发布等方式。
滚动发布的方式如下图：
滚动发布在升级过程中，并不立即拉起所有新版本容器，而是逐个替换老版本容器，直到升级完成。其流量模型如下图：
滚动发布的缺点是，滚动升级期间若发现新版本存在严重问题，需要立即回退所有旧版本容器。
因此，金丝雀发布是一种常见的改进。
//注释：17世纪，在英国古典资本主义制度下，煤矿由于瓦斯浓度超标造成的爆炸频发。矿工们为了自身生命安全，发现了携带金丝雀下井，金丝雀可以在人之前感受到瓦斯超标。当工人发现金丝雀晕倒甚至死亡，立即撤出矿井，躲过瓦斯引发的矿难。
金丝雀发布的模型如下图所示：
首先启动一个新版本容器，这个容器就是程序员的金丝雀。测试人员进行充分测试之后，如果没有问题，则再切换一批容器：
此时，可以对新版本做运行状态观察，收集各种运行时数据。当确认新版本运行良好，再逐渐将旧版本容器关闭，拉起新版本容器，直到全部旧版本容器关闭销毁。
金丝雀发布的流量模型：
可见，对于不同的发布方式，有着不同的流量模型。但无论是怎样的发布方式，在交换机看来，都是这样的流量模型：
对于25G的TOR，一般收敛比为2:3。
对于10G的TOR，由于6个40G接口中一般2个用于堆叠（25G模型一般去堆叠为主，可使用VXLAN隧道作为MLAG的IPL，节约2个100G作为上行口），收敛比达到了1:3，也就是说，虽然交换机下挂了480个10G的服务器网卡，但这些服务器产生的对外服务流量，却需要挤在4个40G的上行端口对外发送。
如果交换机在拥塞时无差别丢弃蓝色容器(新版本)和绿色容器(旧版本)的流量，我们发现，这对DevOps团队是巨大的挑战。开发测试团队需要设法确认，新应用性能的瓶颈究竟是交换机的丢包引发TCP重传，还是应用迭代的修改造成的内部原因。
这是传统网络难以解决的。
幸而，在先知网络的帮助下，这一问题有了解决之道。
先知网络可以通过增强ERSPAN，针对蓝色容器监听TCP三次握手，如发现三次握手出现丢失，则判断网络发生拥塞，并通过INT确定拥塞程度，并通过自动下发QoS策略保障蓝色容器流量优先处理。
这样，在先知网络的加持之下，困扰DevOps团队的网络丢包阴云可以消散，大型容器云的阳光必将照遍全球！
今天是本系列的32篇。在IT从业者看来，32是2的整数次方，是一个近乎完美的数字。我们的局域网SDN技术系列也将告一段落。
我们对这个专题带给大家的知识做一个小结：
虚拟化计算和移动化办公引发了大二层、Overlay和网络配置自动化技术，而用户对网络体验的需求又触发了网络运维自动化的演进。为了实现大数据在网络运维自动化中的应用，INT、增强ERSPAN和gRPC技术成为支撑大数据的三足。最终，基于AI的先知网络引擎能够实现网络的自动驾驶，让网络管理员的时间可以用来实现更具有价值的创新。
今天我们的专题，也引发了另外两个专题——容器与微服务网络硬核技术内幕，和网络设备硬核技术内幕。
大家敬请期待！
