什么是云网融合

来源 | 好奇瞅瞅

责编 | 寇雪芹

头图 | 下载于视觉中国

遵循“先理解-后优化”的工程规律，云网在快速融合，所以：不要把“边缘计算”理解成“计算”；不要把“物联网”理解成“网络”；当然，更不要把5G理解成网络。

为什么先务虚

说明一下，为什么要写这么“务虚”的一篇：

1. 在《从广域网云化推演SASE：面向物联网和边缘计算的SD-WAN演进》里，推演了SASE的本质是“面向边缘时代的网络和安全的综合云化”，那么还是绕不开几个问题：什么是“云化”？什么是“网络云化”？什么是“安全云化”？然后才能去继续深入分析SASE，推演可能的行业格局。

• 什么是“安全云化”，有贼心没贼胆，还不敢写；

• 什么是“云化”，什么是“网络云化”，可以给出一些想法。倒不是因为胆子大，而是因为既然把SD-WAN的本质理解成了“广域网云化”，那么在做相关产品时，已经有过一些对两者的思考，所以可以脸皮厚一些，直接整理一下，抛砖引玉。

• 再来说说先“务虚”的另一个原因：如果做产品不先来放空“务虚”一下的话，是很难真正做对“实事”的，这些实事包括：产品规划、产品架构、产品特性、功能需求等等。两个层面的例子：

• • 产品规划层面：如果不理解云，那么就会很难理解：为什么当前很多厂家，尤其是初创公司的SD-WAN产品不容易铺开落地？为什么即使SD-WAN和NFV的技术已经成熟了，但企业侧的NFV接受程度还是不高？为什么与企业侧的NFV相比，SASE的理念会更进一步？SASE最终可能会是一种怎样的产品形态？规划、架构、特性等层面的偏差，是会随时间推移被急剧放大的，进而极大地影响产品中长期的竞争力、研发效率和研发成本。所谓的“一将无能，累死三军”，大概说的就是这个吧。

  • 产品功能层面：那就更加直接了，结合产品需求分析的Y模型：如果只听用户需求就急着去做实实在在的产品功能，舍不得花时间去务虚探探用户需求的本质，那就有点像：你在高速路上载着乘客往前奔，乘客不停在叨逼叨叨逼叨，说你这里错了那里不对，你就一脸委屈或者赌气：“You can you up”，让乘客来把把方向盘，结果大概率就是：开得越快，死得越快。

  
  图1-1：需求分析的Y模型；来源：《人人都是产品经理2.0》

  做一下预告：

  • 务虚的不是一篇，会是一个系列：

  • • 深入理解SASE一：什么是云化

    • 深入理解SASE二：网络云化及演进方向
      

    • 三：什么是云网融合

    • 四：为什么应用优化是未来

    • 五：新的安全范式

  • 也不是为了务虚而务虚，而是为了深入理解SASE；也不是为了理解SASE而理解SASE，而是为了稍后可以更加深入地分析相关的产品机会，比如MEC、物联网。

  
  

  

  什么是云网融合

  承上，云网融合和网络云化是什么关系？如果单从网络视角来看，云网融合等同于网络云化，一个是目的，一个是手段。

  其次，什么是云网融合？这是一个小众领域里的热门词，大多是巨头和大佬在谈，有很多解读，凑不了这个热闹。“不忘初心，牢记使命”，我们的目标是：分析产业互联网下诸如SASE、MEC、IoT之类的产品机会，所以以下就从最朴素的视角来分析。

  云网融合，字面理解就是“云”和“网”融合，没什么好特别解释的；广义理解应该是“应用”和“网络”融合，因为“云”在这个时代语境里，代表了上云的各种应用和服务。

  • 只有这样理解，才能回答一些带刺的问题：在边缘时代，网络是以云为中心，还是以边缘为中心？预料这可能会是一个新时代下的“甜咸豆浆”问题，巨头和大佬的出身，基本决定了答案，届时可以看看热闹，选择吸收。

  • 照着这个理解，云网融合的好手是谁？觉得反倒可能是做“云”这门生意并不成功的Google。Google贡献了一个BBR，一个QUIC，好家伙，这两项可都是旨在动互联网大厦根基的协议。一家做搜索应用的公司，把网络玩得如此通透，图啥？肯定不是为了“为他人作嫁衣裳”，而是为了极致优化它的核心应用。

  • 照着这个理解，再多问一下：SDN/SD-WAN算不算云网融合？初看一下，这是啥跟啥，哪里扯得到边。那么就再回归本源，多问一下：为什么要“软件定义”（SD-, Software Defined）？如果不是为了更好更快更高效地操纵网络去服务应用，要啥软件定义呢。当然，学术派会说SDN/SD-WAN还有什么白牌化，摆脱厂商绑定等优势，嗯，没错，不过我们再来掰扯掰扯：现在有这么多控制器，哪家的控制器可以真正控制别家的设备了吗？现阶段到底是更开放了还是更绑定了？一些课题甚至早早就在考虑怎么统筹支离破碎的控制域了。所以，在当前的产品形态下，说白了可能都还是半成品，北向还远远达不到可以形成一个AppStore之类“应用市场”那种巨大的业务灵活优势，肯定会有下半程。我们花这么大劲，要从历史背景和技术趋势开始推演分析，就是想看看下半程可能会是怎样的落地形态，不是么。

  
  图2-1 统筹支离破碎的SDN域；来源：互联网

  • 云网融合这个方向必然是对的，符合“先理解-后优化”的工程规律，甚至也早已大规模成熟商用，而且你我每天都在重度使用。再回到移动通信网，其中诸如3G接入网中的RNC全称是什么？Radio Network Controller，无线网络控制器啊（4G/5G也有类似网元，选3G是因为网元名字最形象），早已在大规模使用SDN思想了。为什么无线接入网要采用SDN架构？因为只有SDN的“中央集权式”架构，才能让网络资源的调配速度，可以跟上无线信道的快速变化，保障终端用户业务的连续性，又回到了“身在网络，心怀业务”的初衷，这种改动，算不算“云网融合”呢？

  
  图2-2 3G网络架构；来源：http://teletopix.org/3g-wcdma/wcdma-network-architecture/

  所以，作者觉得云网融合还有一个更为广义的理解，应该是：“你们不要绕来绕去扯了，我不懂也没时间听，你们就说能不能解决我的问题”。好像历来只听到乙方在谈“云网融合”，很少听到甲方会主动谈起“云网融合”，为什么？我想甲方只关心问题的答案，只不过有些问题，当前还没最优解，乙方不得不抱起“云网融合”的概念，一边向用户求谅解，一边向内部指方向，一边向伙伴寻合作。所以，说到底，作者觉得掰扯概念不重要，甚至技术也不重要，能结合自身的产品体系，落地原理，服务生产才重要。

  一些必要的注解：

  • 说Google做云业务并不成功是相对AWS和Azure而言的；特别提到Google是因为，动互联网大厦根基这种事，觉得技术难度是其次的，推动行业去认可去落地的难度是天量的。敬佩这类有追求有“技术责任感”的公司。

  • 说RNC是SDN，可能会有严谨的学术派反对，因为3G RAN侧确实没有在大规模使用通用硬件。因为作者认为“能结合自身的产品体系，落地原理，服务生产才重要”，所以没有这个困扰。

  
  

  

  为什么要云网融合
  

  既然这里谈的“云网融合”和巨头大佬谈的概念不太一样，那么“为什么要云网融合”的视角，可能也就不太一样了。

  所有的“为什么”，最终都会归于“需求”这个本源。在上一篇中，引出了网络云化领域“房间里的大象”——5G。这头大象，同样是云网融合领域中的翘楚。

  
  图3-1：5G能力图谱；来源：ETSI

  因为以下分析的基础是承认5G的需求；发现当前对5G诸如1ms这类场景的意义，还有不少质疑，认为4G和固网，已完全够用，5G是个噱头。所以先来快速解释一下为什么直接承认5G的需求：

  • 这是ITU的专家们经过广泛的调研论证得出的，他们是当前这个领域最资深的人。可以挑战权威，不过在挑战之前，建议先了解背景。不过这是通信强相关的小众领域，稍后可以专门介绍一下ITU、3GPP、ETSI之类组织的背景和关系。

  • 所有人在新技术面前，都是容易短视的，甚至包括这些专家们。其实可以从他们为4G命名可以看出来，什么IMT-Advanced，什么eNB (Evolved Node B)，你都“Advanced”了，你都“Evolved”了，那5G该叫什么了？这下傻眼了吧，哇哈哈，。

  • 这是关乎国家安全和利益分配的社会根基领域，必须要看国家意志。看到过一个比较有意思的问题：“日本近年来为什么总是点错科技树”？可能部分有日本故意就是要保持一定独立性的“安全感”的需要，不过更有说服力的原因是：“大国永远是带着日本玩，而不会跟着日本玩”，残酷而现实。5G已经成为一个直接较量的领域，已经形成“Lead Follow or Get Out of the Way”的态势了。质疑者总是容易正确，不过还是建议去做时间的朋友。:-)

  以下就从MEC、IoT、SASE三方面的视角，分析一下为什么要云网融合。

  3.1 边缘计算 MEC

  5G的三大应用场景，无论是ms级时延，还是Gbps级的速率，都决定了5G业务的终结点，不可能继续留在核心网后端的云平台，而需要向数据源或消费地靠近。这里说的是“业务终结点”，而不是“任何网络协议的终结点”，所以就不再是传统意义上的网络，而是依托网络的应用，即“云网融合”，这也正是MEC的根本契合点。如果需要这方面最直观的例子，可以参考《最深的云网融合：多接入边缘计算（MEC）》。

  3.2 物联网 IoT

  5G在设计之初，定位的通信主体就是物。万物互联，一方面意味着海量数据的产生，另一方面意味着海量的物联网设备，这些海量的物联网设备，大多是缺乏“思考”能力的，需要近场网络帮它们实现物物之间的传感、交互和控制。这里说的“传感、交互和控制”，也都不再是传统意义上的网络，而是依托现代网络的应用，即“云网融合”。所以，从这个意义上讲，最好别把物联网当作网络来理解，理解成应用反而会更合适一些；只不过这类产业互联网下的应用，需要设计者理解更多的网络原理。

  3.3 SASE

  SASE号称是面向边缘计算和物联网的SD-WAN演进，那自然也是离不开“云网融合”的。SASE没有5G的标准协议可以精确查看，但基于它的出身背景，不妨碍对它进行相关推演。在面对边缘计算和物联网场景，SASE不再假定固定边界，而是基于身份和其他相关策略，形成动态的信任边界。这意味着：工作在传统边界的设备，诸如网络领域的广域网加速设备，诸如安全领域的防火墙设备，如果还是继续游离在网络之外而没法融入其中的话，就会统统失效。所以，基于一个云化网络的，可以快速向目标区域投放动态边界所需的网络能力和安全能力，是可以充分发挥SASE竞争力的关键。

  
  图3-2：08年空军向汶川震中区域投放“希望“；来源：新华网

  如此，产业互联网下的产品趋势，慢慢都是相通的了，云网融合成为了一个必需。

  所以，不要把边缘计算理解成计算，不要把物联网理解成网络，当然，更不要把5G理解成网络。

  
  

  

  怎么实现云网融合
  

  慢慢从“道”偏向“术”，所以会相对枯燥；不过这里不会涉及很多细节，即使选图也是选择足够示意的简化版本。对哪部分感兴趣，可以查阅对应文档。

  具体怎么实现，如果认同5G是云网融合的翘楚，那么看看5G的演进就能知道个大概。

  4.1 SDN/SD-WAN

  
  图4-1：ONF SDN架构图；来源：ONF

  三个层次：

  • 基础设施层：专注于数据转发。可以是硬件设备：从芯片级到设备级，基本上各个大厂都有。芯片级的有OpenFlow芯片，以及更加灵活的P4芯片；设备级，基本上所有传统大厂都有。也可以是软件形态：比如开源的OVS（Open vSwitch，https://www.openvswitch.org/）。

  • 控制层：整个基础设施层的控制中枢。可以大致分为两类：买设备“送”的，也就是各大设备厂商的控制器；期望自己主导的开源方案，比如OpenDaylight（https://www.opendaylight.org/），以及后起之秀ONOS（Open Network Operating System, https://opennetworking.org/）。

  • 应用层：直接对接业务需求，然后编排成各种网络需求，再由控制器编排出对各个基础设施的控制指令。

  两种接口：

  • 南向接口：控制层到基础设施层的接口。上图来自ONF，所以只画了OpenFlow，但是南向接口不止OpenFlow，包括相对传统的NetConf等，都是可以使用的接口。南向是个容易有争议的接口，Openflow之类协议，支持和顾虑的人，应该都是排着队的，所以还是赶紧闪开。

  • 北向接口：应用层到控制层的接口。大多会采用RESTful API形式，也有大型设备商演进过来的编程接口。

  4.2 NFV

  
  图4-2：ETSI NFV参考框架；来源：ETSI

  三个层次：

  • 基础设施层（NFVI, Network Functions Virtualization Infrastructure）。将各种物理资源抽象成计算/存储/网络资源池。有意思的是，因为这个资源池是暴露给软件的逻辑资源池，所以资源池可以有多大，还会取决于其下的网络能力，SDN技术就是很好的契合点。

  • 虚拟网络层（VNF, Virtual Network Functions）。在虚拟的计算/存储/网络资源池，将原先的物理网元映射为一个虚拟网元，所以叫VNF。

  • 运营支撑层（OSS/BSS, Operations/Business Support Systems）。OSS，运营支撑，BSS，业务支撑；它们直接对接内部的运营需求，以及外部的业务需求。

  接口部分相比SDN要复杂，而且因为是由ETSI在规范，所以话风都变了，称为参考点（reference point）。ETSI NFV框架在稍后分析5G以及MEC时，会重点涉及，暂不展开。

  4.3 大融合

  ETSI的NFV框架如何运作？OSS/BSS对接了客户和运维，MANO（Management and Orchestration）对接了OSS/BSS；MANO会将一个业务需求，自顶向下分解编排，直到可分配VNF资源为止；然后对应的VM等资源，由NFVI来分配，对应的VNFL资源（可以认为VNFL是连接资源，暂不展开介绍，后续梳理MEC时会重点展开），需要与承载网的网管系统交互，由承载网来分配。

  
  图4-3：NFV支撑端到端网络服务示意图；来源：ETSI

  以上，“与承载网网管系统交互，由承载网来分配”说的是可以与SDN系统集成。事实上，ETSI已经在融合NFV和SDN了。

  
  图4-4：SDN控制器在NFV框架中的集成位置；来源：ETSI

  以上，如果参照OSI参考模型，SDN/SD-WAN主要在软件定义2-3层，比如交换机、路由器等；NFV主要在软件定义4-7层，比如防火墙，负载均衡等。

  
  图4-5：OSI参考模型与对应的TCP/IP协议栈；来源：互联网

  如此，整个协议栈都可以软件定义了，再加上两者都推崇的硬件解耦，就在物理上和逻辑上，都达到了“敏捷”、“弹性”、“按量付费”的技术特点，就又回到了“网络云化”、“云网融合”了。如果你把OSI理解成了网络，那就是“网络云化”；如果你认为OSI包含了应用，那么就也做到“云网融合”了。

  之前提到5G是云网融合方面的好手，那我们最后就反过来看一下5G的大致的演进逻辑：

  • 核心网NFV化

  • • 核心网元虚拟化，硬件解耦。

    • 核心网元模块化，并采用SBA架构，逻辑解耦。

  • 接入网NFV化

  • • 分离成AAU、DU、CU；CU进一步NFV化。如此，完成“力所能及”的硬件解耦和逻辑解耦。说“力所能及”是因为还有OpenRAN的存在，暂不展开。

  • 承载网SDN化

  • • 变态的需求导致了变态的架构，变态的架构导致了变态的部署模式，变态的部署模式进一步导致了大量的3层动态组网需求，进一步导致了SD-WAN演进。

  太啰嗦了，有没有更直接的例子？有啊，以上不就是大名鼎鼎的“切片”了么。:-)

  
  图4-6：5G切片实现框架；来源：https://en.wikipedia.org/wiki/5G_network_slicing

  
  

  

  后记

  预测趋势要比预测时间点简单得多，一些分析判断：

  • 5G、物联网、边缘计算等技术革新，不是为了技术而技术，而是为了能将数字化、信息化、智能化，从消费互联网行业，延展到更为广阔的产业互联网领域。尤其是5G，它不再只是通信那么简单了，更是为了延续产业革命而生。最直接的作证：为什么一个国家可以突破想象力的下限，不要脸到直接下场去干涉一家5G领军企业？没被逼急时，人都是要脸的，更何况是长期以灯塔自居的美国——因为太重要了。

  • 为什么产业互联网重要？因为第三次科技革命所能支撑起的消费互联网，已经接近尾声了，存量搏杀越来越激烈，政府、企业，都迫切需要新的增量来安抚“不安的灵魂”。除了入网人数增长乏力外，一些其他可以看出“尾声趋势”的迹象：

  • • 创新的层次越来越高，很多都已经不得不滑入到业务模式创新了，譬如被官媒点名的“社区团购”。这生意合法吗？完全合法。那为什么巨头要被点名？因为你们号称是“科技巨头”啊，这种“创新”，还没开始就可以预见结局了——大资本支持下的小贩挤压和行业垄断，客气点说，已经很难判断社会价值和社会问题，哪个会更大一些。

    • 争抢的越来越激烈。消费互联网越接近尾声，在争抢的就越成了“国民总时间”。抖音产品大成了，用户停留时间长了，那么微信朋友圈的停留时间就不可避免地减少了，瞎猜这也是微信推出了短视频的原因之一吧。

  • 那当下产业互联网为什么难做？除了技术原因之外，需要的主流创新模式不同。越上层的创新，复制起来也相对越快，这也客观造就了当下能直接复制解决的问题，大部分都已经解决了。那为什么从消费领域往产业领域渗透时，就复制不过去了？因为跟消费互联网是个大池子不同，各个产业领域当下还是待开发地块，有着大量的现实的“坑”需要躬身去“踩”；这些不是快钱，习惯上层创新赚2C快钱的互联网公司，不一定能忍受这种孤寂和苦哈哈，反倒是传统行业的从业者，相对更有这种品质。这种情况下，需要ICT（Information and Communication Technology，信息和通信技术）领域与各个行业领域，能有更加广泛而深入的交流与融合，在原理层面相互理解贯通，才有可能孵化出更有意义的产品。

  关于SASE，我们还有

  触手可及的网络云化，它的主战场落在哪？
  

  SASE 本质探究：什么是云化

  

  更多精彩推荐
  

  ☞5G、射频、奥特曼，这仨有联系吗？☞再见 Nacos，我要玩 Service Mesh 了！☞急！CPU 被挖矿，该怎么找进程？☞立即生效！帕特·基辛格卸任 VMware 所有职务
  

  点分享点收藏点点赞点在看