颠覆和冲击：Service Mesh vs 网络、防火墙、中间件

云头条导读：本文由三篇文章组合而成，主要介绍服务网格（Service Mesh）对网络、防火墙、中间件带来的革新和机遇。作者分别是：侧重技术基础设施领域的研究分析公司AvidThink的创始人兼负责人Roy Chua、云原生网络安全提供商Twistlock的首席技术官John Morello、CloudOps的资深云开发师Flo Adam。

服务网格（Service Mesh）是一种专门用于处理服务间通信的基础设施层。它负责通过组成现代云原生应用程序的复杂服务拓扑来可靠地传递请求。

简化版服务网格架构体系

实际上，服务网格通常实现成一组与应用程序代码部署在一起的轻量级网络代理，应用程序无需感知这个情况。

服务网格会颠覆网络界！

竭力向应用程序开发人员（简称AppDev）表明网络的重要性可能困难重重。对于许多AppDev来说，网络其实并不存在，这倒不是说AppDev不明白网络对于确保他们的应用程序顺畅运行至关重要，而是说他们懒得关心。下面这张图可能很适合：

负载均衡的基础知识

从AppDev和DevOps的角度来看，网络团队要么处理应用程序开发人员不太关心的任务、施行魔法，要么更有可能同时执行这两项任务。一旦DevOps推出了部署，大家都认为魔术就会发生、应用程序就会正常运行。实际上，网络团队和安全团队最终会争相确保应用程序的所有要素都已连接并受到保护，而且应用程序可以扩展，如果应用程序的拓扑结构或部署位置发生了变化，就更是如此。

然而，大多数开发计划通常没有考虑到部署的这最后一个阶段，因此AppDevs和DevOps人员对网络和安全感到沮丧。相应之下，网络运维（NetOps）和安全运维（SecOps）团队抱怨没有得到足够提前的通知来进行更改。然而，DevOps及其他所有人很讨厌“提交重新配置网络的工单，等上2周”这样的套话。

AppDev和DevOps人员憧憬将来可实现L3可达性（L3 reachability），这是他们希望从NetOps获得（跨多个私有云和公共云）的功能；除了用于服务网格和几项监控服务的端口外，所有端口都确保安全，这正是他们需要从SecOps获得的功能。他们认为，如果NetOps和SecOps仅仅专注于为他们提供这一点，他们可以灵活敏捷地处理其他部分：服务发现、路由、负载均衡、扩展、加密、可见性，甚至应用程序层安全。

这时候，服务网络有了用武之地。服务网格层实际上处理网络和安全在一个预敏捷、预容器、预微服务、预多云的环境中竭力提供的功能。

ADC和SLB式微？

由于谷歌、Red Hat和IBM支持Istio及底层的Envoy代理，应用交付控制器（ADC）及其传统的同名服务器负载均衡器（SLB）似乎在未来发挥的作用可能更有限了。F5这家老牌的ADC公司正试图以Aspen Mesh拥抱未来，这个商业支持的服务网络产品基于Istio。Aspen Mesh的品牌推广团队明白传统品牌具有的吸引力，没有宣传根源出自F5。其他ADC公司会如出一辙，要么在Envoy的上面添加新的逻辑作为Istio的替代方案，要么基于Istio提供更好的可管理性。Solo.io及其SuperGloo项目甚至还带来了一个新的类别：服务网格编排器。

与此同时，我们会看到供应商试图捍卫地盘，可能试图将入站南北流量使用场合与东西流量使用场合分开来，ADC历来在前一种使用场合占主导地位，而服务网格扎根于后一种使用场合。HAProxy、NGINX、Pulse Secure、Snapt.io及另外许多软件ADC将尝试与硬件ADC保持距离，声称无论如何自己才是原始的服务网格。我们会再次听到软件将蚕食硬件，开源和白盒将主导专有供应商之类的声音。

ADC、API网关和服务网格都将进入大熔炉。

网络服务网格

思科、Red Hat及诸多网络公司在大力推动一项名为网络服务网格（NSM）的新开源计划。

NSM是提供L2 / L3网络构件的一种方法，反映了Kubernetes环境中的应用程序服务网格。NSM为应用程序向网络请求高级服务提供了一种方法，比如“安全互联网连接”或“通向AWS VPC＃1的安全连接”等服务，然后让网络将可以提供这种类型服务的适当的网络服务端点（驻留在pod上的网络功能软件）汇集起来。比如说，NSM可以先引导流量通过防火墙，然后通过IPSec设备，最后通过封装功能，以便将有效负载传输到远程网络。

是不是听起来有点耳熟？是的，这把NFV、服务功能链（SFC）和网络服务报头（NSH）都整合了进来，但服务于在Kubernetes上运行的容器工作负载。

协调AppDevs、DevOps、NetOps和SecOps

至于L3可达的扁平网络环境中是否需要NSM，这取决于你的观点。一些AppDevs和DevOps人员可能觉得没多少价值，不过需要在网络层出现魔法，才能支持应用程序的连接和安全。CIO们不会放弃分层安全或网络分段机制，将全部应用程序向所有互联网流量敞开，即便在有限的TCP/UDP端口上也不会这么做。NSM团队与应用程序服务网格支持者之间的互动将是未来几个月密切关注的一个方面。

由于Kubernetes、服务网络和容器网络发展势头很猛，DevOps、NetOps和SecOps这三驾马车将齐心协力，共同帮助提高AppDevs的工作效率。当我们大步迈向容器原生的大规模敏捷应用程序开发和部署时，这三驾马车势必要确保公司在安全、网络和应用程序开发等方面制定的策略得到遵守。

Istio是下下一代防火墙吗？

微分段和隔离这个概念是一种基本的网络安全最佳实践，很少有人会争论。微分段遏制潜在威胁，并减小其“破坏范围”，从而有助于降低风险。如果做法得当，微分段会使攻击者更难仅仅通过危及环境中的某个部分而长驱直入。

用于实现微分段的技术 工具 可以追溯到物理交换机上的VLAN，是软件定义网络（SDN）的一个基本特性。除了第7层协议感知外，所谓的“下一代防火墙”（NGFW）还常常格外注重隔离场景。然而，虽然大家认识到微片段的好处，实际采用和使用却明显滞后。

这方面的原因主要是由于复杂性和运维负担。很难手动配置与应用程序的实际拓扑结构紧密对应的SDN和VLAN架构。随着应用程序不断发展，长期维护这些方面就更难了。比如说，大多数企业提供某种基本的分段，比如面向互联网的流量、内部流量和存储流量使用单独的网络。然而，很少有企业对应用程序本身实行分段，为环境中的每个工作负载实现真正的“最小权限”分段。比如说，虽然大多数企业会通过非军事区（DMZ）将面向公众的应用程序的前端连接到互联网，但很少有企业会将此前端后面的流量分开来，比如为缓存流量、队列流量和存储流量分段划区。

对这个问题而言，云原生应用程序架构的兴起既是最大的挑战，又是潜在的救星。试想一下：一个典型的传统应用程序重构成微服务后，离散组件的数量实际上大大增加，而且那些组件的更新比过去频繁得多。如果企业处理几个虚拟机时就觉得微分段很棘手，同样这个应用程序在二十多个容器中运行且每天更新时，企业对于分段该应用程序又抱什么希望呢？幸好，能够支持以一种高度自动化的编排方式来运行这些应用程序的可编程基础架构，同样这个概念也能够支持以一种声明性编程方式来定义分段和隔离。

这个重大创新使一种名为服务网格的技术能够将网络拓扑和路由从基础架构层抽取出来，做入到应用程序本身。服务网格让开发人员可以使用一种基于声明性模型的方法，将微服务轻松地联系起来，该方法在底层基础架构中的物理、甚至传统SDN层之上。比如说，服务网络可以使开发人员能够构建连接到缓存“服务”的前端组件，无需硬编码连接到特定的IP地址、主机甚至云提供商。服务网格确保该服务始终可用，可以管理对服务的访问，对服务之间的流量默认加密，并启用高级负载均衡方案，比如金丝雀部署和A/B测试。服务网格的例子包括Istio和Linkerd。

虽然服务网格为一般的应用程序部署和管理提供了重要的功能，但也提供了使微分段成为现实的潜在解决方案。使用传统工具进行微分段的核心问题是，提供分段的工具与其组件被分段的应用程序之间相互脱节。如果用于进行微分段的规则不是很正确，就破坏应用程序；如果规则不是很精确很具体，分割带来的许多潜在优点荡然无存。此外，随着时间的推移，你要确保这些规则始终与应用程序完全同步。设想一下，大企业有成千上万个应用程序，不断出现的安全事件需要企业密切关注，不难理解为什么大多数企业采用非常粗略的分段方法。

服务网格解决这个问题的方法是，将分段定义移出基础架构，并将它与应用程序本身放在一起。基础架构不再需要手动配置从而与应用程序保持一致。相反，由于解决方案完全用软件开发而成，并完全由用于运行应用程序的编排器（比如Kubernetes）运行，所以开发人员可以直接将安全声明为应用程序部署的一部分。开发和测试环境中使用的同一个网格模型可以跟随应用程序进入到生产环境，具有完美的保真度。这样一来，隔离每个单独的微服务变得切实可行，又没有以前需要手动配置基础架构时阻止大规模使用的那种摩擦。

与NGFW一样，Istio等服务网络还可以确保符合协议（比如确保实体之间只允许HTTP流量），并对传输协议加密。但是与NGFW不同，配置与应用程序并不脱离，也不需要单独加以管理。相反，每次构建应用程序时，就可以针对生产环境中使用的相同网格策略来验证应用程序，并在任何代码库（比如GitHub）中进行版本控制。同样重要的是，由于服务网格纯粹是软件，所以同样这个配置完全可移植过去，哪怕在不同的云提供商和本地部署之间。

服务网格提供的不仅仅是微分段，还首次使微分段在大规模环境下切实可用。就像Kubernetes从硬件和操作系统中抽取出底层计算能力一样，服务网格也从底层网络中抽取出路由和连接。一旦路由和连接与基础架构分离，并且被视为代码，就可以实现真正针对应用程序定制的最小权限的微分段。

服务网格为中间件㪣响丧钟？

随着Istio及相关技术日渐流行，中间件可能在逐渐让位于服务网格。两者都可以监管各种应用程序和服务之间的联系，但在模式和操作方面大不相同。中间件在面向服务的架构中唱主角，它在当今以容器为中心的环境下会变得无关紧要吗？

中间件的工作方式是，将来自各种应用程序的消息传递到集中的通信池。然后，这些消息通过功能管道来传送，以用户注册库服务作为结束。消息在企业服务总线（ESB）上传输。通信融合起来，隐藏了分布式应用程序的多样性以及硬件和操作系统的异构性。

随着企业继续拥抱容器，传统中间件出现了几个明显的问题。DevOps实践鼓励依赖分布式系统的现代环境，并鼓励不可变实例的快速自动部署。容器的持续集成和交付（CI/CD）要求不断更新应用程序和工具。ESB并不总是很适合这个。

• 单一故障点：中间件在一个庞大的集中式日志（含有所有服务）中记录和监控服务日志层面的消息。它将某些功能（尤其是日志记录和性能监控）普遍运用于所有消息。消息排入队列，任何故障都可能导致管道出现流量拥堵。发现一个问题需要筛查可能数千个毫不相关的错误。中间件通过将服务日志转变成单一故障点来实现通信，而小问题可能破坏其他所有通信。

• 整体式：虽然SOA由松散耦合的可重用组件组成，但中间件的统一管道很难改动、适应新要求。中间件编排的功能与它们自身及周围的应用程序紧密集成。用户界面（UI）的微小变化甚至可能需要重新评估整个应用程序。中间件之所以很有效，是由于它提供了一种通用的通信方式，但这需要创建隔离网络的命令式编程。

容器和虚拟化大大增加了应用程序中部署的实例数量，这就加大了单一故障点内拥堵的风险，需要更动态的变化。Istio、Ambassador和Envoy等服务网络解决方案日益被视为替代方案。

相比之下，服务网格是在服务层之上并实现服务到服务通信的专用网络层。其通信渠道依赖分布式API，而不是依赖集中式分离式设备。

消息在服务网格内传输，但消息传递功能与接收消息的服务一起执行。每个实例都连接到代理，代理负责与服务网格之间传递消息。然后，这些代理执行历来由中间件执行的许多功能，比如消息路由及封阻、服务发现、负载均衡、加密、身份认证以及授权。它们还支持发现、故障处理、路由、断路和请求跟踪等功能。

服务网格允许消息直接从服务发送到服务，而不是通过中间管道。这使得应用程序的消息传递与其服务尽可能耦合在一起，而在大多数容器化应用程序的情况下两者是松散耦合。它们的分布式特性减轻了对单一故障点的依赖，便于动态变化。

服务网格在许多方面非常适合容器。它们与平台无关，可以集成到任何基于容器的架构中。它们消除了单一故障点，便于迅速从网络或服务故障中恢复过来。通过分发消息传递，它们便于容器的可扩展性和声明性编程。服务网格支持高度动荡的环境，而容器在其中似乎蓬勃发展。由于这些原因，Istio之类的工具日益用于将中间件大部分的决策和计算能力带入到Kubernetes和基于容器的系统。

随着服务网格不断得到采用，它们也在迅速完善。Istio 1.0最近已发布，表明服务网络变得更稳定更安全。Envoy早已归属云原生计算基金会（CNCF），Istio也有计划加入。服务网络解决方案正发展成为蓬勃发展的云原生态生态系统，并用于云原生应用程序。

但是，某些使用场合得益于中间件具有的稳定性和安全性。中间件已存在几十年，更多人知道如何运作中间件而不是运作服务网格。还有由来已久且成熟可靠的措施可确保中间件安全，并遵守HIPAA、PIPEDA和PCI DSS等法规。

服务网格正迅速变得更安全，但容器安全需要与虚拟机安全不同的思路。尤其是，它取决于将运营流程整合到开发阶段。在整个技术架构中加以实施时，这类DevOps实践可促进应用程序的安全性、敏捷性和长期创新。

如果企业希望淘汰部分中间件，改而使用服务网格，要重新评估组织流程和方法。虽然服务网格有助于支持许多容器之间的通信，但中间件是整体式应用程序之间传输信息的理想选择。它们是在不同的模式中构建的；要想改弦易辙，企业可能要摈弃构建并支持应用程序和基础结构的方式。

除非DevOps工具和实践框架落实到位，否则企业不能淘汰部分传统中间件。这将促进整个环境的基础架构即代码、服务、安全、监控和CI/CD管道之间的动态协作。

声明：本文来自云头条，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如需转载，请联系原作者获取授权。