绿色认证服务网格是一种新颖酷炫的网络工具。它们的价值远不止体现在网络和安全方面，我们很快会看到服务网格出现在几乎每一种微服务架构和堆栈中。
【编者按】如果你对为什么网络是重要的微服务粘合剂很熟悉，那么也许对云原生SDN解决方案和服务网格也已经有所了解。本文具体介绍了自动化SDN和服务网格，在未来，服务网格将出现在几乎每一种微服务架构和堆栈中。
本文首发于SE Daily，作者James Kelly；由云头条编译；供行业人士参考。
在微服务架构当道的新时代下，无论你采用的是容器即服务（CaaS）架构还是函数即服务（FaaS）架构，亦或两者都采用，网络都已变得越来越重要，原因如下：
微服务应用程序组件通过网络相互脱离。它们通过网络重新整合，API作为远程过程调用（RPC），这些RPC已从CORBA和RMI之类的机制、SOAP和REST的昔日Web服务，发展成为像Apache Thrift和更新颖的 gRPC这些新方法，gRPC是谷歌捐赠的一个新的CNCF项目，以实现基于http2的安全又快速的RPC。RPC问世已有很久，但现在的网络实际上很快，足以作为应用程序组件之间一种基本的通信手段来处理RPC，因而让我们得以分解传统的整体式应用程序（monolith）：在传统环境下，服务模块以前总是与更紧密的API通信机制捆绑或结合在一起，这些API通信机制基于包含的软件包和代码库，我们当中一些人可能还记得更复杂难懂的IPC。
每个微服务组件通过复制实例来进行扩展。因而，每个微服务的前端是负载均衡器（它本身就是一个网络组件），但除此之外，服务需要发现所依赖的服务，这一般通过DNS和服务发现来完成。
为了提升处理规模，并增强可靠性，每个微服务实例常常本身与应用程序状态及存储相脱离。状态通过网络来保存。比如说，使用API将状态保存在对象存储、数据库、键值存储系统、数据流队列或消息队列中。还有老式磁盘，但这种磁盘及配套的文件系统也可能是网络挂载的虚拟卷。这些用来存储状态的可通过API和RPC访问的系统本身也是微服务，这种存储方式事实上可能也是使用磁盘的最佳典例。它们还包含大量的分布式存储神奇功能，以兑现所作的各种承诺，这种神奇功能常常是通过网络来执行的。
但愿我们已在为什么网络是重要的微服务粘合剂这点上达成了共识。如果你对此很熟悉，那么也许对云原生SDN解决方案和服务网格也已经有所了解。
服务网格的概念和实现相当新颖。这个话题也备受关注，原因是服务网格可以解决上面提到的网络方面的主要挑战；如果是像CNCFLinkerd这样的新项目和最近发布的项目Istio，其功能远不止这些。
不妨介绍一下服务网格的一些用例和特性，并将它们与SDN解决方案（主要是OpenContrail）进行比较，那样我们就能回答标题中提出的问题：服务网格是“下一代”SDN吗？
自动化SDN和服务网格
首先，不妨看一下使用SDN和服务网格的各种环境中自动化的三大方面：可编程性、配置和安装。
1.可编程性
说到自动化，可编程性必不可少。优秀的SDN不受网络硬件方面的限制，OpenContrail等许多SDN提供了逻辑上集中的控制平面，附带API。上面介绍的两种主要的服务网格也这么处理，它们遵循类似SDN的架构模式：集中式控制平面和分布式转发平面代理。虽然Istio有集中式控制平面API，但Linkerd更加分布式，不过通过其Namerd组件来提供API。大多数人可能会说，这两种服务网格的gRPC API比OpenContrail充分利用REST（RESTful）的API更现代化、更有优势，但是另一方面，OpenContrail 的API与Istio仍很原始的API函数相比，得到了很充分的扩展和测试。
2.配置
除API以外一个更大的区别是如何访问功能。服务网格引入YAML来声明可通过CLI来传达的配置意图。我猜大多数人会一致认为，这与并不提供这项功能的SDN相比是优势（至少OpenContrail现在不提供）。就基于Web的接口而言，服务网格与许多SDN一样，确实提供了这种接口。OpenContrail的Web接口在经历5年的开发后已变得相当高级，但仍感觉很现代、对企业友好。
然而展望“网络即代码”趋势，CLI和YAML在可编程和版本控制方面比OpenContrail 的API调用更容易操作。在OpenStack环境中，OpenContrail可以用基于YAML的 Heat模板来配置，但这对基于容器的K8s和OpenShift环境而言没有太大关系。在K8s环境下，OpenContrail SDN配置被注释为K8s对象。它有意很简单，以便只展示OpenContrail的一小部分功能。可以通过K8s TPR、ConfigMaps或通过某种OpenContrail解释器能完成什么样的工作，仍需拭目以待。
3.安装
Linkerd背后有Buoyant这家公司，这意味着谁都能得到支持，不过一开始上手很简单。与Kubernetes一起部署在DaemonSet模型中，很容易上手。
Istio是全新的，但它已有Helm图，与Kubernetes一起迅速部署。另一方面，使用Istio意味着将Envoy代理捆绑到每个Kubernetespod中，作为sidecar。这是额外的步骤，但借助kube-inject命令，很容易实现。抛开SidecarvsDaemonSet的考虑不说，这种结合会收到一定的奇效，这对于理解后面的调试很重要。
说到SDN，它们是完全不同的wrt部署。OpenContrail在开发一种用于简单部署的支持Juniper的Helm图，而与此同时，社区还提供Ansible playbook和其他同类的配置管理解决方案。
OpenContrail与Istio和Linkerd这两种服务网格有一个共同点，那就是它部署成了容器。一个区别是，每个节点上的OpenContrail转发代理既是用户空间组件，又是内核模块（基于DPDK或基于SmartNIC）。它们是容器化的，但内核模块只用于安装，以便引导insmod安装。内核模块可能让人觉得有点矛盾……内核模块明显会简化性能和与网络堆栈的集成，但是它所使用的资源不是基于容器的，因此没有资源方面的限
