原文链接：https://www.servicemesher.com/blog/201910-what-can-service-mesh-learn-from-sdn/

前言

如果具有通信或者网络行业的知识背景，那么你对SDN(Software Defined Network)一定不会陌生。你也许已经注意到，近来在微服务领域兴起的Service Mesh和SDN(Software Defined Network) 非常相似，这两者都采用了软件对网络进行管理和控制，也都采用了包含控制面和数据面的类似架构。

那么Service Mesh和SDN有什么关系？Service Mesh是下一代的SDN吗？ Service Mesh是否可以从SDN的发展历史中借鉴一些经验？本文将就这些问题进行一一探讨。

传统网络面临的挑战

首先我们来回顾一下SDN的起源。传统的IP网络是一个分布式的无中心架构，各个网络设备包含完整的控制面和数据面，单个设备通过网络协议探测网络中其他设备的状态，自主决定如何对流量进行路由。该架构的好处是容错性强，即使网络局部出现故障，整个网络也可以自主恢复，不会影响整个网络的运行。

这种去中心的架构在基于文本和图片的web浏览器应用时代运作良好，但随着互联网业务的爆炸式增长，各种各样的业务纷纷承载在了IP网络上，包括各种实时业务如语音视频通话，对网络提出了新的挑战。

• 缺少网络质量保证： 绝大多数IP网络都是基于无连接的，只有基于大带宽的粗放带宽保障措施，缺乏质量保证和监控，业务体验较差。
• 低效的业务部署： 网络配置是通过命令行或者网管、由管理员手工配置到网络设备上，并且各种网络设备之间的控制命令互不兼容，导致业务的部署非常低效。
• 缓慢的业务适应： 业务由硬件实现，导致新业务的开发周期过长。需要持续数年的特性和架构调整、引入新设备，才能推出新的业务，无法快速适应市场，满足用户的需求。

SDN如何解决传统网络的问题

为了应对这些问题，提出了SDN的解决方案，SDN的架构如下图所示：

从图中可以看到，SDN从下至上划分为三层体系结构：

• 基础设施层（Infrastructure Layer）： 是网络的数据平面，由各种网络设备构成，根据控制层下发的路由规则对网络数据进行处理和转发。
• 控制层（Control Layer）： 是一个逻辑上集中的控制平面，维护了整个网络的信息，如网络拓扑和状态信息等，控制层根据业务逻辑生成配置信息下发给基础设施层，以管理整个网络的运行。
• 应用层（Application Layer）：通过控制层提供的编程接口，可以编写各种应用利用控制层的能力对网络进行灵活的配置。

SDN的不同层次之间采用标准接口进行通信：

• 南向接口（Southbound API）：数据面和控制面的接口，控制面通过该接口将路由和配置下发到数据面，该接口一般使用OpenFlow、NetConf等网络协议。标准的南向接口解耦了控制层和基础设施层，只要支持标准南向接口的交换机都可以接入到SDN网络中，这样基础设施层可以大量采用支持OpenFlow协议的白盒交换机，解除了厂商锁定，降低了网络成本。
• 北向接口（Northbound API）：控制面向应用层提供的可编程接口，例如RestConf接口。利用控制面提供的编程接口，新的网络业务可以通过存软件的方式实现，大大加快了推出新业务的周期。

微服务面临的问题

在一个微服务系统中，各个独立的微服务之间采用远程调用进行通信。服务发现，请求路由等服务通信相关的功能以代码库的形式存在于各个微服务之中。

该架构也存在和通信网络类似的问题：

• 不同语言/框架的代码库版本中关于服务通信相关的配置完全不同，需要对不同的微服务单独进行配置，导致微服务的运维非常困难。
• 应用和服务通信之间的代码耦合导致修改或者增加新的服务通信功能需要修改并升级所有的微服务，如果需要引入新的运维功能，例如支持灰度发布等，则需要修改并升级所有微服务，代价非常大。

Service Mesh是下一代SDN吗？

从上面的分析可以看出，SDN和Service Mesh面临的是类似的问题，既然都是解决类似的问题，那么Service Mesh是否可以看作下一代的SDN呢？

我认为答案是否定的，因为两者之间还是有显著的不同。SDN主要面对L1到L4层，即网络层的基本转发和控制功能；Service Mesh则主要面对L7层及以上，用于处理应用层的服务发现，服务路由等功能，但两者采用了相似的理念，我们可以把Service Mesh看作SDN的理念在应用层的扩展和实践。

Service Mesh可以借鉴SDN的架构来解决微服务系统的服务通信的相关问题，如下图所示：

我们可以看到，基本上所有的Service Mesh实现都采用了类似上图的的架构，包括Istio，Linkerd，Kuma等。

在该架构中，数据面承担的是一个白盒交换机的角色，不管何种实现，其功能都是类似的，不存在太多争议，目前envoy已经成为数据面的标准实现，因此数据面和控制面之间也采用了Envoy的xDS v2作为标准的数据面协议。

各个Service Mesh项目的创新和争夺的战场主要在控制面上，Microsoft等公司提出了采用SMI（Service Mesh Interface）作为控制面的标准接口，虽然SMI得到了Linkerd，HashiCorp, Solo.io等一干公司的支持，但目前影响最大的Service Mesh项目Istio还未对此进行表态。缺乏统一的控制面标准，控制面之上的应用层生态目前还没有发展起来，基本没有看到有项目对应用层进行宣传。

统一管理硬件设备和Envoy

SDN给Service Mesh带来的一个重要启发是控制面对数据面各种网络设备的统一控制，那么是否可以采用Service Mesh控制面对硬件设备和软件代理进行统一控制呢？

F5网站上提供了一个F5 Big IP和Istio集成的案例。在该案例中， Service Mesh中的微服务需要和一个外部数据库系统进行通信，为了对数据库进行保护，在数据库前放置了一个F5 Big IP设备作为反向代理，并进行下述配置：

• Service Mesh中的微服务通过F5 Big IP作为代理和后端的数据库通信
• F5 Big IP和微服务之间采用mTLS，F5 Big IP和数据库之间采用Plain TCP
• F5 Big IP采用spiffe对微服务进行身份认证，只允许需要访问该数据库的微服务的请求通过

F5的该案例证明了Service Mesh和F5设备之间集成的可能性，但是需要在F5 Big IP设备上进行一系列复杂的配置操作，包括开通服务端口，配置TLS证书，设置认证和访问策略等等。如果Service Mesh控制面可以将F5设备也纳入统一控制，通过控制面统一下发规则，则可以极大简化网络的配置工作，加快业务下发的敏捷性。

利用控制面接口开发应用

SDN的另一个优势是可以通过控制器提供的北向接口快速开发各种SDN应用，而不需要对硬件进行升级，这种模式加快了新业务上线的周期，鼓励各种创新业务蓬勃发展。目前Service Mesh在应用方面尚未有太多实践，但从SDN的发展历程来看，Service Mesh应用层有极大的发展空间。

下图是一个利用控制面接口开发的用户业务订阅及SLA管理的APP示例：

1. 用户通过APP管理界面订阅服务，并设置SLA（服务水平协议），包括服务的请求次数，服务的响应时间等等
2. APP将用户订阅及SLA约定转换为运维策略,调用控制面提供的编程接口下发给控制面
3. 控制面将运维策略转换为数据面标准协议下发给数据面的代理，在代理上，运维策略被转换为代理的配置和转发策略
4. 代理在收到用户请求时，根据用户标识对用户进行认证，并根据配置和路由策略对用户请求进行处理，例如根据SLA处理用户请求的限流策略，系统忙时优先转发高SLA等级的用户请求，等等。

上面只是一个非常简单的应用示例。通过对Service Mesh控制面提供的流量控制，安全策略，拓扑信息、性能指标等基本能力进行组合，并加以创新，可以创建大量端到端的高附加值业务，例如支持业务平滑升级的灰度发布，测试微服务系统健壮性的混沌测试，微服务的监控系统等等。

总结：他山之石，可以攻玉

SDN和Service Mesh的出现都是为了解决类似的网络通信问题，两者都采用了“数据面+控制面”这种类似的架构，但位于网络协议的不同层次。Service Mesh并不是下一代的SDN，但通过借鉴SDN的发展经验，Service Mesh也许可以向下面这些方向发展：

• 北向接口：北向接口面向业务和运维，具有较高的抽象层次，比较容易提取统一的控制面标准。目前已经有多个公司支持采用SMI作为统一的控制面标准。但SMI的发展也存在一些挑战，例如如何避免SMI成为不同Service Mesh实现之间的最小公共子集，如何扩展支持除HTTP之外的其它应用层协议？
• 南向接口：Envoy的xDS v2已经成为了南向接口的事实标准，但xDS接口包含有较多实现相关内容，例如Listener, Filter等，这些限制是否会妨碍Envoy之外的其它兼容数据面实现？
• 对硬件的控制能力：Service Mesh控制面可以提供对数据面软硬件的统一控制能力，以减少软硬件混合环境下的运维复杂度。
• 应用层的发展：通过北向接口（控制面编程接口）提供出来的能力，可以开发各端到端的创新应用，这也许会成为Service Mesh的下一个热点。

这篇的原文链接：https://zhuanlan.zhihu.com/p/56062418

推动人工智能爆发的最主要原因之一，就是硬件算力的提升。而英伟达的股价当年之所以能够三年涨10倍，就是因为GPU非常适用于深度神经网络的训练。与传统的CPU相比， GPU拥有数千个计算内核，能够在性能上取得上百倍的提升。因此AI就成为了GPU最主要的应用领域之一，也成就了英伟达的高速增长。

随着AI的不断发展，诸如微软和谷歌这样的巨头公司开始考虑在数据中心里采用GPU作为AI加速芯片，这时问题就出现了。在大量部署时，芯片的性能并不是唯一需要考虑的因素。事实上，很多情况下它也并不是最重要的因素。

对于某种AI加速芯片，老石将常见的评价因素总结为五点：性能、灵活性、同构性、成本和功耗。其中：

• 灵活性：指这种芯片对不同应用场景的适应程度。
• 同构性：指的是AI加速芯片能否重复利用数据中心现有的架构和资源。
• 成本：既包括对该硬件加速器的研发投入，也包含了它的采购、部署和运维开支。
• 功耗：就是指引入该方案后，对数据中心带来的额外功耗负担。

接下来，老石就对几种常见的AI加速芯片，比如GPU、FPGA以及ASIC，采用上述评价因素做一个简单的定性对比。

*GPU*

GPU最大的问题是，它基本上是个“功耗黑洞”：中等性能的GPU功耗都普遍超过200W，而高性能GPU的功耗会超过300W。相比于FPGA或ASIC的几十瓦甚至几瓦的功耗而言，这个数字显得过于惊人。

高功耗对于GPU在数据中心里的大规模部署是致命的，因为这不仅代表着高昂的电费开支，还表示数据中心现有的供电、散热等硬件架构需要进行重新修改，这对于同构性和低成本这两项要求而言基本上是不可能的任务。

在灵活性方面，GPU通常只适用于计算密集型运算，对于通信密集型的应用，GPU需要与CPU和网卡组成一个完整的通信系统，因此对于这类应用，GPU的灵活性会受到较大限制。

*ASIC*

专用的AI加速芯片以谷歌的张量处理器TPU（Tensor Processing Unit）最为典型。TPU专为谷歌的深度学习框架TensorFlow设计，现在已有第二代，被用来加速神经网络的和决策。ASIC最主要的优势是它的超高性能和超低功耗。与GPU相比，TPU在某些AI应用的性能可以提高一个量级，而功耗会下降一到两个量级。

不过，得到这样高性能和低功耗需要付出的代价就是巨大的研发成本。放眼全球，有资金实力和技术储备进行这类研发的公司，大概用一个手就能数的出来。ASIC的另外一个缺点是它的低灵活性，它通常针对某种特定的应用和算法框架而设计，因此很难直接用于其他的应用。

*FPGA*

相比GPU和ASIC，FPGA在各项评价指标中能够达到比较理想的平衡。在绝对性能方面，虽然不如GPU或ASIC，但由于FPGA可以定制化硬件流水线，并且可以进行大规模并行运算，因此相比传统的基于CPU的计算性能还是有着至少一到两个量级的提升。由于FPGA具有硬件可编程的特点，使得它可以应对包括计算密集型和通信密集型在内的各类应用。此外，FPGA独有的动态可编程、部分可编程的特点，使其可以跨空间和时间两个维度，同时处理多个应用，或在不同时刻处理不同应用，因此有很强的灵活性。

功耗和成本方面，FPGA的功耗通常为几十瓦，采购与运维成本远低于GPU。FPGA的开发成本主要涉及购买特定的FPGA设计和调试工具、采购FPGA芯片或加速卡，以及组建团队进行或外包FPGA开发项目等投入。虽不及CPU或GPU等基于软件的开发方式，但由于省去了FPGA芯片制造的相关环节，因此相比研发一款专用芯片而言还是低很多。

此外，FPGA目前通常以加速卡的形式配合现有的通用处理器进行大规模部署，对额外的供电和冷却等环节没有特殊要求，因此可以兼容数据中心的现有硬件体系结构。

AI芯片的最大风险

对于AI芯片的设计者而言，当前最大的风险就是AI本身。在这个群雄争霸的时代，各种新算法、新模型层出不穷，因此在某种方法一统天下之前，很难将其中的任何一种方法固化在芯片上，否则就很可能再次重演以前的小甜甜变成今天的牛夫人这样的悲剧。

比如，为了进一步提升性能功耗比，目前比较流行的方法是使用近似（approximation）算法，例如将双精度浮点数换成低精度的定点数，或者对不同权重的网络分支做剪枝、结构优化和压缩的操作。

这些不断涌现的全新AI方法只有通过FPGA才能快速实现，这对于GPU或者ASIC都是不可能完成的任务。

结语

正如老石在之前的文章里提到的，数据中心与AI已经成为各家芯片公司的必争之地。只不过，近期资本市场的表现在某种程度上展示了人们对不同方案的认可度。这也是老石在本文中尝试分析的。

然而，老石并不想立flag断言这些公司的未来，老石只是相信，技术会不断给出自己的答案。

这篇的原文链接：https://zhuanlan.zhihu.com/p/84367537

今年6月，英特尔宣布收购一家名为“Barefoot”的公司，旨在帮助英特尔的数据中心部门“更好的应对云数据中心客户的不断变化的各类需求”。伴随着收购，Barefoot的CEO兼总裁，Craig Barratt博士（下图右）被任命为英特尔数据中心部门旗下“互联事业部（connectivity group）”的总经理，负责英特尔以太网控制器、网卡、交换芯片等一系列网络互联产品。

很多读者也许并没有听说过Barefoot这个公司。事实上，它的飞速发展已经对诸如博通和英特尔等传统网络交换芯片厂商形成了逼宫之势，大有一种“光脚的不怕穿鞋的”之感。

在这篇文章中，老石将详细解读这家“赤脚”公司的四大核心竞争科技：

1. 一种编程语言：P4
2. 一种可编程芯片架构：PISA
3. 一种编译器与工具链：P4 Studio
4. 一种可编程网络芯片：Tofino

文章最后，老石将分析Barefoot的这些“黑科技”对FPGA在网络应用的影响。

一种编程语言：P4

早在2014年，Barefoot与英特尔、谷歌、微软，以及斯坦福大学和普林斯顿大学联合发表了一篇名为《P4：Programming Protocol-Independent Packet Processors》的论文，这也代表着P4编程语言的正式诞生。

P4本质上是一门针对网络数据包处理的领域专用语言（Domain Specific Language）。从它的全称可以看出，P4最主要的特点就是与具体的网络协议无关，这与当前正在蓬勃兴起的SDN（软件定义网络）概念不谋而合。

在一个SDN网络中，通常可以将其划分成控制平面和数据平面两部分，这也是它有别于普通网络的最本质特点。其中，控制平面负责对数据平面的各种网络设备进行集中管理和配置，二者通过标准化的接口进行互联。控制平面往往基于标准CPU实现，因此有着很强的可编程性。而数据平面的传统实现，则是基于各家网络设备厂商、针对不同网络功能提供的各种设备。这样的实现方式，说好听一点是“百花齐放”，说现实一点就是“杂乱无章”、“各自为战”。由于各种设备和网络协议之间的兼容性和通用性不足，极大的限制了SDN数据平面在规模和功能上的扩展能力。

在现有的SDN网络中，控制和数据两个平面之间的标准化接口通常使用OpenFlow，很多网络设备供应商也相继推出了很多支持OpenFlow编程的网络硬件。然而，OpenFlow标准与网络协议紧密相关，它的多次版本更迭都是为了增加对更多协议的支持，见下图。

随着网络流量的爆炸性增长，各种新的网络协议层出不穷，比如在云数据中心里，各类隧道和封装协议（如VXLAN等）已经被普遍采用。除此之外，很多网络设计者也希望使用自定义或非公开的网络协议，以更好的满足自己和客户的定制化需求。这些新型的应用场景，一方面需要OpenFlow不断更新标准，另一方面需要硬件厂商不断更新硬件，以支持这些新兴协议。而这不管从成本还是时间上看，显然不能满足网络的发展需要。

事实上，P4诞生的最主要目的就是为SDN的数据平面提供协议无关的可编程能力。如下图所示，网络设计者可以通过P4定义数据平面的转发和处理规则，例如报头解析、匹配、表项配置等，然后通过编译器在目标交换机上进行实现。

P4作为一个开源的领域专用语言，发展至今天已有相当的规模，拥有包括英特尔、赛灵思、微软、谷歌、思科、阿里、腾讯等几十家科技公司和大学的代码贡献和支持。

值得注意的是，OpenFlow和P4均出自一个大师的手笔，那就是斯坦福大学教授Nick McKeown。作为SDN的提出者和先驱，他先后发起成立了开放网络基金会（ONF），以及负责制定P4标准的http://P4.org。此外，他也是多个初创企业的创始人，其中就包括这篇文章中介绍的Barefoot：McKeown教授在Barefoot公司担任联合创始人和首席科学家。

业界有“一流的企业做标准”的说法。Barefoot公司作为P4语言的主要发起者，又由SDN领域最有权威的大牛创办，因此在业界的影响力不言而喻。

一种可编程芯片架构：PISA

Barefoot的核心竞争力之一，就是提出了一种通用的、协议无关的、可编程的交换机芯片架构：PISA（Protocol Independent Switch Architecture）。

PISA的架构示意图如下所示。它的主要数据通路是由大量“匹配-动作”单元以流水线的方式组合而成。在流水线入口，有一个可编程的包头解析器，负责对数据包进行预处理和解析。此外，流水线还有一条回流路径，适用于数据包需要进行多次解析和反馈处理的情况。

对于每个“匹配-动作”单元，它的微架构如下图所示。可以看到，它里包含多个并行的由SRAM和TCAM组成的查找表单元，可以同时进行大量的精确匹配和三元匹配。查找后的表项再通过ALU进行计算和修改，组合成新的包头传递到下一级流水线。

PISA这种架构由通用的逻辑单元和流水线组成，因此与具体协议无关，并且可以通过编程实现各种标准或自定义的网络包处理规则，而无需进行架构修改，如下图。

一种编译器和工具链：P4 Studio

有了编程语言P4和底层架构PISA，自然需要编译器将二者进行映射。为此，Barefoot有着名为P4 Studio的编译器和开发套件。它的功能就是将P4语言描述的数据包处理规则，完整、正确的映射到PISA架构上。其功能架构如下图所示。

P4 Studio主要包含以下几个主要部件：

• P4编译器、调试器和IDE。
• P4语言的仿真环境和测试框架。
• 底层硬件的通用接口和驱动。
• 对开源网络操作系统的支持，如HPE的OpenSwitch、微软Azuere的SONiC和Facebook的FBOSS等。

有了全新的编程语言、编译器和系统架构，一款全新的可编程网络芯片就诞生了。

一种可编程网络芯片：Tofino

Tofino是Barefoot推出的首款可编程交换芯片，它基于台积电16nm FinFET+工艺制造。在推出之时，Barefoot称这款芯片是世界上最快的交换芯片，性能可以达到6.5Tb/s，与博通等公司的旗舰产品性能不相上下。同时，Tofino基于PISA架构，能通过P4语言进行现场编程，又有着ASIC基本的功耗和成本数据，这也是它有别于其他“传统”网络交换芯片的最大特点和优势。

Tofino的芯片架构示意图如下所示。可以看到，Tofino有着4条PISA架构的流水线，并通过同一个TM负责四条流水线之间的流量调度和管理，最多可以支持130万条IPv4路由。在每条流水线里，包含16个100G MAC，也可以配置成10G/25G/40G/50G等多种模式

目前，Barefoot又推出了第二代Tofino芯片，它基于7纳米工艺制造，性能提升了一倍，最高支持12.8Tb/s的数据包处理速率。

基于P4的可编程网络芯片对FPGA的影响

网络数据处理和加速一直是FPGA最主要的应用领域，在之前文章中曾介绍过，英特尔近期刚刚进行了组织架构调整，将FPGA和网络平台部门合二为一，足可见对FPGA在网络领域的重视。在SDN和NFV的应用中，也有很多实用FPGA进行网络功能卸载和加速的案例，在老石之前的文章中也详细介绍过的智能网卡等等。

不过，FPGA的开发难度一直是制约其广泛使用的最大障碍之一。因此，使用诸如OpenCL等高层次语言对FPGA进行编程开发就成了业界和学术界研究的热点之一。

近年来，这类研究的重点开始转向对领域专用语言的探索，正如网络领域的P4语言。前文提到，英特尔和赛灵思都是http://P4.org的成员和代码贡献者之一，两家公司都在进行使用P4语言编程FPGA的相关研究。

在2019年的FPGA大会上，赛灵思和Nick McKeown教授以及剑桥大学联合发表了一篇讨论P4编程FPGA的论文，它使用了赛灵思的P4-SDNet编译器生成底层Verilog代码模块，然后映射到名为“NetFPGA”的参考设计上，见下图。

对于英特尔，在收购Barefoot之前，它就也已经开始了P4编程FPGA的研究，在最近发表的一篇白皮书中（下图），英特尔和Netcope公司合作开发了一款使用P4编程FPGA智能网卡，并得到100G吞吐量的应用实例。此外，P4语言的最初作者之一Dan Daly，一直在英特尔担任主任工程师。在收购Barefoot之后，相信对无论是FPGA还是ASIC在内的各种英特尔芯片采用P4编程会是极大的促进。

结语

Barefoot作为一个“出身名门”的初创公司，很好的把握了现在网络体系架构发展的最大痛点，提出了已经成为业界标准的P4语言，开发了对应的PISA芯片架构和编译器，并做出了两款可以完全编程的高性能网络交换芯片，可以说构建了完整的技术闭环。如今被英特尔收购，对双方都有极大的好处。Barefoot的整个创业过程和理念，值得各家芯片创业公司借鉴。