1 前言
本文是在通篇梳理完 ETSI GS MEC 002 V2.1.1 的基础上，从边缘计算来回看SD-WAN：看看SD-WAN可以如何“了却君王天下事，赢得生前身后名”。
作者孵化过基于SD-WAN的云网产品，有一些基本的行业背景和产品经验。不过本文的问题偏大，仅凭自身经验还是有点心虚，所以预先做了一些功课，尝试站在巨人的肩膀上，即在ETSI MEC用例协议的基础上，再来“理论学习结合实际感受”，相对更为踏实一些。
ETSI MEC协议导读是个系列，较干较枯燥，不适合平台风格，如对协议有兴趣，可移步个人公众号，欢迎相关同行交流碰撞。
2 前世
2019年，带头大哥Gartner官宣SDN社死(见下图)，悼词有些悲壮：SDN is Dead; Long Live SDN. 大意是：“SDN挂了，但他的精神永远活在我们心中，阿门”。
SDN为什么给社死了?悼词写得很明白：并不是SDN不好，而是SDN已经深入人心了。该用SDN的，都已经用上了;用不上SDN的，再跟他们去掰扯，也是乌龟壳上找毛——白费劲。既然接下来没啥直接的新市场可以去拱拱了，那带头大哥再不宣布它社死，岂不是容易被居心叵测的小人利用，坑害无辜的创业者和投资者继续掉坑么。
所以，SDN的社死，并非技术理念原因，而是产品形态原因。
离用户远：SDN的主要产品形态是DCI，以及基于DCI的所谓弹性云连接(还有一块是DCN，不过这块离普通用户就更远了，故略)。这是一种什么样的产品形态呢，如果拿自来水管做一下类比，这至少是在市政水管级别：通过SDN改造的市政水管，其底层还是需要依赖挖沟埋管的，革命性的创新在于，通过在市政水管的转接点上加装支持软件定义的设备，就可以快速调整水流大小和水流走向等。基础设施这么一“快”，直接的结果就是可以支持对管线资源的灵活复用，再往上就可以进一步衍生出诸如保底突发、95计费、流量包等多种运营层面的新业务了。但是，话说回来，它的本质还是以干线为主的资源大管道，所以直接用户主要是大企业、大运营商之类。所以，有大网资产需要去降本增效的，都已经用上SDN了，而且用的还挺爽;那些还没用上的“貌似客户”，其实是不太需要，或者说如果有零星需要，可以从已经用上SDN的运营商那里租一份来用一用。
离应用远：SDN不但离用户远，离应用也远。在大管道上，无论是识别应用的粒度，还是操控应用的粒度，都有些力不从心。
3 今生
带头大哥在官宣SDN社死的同时，鼎力支持SD-WAN再升一级，甚至在2020年，更是让其跨界到网络安全领域，宣称它是在未来两年会被采纳的高价值领域(high benefit and less than two years to adopt category)，这个评价甚至高于IPS和WAF(moderate benefit and less than two years to adopt category)。
继承SDN精神的SD-WAN，可以摆脱SDN类产品的机房限制，飞入寻常百姓家，离用户更近，离应用更近。
SD-WAN凭什么比SDN更接近用户，更接近应用?一个直接的答案就在于SD-WAN的CPE。
正是由于CPE的存在，才能让SD-WAN发挥出核心优势，至少是PPT上的核心优势。假设某家企业在硅谷新设了办公室，需要将其接入企业网。如果该企业网是基于SD-WAN构建的，那么对客户而言，需要做的就是：在收到CPE之后，上电插线，然后企业网就建立起来了，就是这么神奇。
在产品界面上，CPE是厂商的关键服务触点之一(另一个是自服务门户页面)，所以必须闪耀出ZTP的光芒。
在网络运维上，CPE也清晰地标定了责任边界：CPE往下，客户负责;CPE往上，供应商负责。
警告：以上只是原理，拿SD-WAN做企业组网，真正要做些什么，请参考 《SD-WAN行业理解：从广域网云化看SD-WAN》 第5.1章，此处不再赘述。
4 身后
SD-WAN也不用高兴的太早，从以上2019-2020的Gartner两图对比中，可以看到带头大哥已经在给SD-WAN安排身后事了，就是图中那个迅速崛起的SASE，一下子从Innovation Trigger窜升到Peak of Inflated Expectations。
SASE可以继续离用户更近，离应用更近，更贴心，更安全，基本满足了当下对未来企业网的所有幻想。
这里直接偷懒，如需了解SD-WAN向SASE的演进逻辑，可以参考：
从广域网云化推演SASE：面向物联网和边缘计算的SD-WAN演进
5 病灶
年纪轻轻的，早早被安排了身后事，总该是被带头大哥看到了一些问题。以下结合摸爬的经验，来找找可能的病灶。
对于疾病，进化论有个挺有意思的观点：疾病是生物进化的产物。即，进化只是让利益和风险在特定的环境下达到了某种适应和平衡。任何一种平衡，都会随着物种自身的发展被打破(这么说来有点悲观)，所以很多疾病的根源，其实正是上一次进化时留下来的优势(比如肥胖和糖尿病)。CPE之于SD-WAN，可能正是如此，它在帮助SD-WAN取代SDN的同时，也成为了一个隐隐发作的病灶，一些比较典型的问题：
1)选什么盒子?MIPS、ARM、x86?一款还是几款?
选一款吧，选高了，销售说价格太离谱，没法卖;选低了，销售说我还有好些客户可是有大带宽需求的，你还要不要赚钱了。
那就试试选多款吧，好，产品经理把硬件成本的帐算清了，那么研发成本呢?研发成本真的能估得准吗?研发团队有设备研发经验吗?做企业级设备和做互联网应用的玩法好像还不太一样吧。另外，销售听得懂研发将会面临的痛苦吗?是话术上的“我懂”还是真的听得懂?此外，多款选型还会进一步带来包括采购、库管、配置等一系列方面的管理成本。
2)一些老牌设备厂商可能没有第一个问题(因为本来就是新瓶装老酒，所以很多时候根本没得选，哇哈哈)，但第二个问题会相对更加普遍。SD-WAN面向的是2B市场吧，2B市场总要做PoC测试的吧。测试会带来哪些问题呢?
老牌设备厂商通过存量和品牌，相对容易占领高端市场，但行业的头部企业毕竟有限，背后的广义资方，是否甘于局限于高端市场，还是要去试一试中长尾呢?
如果要试一试中长尾，那就会出现大量的测试，这些中长尾大多可是不会接受付费测试的。噩梦就要开始了：寄盒子。库管部门出货 -> 交付部门配置 -> 物流部门发货 -> 客户签收 -> 交付部门约客户上线 -> 测试保障 -> 算你产品牛逼，50%转商，那50%还是需要联系客户寄回 -> 库管部门收货 -> 检查测试 -> 库管部门入库。这还是一个偏简单的正常流程，还没涉及一系列的工单流转环节，各地仓库的水位维持，以及一些“常见的意外事件”，例如，客户在方案阶段给的信息有误。
运营团队能支撑吗?市场部门可是已经官(吹)宣(牛)了各项服务的标准时限了。如果能支撑，是能支撑活着，还是能支撑业务跨越式增长?
3)SDN时代遗留下的客户要不要拓展?其中一些其实是涉及到办公室等场景的。如果要把他们升级到SD-WAN产品，那么以往的通过专线接入的云连接站点等怎么建模，要不要CPE?如果不要CPE吧，网络架构会有些“不美”;如果要CPE吧，那是要去机房放盒子呢还是买机房资源做虚拟化呢?要买的话谁买?运维界面又是怎么样的?
以上每个问题的抉择，都会涉及到具体落地，而一旦落地，又会涉及到是不是会背上越来越重的历史包袱(总不能说今天支持了，几个月后就说不干了吧)，有点让人头大。
6 机理
继续推荐Y模型：如果要解决一个具象化的问题，需要再深挖一层在更基础的层面去解决它。让我们从客户视角切换回厂商视角。
以下是主流SD-WAN产品的典型系统架构。
- Subscriber Web Potal：基于Web的自服务门户，一般会与供应商的BSS/OSS系统打通，形成联动。
- Service Orchestrator：编排器，负责将用户在自服务门户上输入的业务意图，编排成一系列的网络服务。服务编排器与自服务门户之间的接口，就是通常所说的北向接口。
- SD-WAN Controller：控制器，负责将各种网络服务，进一步翻译成网络设备可懂的设备语言。控制器与网络设备之间的接口，就是通常所说的南向接口。
- SD-WAN Edge：网络边缘设备，即俗称的CPE，执行具体网络策略的设备。在有些设备商的方案中，会有专门的强大一些的CPE，可以放到POP端做局端设备。
以下是主流SD-WAN产品的典型网络架构。
- 接入侧：CPE-POP之间的网络部分，属于供应商的弱管控范围，底层承载的质量通常不可控。
- 骨干侧：POP-POP之间的网络部分，属于供应商的强管控范围，底层承载的质量通常可控(例如Aryaka的全球二层骨干网)。当然，理论而言，骨干侧并不是必须的，不过如果考虑的大背景是广域网云化，有骨干资源的供应商，会有极大优势。
- 端到端隧道：CPE-CPE之间的逻辑连接，通常这是overlay隧道。基本原理如下：在一对CPE之间，基于用户在自服务门户上输入的业务意图(例如连接两个分支站点)，通过编排器和控制器的编排翻译，向目标CPE下发设备配置，建立起支撑客户业务意图的一条条端到端隧道。
直接为客户提供服务的，正是这一条条的端到端隧道。所有的花活，也就开始在这上面展开来玩。
最简单的的花样：确有一些厂家就是把这条隧道当作SDN业务的补充来做的，也就是，本质上就是在售卖这一条条端到端隧道;只不过与传统的SDN业务相比，由于接入侧可以不必受限于专线，可以大大缩短交付周期，降低整体成本，至少可以做成应急或灾备。按作者了解，很多人对SD-WAN存在误解，最容易的误解，就是把SD-WAN限定到了这个层次。
复杂的花样，就要取决于各自的技术功底了，底层支撑的技术能力越多，可以玩出的花样就越多，当然前提还是要与目标场景相契合，即与自己的目标市场相接轨。绝对不要去羡慕巨头设备商五花八门的功能，更不要去直接抄作业;人家可能正在为自己的肥胖而苦恼，正在寻思着该怎么瘦身呢。
为什么这么说?让我们再来分析一下以上架构中CPE的作用：
- 引流：即把流量送到指定位置，例如最佳的POP点，或者直接到对端的CPE。只要能完成引流，其实就不必局限于某种特定的实现方式。
- 分流：在越接近源头的地方分流，整网的效率越高，用户体验越好;分流的语义越接近应用，越准确，就能做更多的高级处理，整网的效率也会越高，用户体验也会越好。应用识别和应用分流这方面，国内基本已有龙头了，第三次推荐Panabit。
- 传输安全：即对目标流量进行加密，当前的主流CPE形态，大多在使用诸如IPSec之类协议，IPSec天然就支持感兴趣流(这名字可起得真好)，所以传输安全可以和引流一齐完成，但从功能逻辑上来讲，还是需要将他们区分开的。
- 基础安全：基础防火墙等，例如基于五元组的传统ACL方案。个人觉得直接原因是CPE带来了一个新的网络边界，所以CPE至少要保证自己不会成为猪队友。
- 安全能力：指高级安全能力，例如IPS、UTM、NGFW、WAF等等。
- 基础调度：例如在不同物理线路、不同隧道之间的优先级、QoS和抢占等。个人觉得这主要是因为，与SDN类产品不同，SD-WAN产品本身不强调underlay的承载，那么在这样的情况下，怎么去伺候好应用呢?那就至少需要在underlay的线路层面，以及overlay的隧道层面，都能去支持去玩点花样。
- 优化能力：包括多径包复制、FEC，缓存、压缩、去重、协议优化或代理等，因为不同背景的厂商，划分出来的基础能力和高级能力会不大一样，所以这里干脆放在一类。不过发现了没，这些功能已经与CDN功能越来越趋同了。
7 处方
然后就可以从病灶到发病机理到处方了。每个人体质不同，症状各异，相似又不相同的药也是多种多样。所以，谈处方时，更为关键的就是处方逻辑，了解处方逻辑之后，各自的药基本不会相同。所以这一章，只能算药引，药需要自己去抓。让我们再来做一些推导，分析思路如下，仅供参考。
1)首先确认一下是否认可：“SD-WAN的本质是广域网的云化，它的灵魂是应用和场景”。如有需要，可以参考：《SD-WAN行业理解：从广域网云化看SD-WAN》，此处不再赘述。
2)“应用和场景”，天然会有个特点：千差万别，不能一概而论。如此，就会推导出对产品架构的较高要求：产品架构需要足够灵活，需要允许解决方案人员，将“差异化的行业需求”，用“相对稳定的产品”，在“灵活的产品架构”的支持下来搭建。写下这句时，总觉得有些耳熟，再一想，这不正也是5G核心网SBA的演进逻辑么。
3)既然“本质是广域网的云化”，那么很大一方面，是要考虑怎么把产品做出云的客户价值：敏捷、弹性、按量付费。其中，敏捷在一定程度上，是后两者的基础，先聚焦到敏捷。
4)敏捷是云的“客户价值”，所以要重点关注产品的服务触点。
5)之前提了，SD-WAN类产品的服务触点主要有两个：
- Portal：即自服务界面。有些客户是大爷，不会来用portal自服务，但还是要将portal提供给大爷的管家的;此外，此处potal应是广义的，即需要考虑调用API集成。Potal是基于Web的，天然具备了云的客户价值，不是瓶颈(不全对，设备商的视角就容易有问题，不过先略过)。
- CPE：通过以上的「病灶」分析可得，CPE正是个大瓶颈。
6)如此，症结可以归结为：产品的本质要求CPE必须灵活，但在当下主流产品的系统模型里，CPE承担着太多功能，非常不灵活，是一种令人又爱又恨的存在。CPE又为什么要承担着如此重负，是因为跟我们选择的业务方向有关，即受限于业务模型。
7)所以，处方就可以归结为：理解自己业务模型的本质，为每个业务模型设计独立的逻辑CPE功能;如果确有需要支撑多种场景，那就梳理出所有需要支持的业务模型，求助架构师如何综合出适合自己的产品架构。即，在充分析构的基础上再考虑怎么综合(另一句潜台词是：如果受限于能力综合不了的，建议暂时先放弃，从自己最能干得成的事开始一件一件干，精瘦地活着好过虚胖着饿死)，毕竟偏统一的通用架构，一般都是长出来的;而且当相关各方世界观一致时，长出来的架构基本都大差不差。
只不过，那个时候，CPE还叫不叫CPE，SD-WAN还叫不叫SD-WAN，都是未知数。不过，只要能对社会有用，能产生价值，谁还在乎名字呢。
让我们再来验证一下。SD-WAN可以分为名义市场和无形市场，之前多在分析名义市场，今天尝试通过AWS来管中窥全貌。AWS有没有在做SD-WAN?有，有人会觉得就是“Transit Gateway + 合作伙伴的SD-WAN Edge”。如果再把抽象层面拔高一些，AWS的Lambda@Edge有没有在用SD-WAN?AWS的Greengrass有没有在用SD-WAN?AWS的Outposts有没有在用SD-WAN?AWS的Wavelength有没有在用SD-WAN?我想，这些产品的整体架构，应该都是符合以上SD-WAN的典型产品架构，以及SD-WAN的典型网络架的吧。更加极端的例子是，发现某家机器人公司，竟然建有一张SD-WAN网络，然后把它叫做机器人的神经网络(Nerve Network)。觉得它们都可以归结为隐含市场，只不过它们在各自服务的独立场景，是远远超过“40-60亿美元”这个名义市场的，所以是不屑于说自己在做SD-WAN的。这里还有一个有意思的问题：为什么在大家都做的企业组网这个方向，AWS的选择是“Transit Gateway + 合作伙伴的CPE”这条路子?是AWS没这方面的实力吗?可拉倒吧，个人觉得这正是AWS产品规划的厉害之处，在这一个业务方向选择“Transit Gateway + 合作伙伴的CPE”进行落地的原因，很可能在于：
- 企业组网这个业务方向对2B的云计算而言，是必不可少的，是必须得支持的，所以得做;
- 企业组网里的Transit Gateway，产品形态可以符合云的本质，并且可以集成到更庞大的云产品体系里去，所以得自己做;
- 企业组网里的CPE，产品形态无法符合云的本质，也不能纳入到更大的云产品体系里去，不符合AWS作为一家云厂商的定位，这部分赶紧外包出去，又刚好有人要排队进来做这份“苦活”，何乐而不为呢?
所以，如果我们带着“先析构后综合长架构”的思路再去审视一遍CPE的话：
- CPE必须保留的功能也就是引流能力;
- 第二批次的功能是分流、基础调度、传输安全和基础安全;
- 最后批次的功能再是优化能力和安全能力。
即，极端情况下，除引流能力外，CPE的其它功能都可以按场景选取分配。
即，在产品层面，如果要把产品做轻，做的像云，CPE所承担的逻辑功能，必须要能做轻。越轻，越无感，业务越灵活。
显然，直接来讲，那就是直接在选定应用场景，把不需要的功能剥离。这方面，最直接的例子是各个厂家越来越多的App。不过，虽然看上去大家都是App，但不同App在各自的产品架构里，扮演的角色可能也并不相同，有些更像是一个接入端，有些都开始重得有点像个物理CPE了。其实这方面怎么做都可以，就是最好真的知道自己在做什么，发展到下一个阶段时可以复用哪些，等等。
另外，那就是反其道而行，往重量级走，把CPE做大做厚实，然后塞到POP里去，通过复用来实现“轻量化”。这种情况下，最基本得引流，就得通过端或者某种特定的方式来完成。
所以，逻辑上的CPE，会被两头分拆：
- 往端一头，例如侧重强管控的SASE端，主要承担的是引流、传输安全、基础安全能力等。
- 往云一头，或者说往边一头，会转移到在近场/中心的更强大的“带计算的网络设备”，或者“带网络的计算设备”，总之是云网融合设备。在客户侧盒子大爆炸的大背景下，再塞一个不尴不尬的盒子，可能不是长久之计;这个盒子的形态演进，应该需要符合一个更大的基础设施变革逻辑才行。
SASE是SD-WAN的直接身后事，不过目测SASE也是有着名义市场和无形市场的特点的，同样，大概率也是无形市场可能会更为波澜壮阔。在通篇梳理完ETSI MEC的用例协议后，MEC这个方向可能会是一种更大的融合背景。稍后会从MEC用例视角出发，进一步梳理这个逻辑，回看一下SD-WAN所珍视的技术积累，诸如分流能力，基础调度能力，优化能力，可能会被怎样继承并发扬光大，赢得“生前身后名”。
“做SD-WAN”的思路，最好过渡到“用SD-WAN”，即看看需要用到SD-WAN的更大舞台。
8 药引
业务需求是利润需求，架构需求是支撑需求，绝大部分的创业公司都没有太大的战略纵深。所以，一个理想的药引，是最好能在存续现有SD-WAN业务的同时，逐步将产品架构转型至未来形态，从而既能在当下养活自己，也能在未来拥有更大可能。
如果顺着广域网云化的逻辑，应用加速可能是个更好的切入点。当时更多是在生态和市场的角度推导的。现在，就在以上分析的基础上，再从产品的业务模型角度，看一看相关逻辑。
上图中上下两半部分，分别对应着企业组网和应用加速的极简业务模型。它们有什么区别：
明面上，客户可见的业务元素变少了：
- 企业组网：分支站点A，分支站点A CPE，分支站点Z，分支站点Z CPE(必须区分CPE A、Z的原因是规格和形态都可能不同);
- 应用加速：分支站点A，分支站点A CPE，应用Z。
逻辑上，隐含的业务元素缩简就更多了。企业组网里的内网规划、接入模式、连接策略、线路策略，遗留系统支持，等等，在应用加速场景里，基本都可以被排除或被低代价地限定掉。
结果就是，在当前的生态成熟度和技术成熟度下，企业组网因为不可避免会触及到客户内网，注定了是个非标品，而应用加速相对更容易做成标品。标品有什么作用：
- 低切入复杂度：企业组网只是“听着”简单而已，做着可不简单，会遇到大量的现实问题;标品就更容易去切入，注意是说切入，而不是说就受限于此。
- 全方位的低复制成本(前提是匹配的架构支撑)，更接近云的形态。
落地时，隐去的“分支站点Z CPE”又有什么作用：
- 原先暴露给客户的选择题，转变为可以自己作答的小抄题。
- 更早地实地了解一下POP里的逻辑CPE(如果需要有的话;但这也是符合SASE方向的)，需要满足什么样的具体需求，它们与传统的物理CPE必定是不一样的。
- 敏捷是更大的主旋律，越在基础层面做到敏捷，对上层业务的潜在促进作用就越大，即，在产品系统层面敏捷方向上的丁点进步，还是有可能会衍生出运营层面更多更大的创新的，这类创新可能需要在系统就绪后，碰撞自SA团队、BD团队等。
此外，还有一点是值得稍稍宽心的：如果站在更大的云化背景下，企业内网正在被逐步掏空，即，原先需要组内网的内容，正在逐步转变为需要被加速的内容。
所以，应用加速，可能是个广域网云化更好的切入点。
最后，也得承认，可能确实不是所有企业都适合去做应用加速，以上只是作为产品分析的示例。
留道开放题：在应用加速方向，能不能进一步做出下图这样的业务模型呢?它的好处很诱人：客户不再需要任何CPE，可以极为敏捷。如果可以实现，可能会有哪些限制?企业组网是否也能适用?
作者简介：张云锋，云网融合相关行业从业人员
