关键点
- 服务网格框架用于处理服务间的通信，并提供连接、管理和保护微服务的平台。
- 服务网格通过处理需要复杂编码的功能来帮助应用程序开发人员，例如路由决策，这些决策在网格层级完成，而不是在应用程序中完成。
- 它还提供了可以编入网格的安全策略。例如，您可以设置一个策略，以限制网格中某些服务的入站网络流量。
- 像Istio这样的服务网格可以在Kubernetes平台上无缝工作，但在其他平台上使用还比较麻烦。
- Sidecar代理使得应用程序与管理服务通信的操作方面有效和可靠。
服务网格是一个专用的基础设施层，用于处理服务间通信，并提供连接、管理和保护微服务的平台。
服务网格使得微服务之间的通信变得灵活可靠。它提供了分布式服务所需的关键功能环境，如弹性、服务发现、负载均衡、加密、授权、容错（通过服务重试和断路器）。
InfoQ与服务网格领域的主题专家进行了交谈，以更多地了解为什么服务网格框架已成为云本机体系结构的关键组件。
本文下面的部分提供了与我们交谈的小组成员的详细信息，虚拟小组中包含的问题以及小组成员的答复。
讨论嘉宾：
- Matt Klein，Lyft
- Dan Berg，IBM
- Priyanka Sharma，Lightstep
- Lachlan Evenson，微软
- Varun Talwar，Google
- Oliver Gould，Buoyant
InfoQ：您能否定义Service Mesh以及它在微服务交互和治理方面带来了哪些的优势？
Matt Klein：微服务从业者面临的两个最困难的问题是网络和可观察性。即服务彼此如何可靠地通信？当出现问题时，如何快速确定问题，修复和解决问题？可靠的微服务网络和可观察性需要多种技术，包括服务发现、负载均衡、超时、重试、断路器、运行状况检查、高级路由、统计、日志记录、分布式跟踪等。从历史上看，大多数现代架构都构建了功能丰富的库，这些库可以直接拿来使用。但是如果需要做多语言适配的话，就需要用多种语言重新实现和维护大量复杂的功能。
“服务网格”背后的想法是使用与每个应用程序并行运行的进程外的“sidecar”代理。该代理可以以非常高的性能实现了微服务架构的所有复杂网络和可观察性需求。由于代理在专用进程中实现了所需的功能，因此它可以与任何应用程序语言一起使用。当每个应用程序都有一个关联的sidecar代理并通过它来路由所有流量时，应用程序本身不再需要知道底层网络细节并可将其视为抽象。这允许应用程序开发人员只要关注业务逻辑，而不需要考虑组织内可能使用的什么语言。
Dan Berg：服务网格是一个术语，用于描述组成应用程序的微服务网络以及对它们之间交互的管理。其中一个例子是Istio，这是一种开放技术，为开发人员提供了一种无缝连接、管理和保护不同微服务网络的方法——无论平台、来源和供应商。通过将复杂且容易出错的逻辑从应用程序代码中移动到服务网格，这可帮助开发人员提高工作效率。例如，服务网格管理流量路由，确保服务之间的安全通信，捕获网络遥测以及网格内所有服务的安全策略实施等。通过内置的断路支持，服务网格可确保更高的服务弹性，从而在服务无法到达目的地时以优雅的方式处理故障。
Priyanka Sharma：服务网格是服务间通信的基础架构层。它确保您的消息在整个系统中的可靠传递，并与服务的业务逻辑分开。服务网格通常被称为sidecar或代理。
随着软件开发进入微服务时代，服务网格将变得非常重要。通过服务网格，您不仅可以确保弹性网络通信，还可以在不改变应用程序运行时的情况下实现可观察性和控制。
通过服务网格，组织可以更轻松地在工程团队中使用具有一致工具的微服务。开发人员也可以专注于他们的服务，并让网格负责网络层通信以及围绕微服务的工具。
Lachlan Evenson：服务网格是一组应用程序，可以在微服务体系结构中实现统一的服务间通信。服务网格使微服务开发人员和运维人员都能够以规定和预期的方式与依赖服务交互。这通过为所有通信提供单一接口和单点策略执行而不是定制或样板实现来辅助治理。
Varun Talwar：服务网格是一种架构模式，微服务所需的所有服务通信和通用功能均由平台层（外部代码）统一处理。当像这样的平台层可以统一实现像路由和负载均衡这样的常见网络功能时，弹性功能（如重试和超时）、安全功能（如身份验证、授权和服务级别监视和跟踪）可以显著简化微服务开发人员的工作，智能组成的基础架构可以使组织能够在更高的服务抽象层面进行管理（独立于底层网络和基础设施）。
Yuri Shkuro：“服务网格”一词相当误导人。在直接解释中，它可以用来描述组成分布式应用程序的微服务网络以及它们之间的交互。然而，最近这个术语主要应用于处理服务间通信的专用基础设施层，通常实现方式是与应用程序代码一起部署的轻量级网络代理（sidecar）。应用程序代码可以将架构中的任何其他服务视为在同一主机上的本地端口上运行的单个逻辑组件。它使得应用程序代码不必了解现代云原生应用程序的复杂拓扑结构。它还使基础设施团队能够专注于在单个sidecar组件中实现诸如路由、服务发现、断路、重试、安全性、监控等高级功能，而不是通过现代应用中典型的多种编程语言和框架来支持。
Oliver Gould：服务网格是一个专用基础设施层，用于在微服务之间进行安全、快速和可靠的运行时通信。在Twitter里我们了解到，这种通信是应用程序运行时行为的关键决定因素，但如果您没有明确地处理它，最终会形成一个脆弱、复杂的系统。服务网格为运维人员提供了调试和管理此通信所需的控制机制。如果你想深入挖掘，就深入了解一个服务网格是什么以及为什么需要它，你可以在这里找到。
InfoQ：企业服务总线（ESB）模式在过去几年一直流行，特别是在面向服务架构（SOA）模型中。对于ESB和服务网格模式各位怎么看？
Klein：我不打算讨论SoA与微服务，或者ESB与服务网格之间的差异。坦率地说，我认为这几乎没有真正的区别，名称的变化主要是由于厂商试图区分新产品导致的。一般而言，计算和工程是由迭代变化驱动的。近年来，大多数SoA/微服务通信已经转移到REST和更新的强类型IDL，如Thrift和gRPC。开发人员通过直接来自进程库和集中式消息总线的网络调用来支持简单性。不幸的是，大多数正在使用的进程库不足以解决运行微服务架构时出现的操作难题（Finagle和Hystrix/Ribbon是例外，但需要使用JVM）。我认为“服务网格”实际上只是ESB体系结构中的一个现代应用，适应了微服务从业者所喜欢的技术和流程。
Berg：从较高层次上看，ESB和服务网格很类似，因为它们都是管理一组服务之间的通信；但是，它们之间有根本的区别。一个关键的区别是消息被发送到ESB后ESB再确定向哪个端点发送消息。ESB是进行路由决策、执行消息转换以及管理服务之间安全性的集中点。另一方面，服务网格是一种分散式方法，客户端代理通过服务网格控制平面进行编程，以管理路由、安全性和metric收集。因此，服务网格将关键责任推送给应用程序，而不是将功能封装在集中式系统（如ESB）中。这使得服务在高度分布式的系统中更具弹性和扩展性，例如云原生应用程序。
由于将客户端方法与服务网格一起使用，因此可以有比ESB可实现的更复杂的路由规则、策略实施和断路器等弹性功能。另一个关键区别是应用程序逻辑不知道自己加入到了服务网格。网格主动调整以采用应用程序。使用ESB时，必须调整应用程序逻辑才能参与ESB。
Priyanka：ESB和服务网格有很多共同之处，特别是它们为什么被构建。ESB在SOA时代开始流行起来——它们管理网络通信，并负责管理一些业务逻辑。构建ESB的原因与我们今天构建服务网格的原因相同——随着服务数量的增加，整个系统需要一致性和可靠性，并且消息总线/辅助代理是实现这一目标的好方法。
服务网格与ESB不同，因为它们专为云原生的微服务架构而构建。在云计算领域，ESB功能不佳。它们承担了服务中过多的业务逻辑，并通过创建另一个依赖和组织孤岛来减缓了软件开发的速度。
总而言之，我认为服务网格是ESB技术的下一代发展。核心动力是相同的，但是实现更加复杂并且是为云原生时代量身定做。
Evenson：就像ESB是SOA的代名词一样，服务网格与微服务也是如此。主要区别在于ESB和服务网格实现的服务的范围和大小。ESB在功能集和后端系统支持方面要大得多。ESB通常关注大型企业和行业标准、协议等，而服务网格足够轻量级以便为微服务增加价值。
Talwar：ESB是关于集中式架构的，其中一个核心部分承载了作出决策的能力。随着时间的推移，中心部分变得复杂，并且缺乏微服务架构的能力，每个团队/服务都想要快速配置、测试、部署和扩展其服务。服务网格的新架构代表了SOA模式从笨拙端点、智能管道（大型单体分层应用程序）到智能端点（服务特定功能）、笨拙管道的转化。
Shkuro：ESB和服务网格之间的关系类似于基于单体和基于微服务的应用程序之间的关系。它们都起到类似的作用，主要区别在于它们如何做到这一点。ESB是位于架构中所有其他服务之间的单个系统。它为服务之间的每个消息交换提供单一控制点。它还引入了单点故障并增加了所有通信的延迟。相反，通过sidecar实施的服务网格执行相同的功能，但是以分布式、分散的方式。服务网格的控制平面提供了与ESB相同的策略和路由决策的集中权限，但不处于每个请求的关键路径上。数据平面由与应用程序代码一起运行的sidecar实现。例如，在一个典型的Kubernetes设置中，每个微服务实例运行在它自己的服务网格sdiecar副本旁边的一个容器中。所有进出微服务的流量都会通过sidecar的实例，而不会对其他集中式子系统造成严重依赖。
Gould：目标并非完全不同，但是优先级和实施细节极为不同。ESB倾向于实现为一个集中的单点故障，而像Conduit这样的服务网格使用“sidecar”代理来明确分散和可扩展。
此外，可以仅在应用程序的一小部分中使用它，这意味着服务网格的采用可以是增量式的，不需要全面的架构锁定。最后，服务网格重点关注通信的操作方面，并尽量避免实际感知应用程序的业务逻辑细节。服务网格的目标是可操作的，而不是架构或整合。
InfoQ：企业中谁应该关心服务网格？这是典型的开发人员在部署应用程序时应该注意的事情吗？
Klein：服务网格背后的想法主要是将网络抽象为应用程序开发人员。应用程序开发人员仍然需要了解一般网络概念，例如重试、超时、路由等（因为他们将参与配置），但是他们不需要知道它们是如何实现的。因此，典型的开发人员应该关心服务网格，因为这意味着他们可以删除大量的一次性的网络设置和关于可观察性的代码，并获得统一的、功能更丰富、更可靠的免费解决方案！
Berg：使用服务网格和强大的云平台，小型公司也可以创建那些以前只有大型公司投入大量资源，在传统模式下使用定制代码并重新配置每台服务器才能创建的应用程序。云、服务网格和微服务使开发人员能够灵活地使用不同的语言和技术工作，从而提高速度和生产率。
一个典型的开发人员应该意识到他们正在参与一个服务网格并了解他们正在与网格中的其他服务进行通信。他们应该接受这样一个事实，即服务网格可以帮助他们避免需要复杂编码的功能，例如路由决策，因为这些功能是在网格级而不是应用程序本身完成的。服务网格最终可以提高开发人员的工作效率。遥测信息和故障注入是一种强大的开发工具，可用于检测问题并最终将其从应用程序中删除。
Priyanka：基础架构和平台团队通常是在软件组织中设计和实现服务网格的人。对于这些团队及其工程领导者来说，为公司的最佳战略和实施共同努力至关重要。
虽然服务网格通过将网络通信与服务分离开来以提高开发人员的生产率，但他们应该了解服务网格所提供的特定服务发现和可观察性功能。这将帮助开发人员知道什么会自动工作以及需要自定义哪些功能。例如，如果服务网格使用OpenTracing进行检测，则开发人员可以保证整个系统具有最高的可观察性。然后他们可以选择使用OpenTracing来测试他们的服务，以获得更多详细的错误或性能降级追踪。
Evenson：服务网格对开发人员来说应该是透明的，它提供的服务被视为平台的一个特性。然而，运维人员也会对服务网格感兴趣，因为这堆东西也需要他们来维护。
Talwar：服务网格的一个有趣方面（限制）是它将诸如开发人员、运维人员、生产安全、网络运维、CIO、CTO等众多不同的利益相关者聚集在一起。对于开发人员来说，服务网格是由另一个组织完成的，开发人员无需为许多常用功能（理想情况下只需要编写业务逻辑）编写代码，并且可以部署到结构中（使用网格）来在运行时处理功能（通过策略）。
Shkuro：服务网格解决方案通常由基础设施/网络团队负责。典型的应用程序开发人员不需要了解多少。他们可能需要知道为了向服务X发出请求，他们需要将它发送到为该服务保留的本地端口Y，或者将所有请求发送到同一个端口，但是需要通过HTTP头或特定的API来指示目标服务RPC框架。当然，在许多组织中，同一个开发人员也是他们服务的随叫随到人员，这意味着在出现问题时，了解如何监控sidecar进程也很有用。在Uber，我们有一个工具，可以自动为每个服务提供一个仪表板，显示来自服务所使用的许多基础架构组件的metric，包括sidecar进程生成的度量，例如请求和错误计数，请求延迟直方图等。
Gould：企业应该关心它，因为它为运行时操作带来了一层标准化，类似于Docker和Kubernetes提供的运行时操作的标准化。平台运维人员（将Docker和Kubernetes引入组织的人员）会支持服务网格，因为这使他们摆脱了调试和运行微服务的关键路径。
开发人员（以及更一般的服务所有者）也会受益，因为服务网格可以将应用程序代码与运行时所属的操作逻辑分离。网格提供了可操作的功能，可以让开发人员更快的开发，而不用担心造成破坏。
InfoQ：服务网格解决方案如何在服务重试、超时、断路器、故障转移等方面支持弹性？
Klein：Sidecar代理代替应用程序实现大量高级功能，如服务发现、负载均衡、重试、超时、断路器、区域感知路由等。这些功能非常难以正确使用，而微服务代码库通常散布着错误或不完整的版本。将这种类型的功能剥离到高性能一次实现到处是用的单个实体，效率会大大提高。
Berg：与网络紧密耦合的应用功能（如断路器和超时）与服务代码/业务逻辑明确分开，并且服务网格的这些功能便于在云中开箱即用。大规模分布式系统具有一个明确的特征：小型局部故障有很多机会变成全系统灾难性故障。服务网格旨在通过使用云工具（如容器）的敏捷性和可移植性来防止这些故障升级，以在底层系统接近其极限时快速卸载负载并快速失败。
这一切都是在应用程序中可用的客户端代理（sidecar）中完成的。该sidecar负责将请求转发到另一个sidecar代理在转发到该应用之前接收该请求的服务。当发出请求时，代理将自动断开断路器，并且当上游服务不可达时，可能会将流量重新路由到另一个版本。服务之间的超时设置可能会失败。像Istio这样的服务网格可以帮助您避免不良用户体验和超时中断，因为Istio允许您将故障直接注入网格，从而使您无需猜测就可以测试和验证连接超时。
Evenson：服务网格数据平面组件位于所有微服务的所有数据通信的路径中。考虑到这种布局，他们意识到数据网格，因此可以制定支持弹性功能的策略驱动决策。
Talwar：服务网格有两个部分。数据平面和控制平面。像Envoy（用于Istio）的可插入API驱动数据平面允许配置重试和超时，以便轻松配置和更改这些数据平面。Envoy还可以定义断路器的配置以及池中所有实例的粗粒度和细粒度运行状况检查，以实现负载均衡和从故障/高延迟实例进行路由。有关更多详细信息，请参见此处。
Shkuro：这些功能中的很多功能在服务网格的特定实现之间会有所不同。技术本身并不新鲜，但许多技术仍然是研究和创新的活跃领域。服务网格的特殊之处在于它们从应用程序代码中抽象出这些问题并封装到单个基础架构层中。这样做可以保持应用程序代码的轻量级，并允许服务网格开发人员快速迭代并针对这些问题开发最佳的解决方案。例如，采取故障转移的问题。当特定可用区域中的某项服务遇到问题时，通常最安全的恢复方法是将流量转移到另一个可用区域，前提是它具有足够的过剩容量。通过改变控制平面中的一些设置，服务网格可以完全透明地完成架构中其余的服务。要在每项服务中都支持这种故障转移功能将会困难得多。
Gould：服务网格提供的最重要的可靠性特性是第7层负载均衡。与L3/L4负载均衡器不同，像Conduit这样的服务网格知道每个请求的元数据，并且可以帮助自动寻找缓慢或失败的实例、机架故障等。
一旦这些负载均衡器知道服务级别目标（通常以延迟和成功率的方式），它们可以令人难以置信的做出何时不应将流量发送给特定实例的明智决定。
如果这是一件安全的事情，服务网格还可以自动重试应用程序的请求。但是，请注意，重试实际上可能使中断更加严重；您可能会遇到长时间运行的重试循环，这些重复循环会占用资源并可能导致系统级联故障。所以正确地参数化是很重要的，例如像我们在Linkerd所做的那样，采用基于预算的方法来重试。这极大地改善了最坏情况的行为。
InfoQ：服务网格如何支持身份验证和授权等安全功能？它如何帮助实施运行时安全策略？
Klein：尽管大多数安全团队都会说他们希望在服务之间进行身份验证和授权，但很少有组织最终会大规模部署解决方案。这是因为系统范围的认证和授权是非常困难的问题！服务网格在这方面有很大帮助。使用mTLS和SPIFFE等技术可以相对容易地部署认证。应用程序/安全开发人员需要指定策略，但不必担心底层加密和身份验证是如何实现的。同样，sidecar代理可以使用来自mTLS会话的认证数据在L7路由级别进行驱动授权。例如，指定/service_a只能由服务A访问，而/service_b只能由服务B访问。
Berg：这起源于一些关键因素。服务网格具有管理网格内证书颁发机构的组件。此身份验证组件负责对客户端代理进行编程，以使用相互TLS（传输层安全性）自动在网格中的服务之间建立信任关系。如果开发得当，这些证书的寿命会很短，这样如果服务受到损害，在证书被循环使用之前，只有一小部分安全漏洞窗口，从而导致原始的无用功能。
服务网格具有可编程的安全策略。例如，您可以设置一个策略，以限制网格中某些服务的入站流量。如果您只想允许入站Internet通信服务A，则由于客户端代理拦截所有到应用程序的入站和出站通信，所有其他入站Internet通信都将被拒绝（如果它偏离A以外的服务）。服务网格强化了服务之间的强标识声明，并限制了可以访问服务的实体，所有这些都是在不更改应用程序代码的情况下完成的。
Priyanka：服务网格在部署时创建了更多的灵活性和控制权，因为对应用程序代码的依赖很少。我觉得我们这些服务网格提供者最好谈论具体实现以实现弹性和身份验证。
Evenson：服务网格控制平面只能提供在服务网格运行的平台上固有支持的功能。在Kubernetes上运行服务网格的情况下，认证和授权在服务网格中表示并转换为强制执行的底层Kubernetes资源。
Talwar：一旦服务网格拦截了所有的服务间通信，它们就可以加密并强制认证所有通信，而无需开发人员参与（巨大优势），并为谁可以调用谁启用授权策略。由于所有流量都流经服务网格的数据平面，因此可以通过服务网格来确保所有受支持/隧道协议的加密以及允许/禁止每个服务的出口/入口。
Shkuro：Sidecar方法的一个巨大好处是它的身份可以与实际的微服务的身份互换使用，因为可以设置容器上的网络策略，使得微服务除了通过sidecar进程无法通过其他方式访问。这允许将许多安全问题转移到sidecar上，并在整个组织中对其进行标准化。认证可以由sidecar专门完成，例如，通过在sidecar上终止所有的TLS并且在应用和sidecar之间使用未加密的通信。如果需要执行额外的高级授权，则可以通过可信请求标头将调用者身份传递给应用程序代码。一些简单的授权形式，例如“只允许服务X访问我的端点Y”，也可以完全转移到sidecar过程中，并通过集中策略进行控制。这些策略甚至可以在运行时更新，而不会影响应用程序代码。
Gould：一旦使用了编排工具例如Kubernetes，传统的网络分割方法认同就开始崩溃。通过服务网格，服务可以通过一致、安全的方式在数据中心中重新建立一致的身份，此外，还可以基于强大的加密基元而不是部署拓扑来实现。例如，Conduit可以提供证书颁发机构和/或与证书颁发机构集成，以自动分配服务的TLS证书，以便当两个支持服务网格的服务进行通信时，它们具有强大的对等密码证明。一旦这些身份原语被建立起来，我们就可以用它们来构建访问控制策略。
InfoQ：当前人们学习和部署服务网格的熟悉阶段如何？学习曲线陡峭吗？陡峭的部分在哪里？
Klein：说实话，为时尚早。在大型微服务架构中成功部署服务网格是可能的，但仍需要相当多的网络和系统知识。正如我多次提到的，服务网格部署由“数据平面”和“控制平面”组成。数据平面触及每个数据包并执行负载均衡、重试、超时等。控制平面通过为服务发现、路由表等提供配置来协调所有数据平面。像Envoy、HAProxy和NGINX这样的数据平面是健壮的，完全可用于生产。但是，为组织开发和部署控制平面和相关配置实际上是最困难的部分。
Envoy是一个可用于大量多种部署类型的通用工具。这意味着Envoy拥有令人眼花缭乱的选项，对于不熟悉的人可能会非常恐惧。不幸的是，适应性往往与易用性相左。另一方面，更紧密地与组织的开发实践和工具绑定的控制平面可能会有更少的选项，选项越多对于大多数开发人员来说更容易理解和使用。因此，随着时间的推移，我认为随着微服务架构在Kubernetes等工具上的标准化，服务网格将通过控制平面项目（如Envoy之上构建的Istio）变得更“开箱即用”。
Berg：与采用云策略类似，服务网格具有丰富的功能和特性，但如果您一开始就尝试使用其所有功能，您可能会觉得它难以琢磨。在使用Srevice Mesh的初期建议您只采用部分功能。例如，如果您想要查看微服务的复杂性，请仅为使用服务网格中的遥测，而不是安全或路由。随着需求的增长，从简单采用到逐步接纳服务网格。
Priyanka：根据我们从OpenTracing最终用户社区获悉的信息，服务网格是一项受人欢迎的技术，它可以使微服务更加健壮。目前，人们需要花时间了解所有的选项，如果有更多的教育材料（如本文）就更好了。
Evenson：这实际上取决于服务网格。服务网格的功能之一是，您不必更改应用程序以支持服务网格。有些阻力是应用程序开发人员不知道如何修改基础结构定义以部署服务网格的数据平面组件，以便它可以在所有数据通信的路径中。
Talwar：今天，像Istio这样的服务网格可以在Kubernetes等平台上无缝工作，但在其他平台中使用它还存在困难。另一个关键点是让用户逐步尝试Istio的各个部分，就像安全、监控或弹性一样，而不需要增加了解Istio其他部分的认知负荷。我认为如果在这两个领域投入更多工作将使Istio更易于消化和被更广泛的使用。另一个问题是需要经过良好测试，和多性能的优化已经支持生产，这是Istio项目目前正在进行的工作。
Shkuro：在Kubernetes中部署Istio服务网格相当简单，但对于许多不使用Kubernetes的组织来说，这有一点学习曲线。首先，组织中使用的部署系统需要支持将多个容器作为服务实例的逻辑单元（Kubernetes中的pod的概念）运行。另外，服务网格进程可以作为主机上的单个代理运行，这虽然可以解决路由和服务发现等问题，但却使安全性和身份验证等其他功能无法实现。从我与其他公司进行的一些非正式对话中，为服务网格运行控制平面可能是最难的部分。控制平面需要与系统架构中的其余部分深度集成，例如，它需要了解服务部署以便控制服务发现，运行状况检查、负载均衡/故障转移。 Istio项目在抽象控制平面功能方面取得重大进展。
Gould：我们一直在支持Linkerd生产近两年。我们已经学到了很多陡峭学习曲线的知识，包括我们期望学习的一些东西，但是往往这些东西在回顾过程中显而易见。一个令人惊讶的教训是，虽然Linkerd在极高的规模上表现出色，但事实证明，许多用户会从最强功能的简化方法中受益匪浅。应该让用户很容易就开始使用服务网格。我们希望降低管理分布式服务的复杂性，而不是增加它。这种见解导致了我们最近在Conduit上的工作，如果https://conduit.io/getting-started/不能满足您需要启动和运行的所有功能，我想知道为什么。
更一般地说，我认为采用服务网格的缺陷是一次尝试做太多事情。服务网格的采用需要在其关键性和解决的问题范围内增加。这是一种新的工具，我们见过的最成功的采用方式是渐进式的。我们的建议是尽可能保持简单（但并不简单）。
InfoQ：各位否谈论下Sidecar设计模式以及使用Sidecar可以实现哪些平台级别的功能？
Klein：正如我上面所讨论的，sidecar代理是抽象应用程序网络的关键。我们认为localhost网络是可靠的。根据这个假设，应用程序只需要知道它的sidecar代理，并且代理可以处理其他任何事情（除了上下文传播）。
Berg：Sidecar是客户端代理，与每个应用程序（即容器）一起部署。与sidecar配合使用的服务会自动启用带网格的服务。它在概念上与父应用程序相连，并通过提供平台功能补充应用程序。因此，sidecar提供了关键的网络控制点。有了这种设计模式，您的微服务可以将sidecar作为同一个微服务容器内的一组进程使用，也可以作为自身容器中的sidecar，以利用路由、负载均衡、弹性（如断路和重试）深度监控和访问控制。
Priyanka：Sidecar模式基本上是插件或驱动程序模式，但是相对于平台。通过从网络、度量、日志记录和其他具有标准接口的子组件中抽象出实现细节，运维人员可以更好地控制和灵活地制定其部署。
Evenson：Sidecar设计允许您操作Linux运行时环境，而无需更改应用程序代码。通常，将服务网格数据平面组件部署为sidecar，并修改Linux内核上该网络namespace的路由，以通过数据平面组件路由所有入口/出口。
Talwar：Sidecar模式是一种模式，其中协处理/容器镜像位于应用程序旁边，可以作为可信任的搭档，可以独立更新并由单独的团队管理，但与应用程序共享生命周期。平台可以承担的平台功能包括日志记录、报告、身份验证、配额策略检查等。
Shkuro：行业内没有关于什么是Sidecar模式的严格定义。例如，谷歌的Brendan Burns认为我们在这里讨论的服务网格sidecar是Ambassador模式的一个例子，因为它只关心应用程序如何与其他地方进行通信，而Microsoft Azure文档使用更慷慨的定义包括许多外围任务，包括平台抽象、代理通信、配置、日志记录等。我个人更喜欢后一种定义，其中Ambassador模式是Sidecar模式的子类。
本质上，Sidecar模式建议从业务应用程序中提取常用功能，并将其封装到在sidecar容器中运行的另一个进程中。这是一个众所周知的分解原理。通过将常见的部分抽取到可重用的容器中，使应用程序免于重新实现这些功能，可能使用多种编程语言。这与将传统的单体应用程序分成单独的微服务类似，除了sidecar的生命周期与父服务的生命周期相同之外，我们主要将它们用于与基础设施相关的功能。
Gould：从根本上说，sidecar只是另一个容器。这没什么神奇的。使用sidecar代理，我们能够尽可能靠近应用程序来管理操作逻辑，而不需要在应用程序代码中管理。服务网格的全部要点是将您的应用程序与管理服务通信的操作方面有效和可靠地分离。使用sidecar模式，我们可以为应用程序提供和验证身份等功能，因为sidecar必须具有与其代理的服务相同的特权级别。这是sidecar与在每台主机部署之间最大的不同。
关于小组成员
原文于2018年4月15日发表于InfoQ，原文链接：Virtual Panel: Microservices Communication and Governance Using Service Mesh