有人把2018年称为 Service Mesh之年，在2018年至今的两年时间内，Service Mesh从概念期进入到应用期，国内部分企业甚至已经进入 Service Mesh大规模落地的深水区。但是伴随而来的，是对Service Mesh的诸多疑问：非Kubernetes环境是否可以进行Service Mesh研发？Service Mesh改造或自研面临的风险有哪些？Service Mesh维护复杂、成本高昂的问题如何解决？近期InfoQ记者采访了Tetrate.io CEO Varun Talwar，Founding Engineer吴晟，以及Head of Products Sridhar Krishnamurthy，就以上问题给出答案。

InfoQ：Kubernetes在应用生命周期管理方面很成熟，那么，Service Mesh补足了哪些Kubernetes不太成熟的地方？

A：Service Mesh更多的关注服务间通讯的管理。Kubernetes解决了服务注册和发现的问题，但是在通讯层面、安全、监控，以及由此为数据基础的审计、扩容等能力等方面，这些都是Service Mesh带来的新特性。同时更为重要的是，Service Mesh还提供另外两种核心能力：

提供了智能网关，替代F5成为主入口的能力。并由于Service Mesh对Envoy在网关和Sidecar具有相同的管理能力，可以更为平滑的完成传统Proxy负载均衡到Service Mesh的过渡。
在从VM到Kubernetes迁移过程中，Service Mesh提供了桥接两端的能力。即使针对陈旧的系统架构，无需微服务化技术改造，依然能获得相应的能力，并为向Kubernetes的迁移扫清障碍和提供保障。

InfoQ：国内大部分技术专家认为 Service Mesh 最关键的部分是将服务通信管理能力从业务应用剥离下沉到基础设施，您认为Service Mesh的关键部分是什么？

A：是的。事实上，把诸如超时、重试、熔断在内的网络通讯相关的特性，从应用部署环境中独立出来，可以有效的提升应用的部署能力。如果上述的这些通讯相关特性被硬编码在业务代码中，即使是通过SDK库的模式，都不利于应用的快速部署。

更重要的是，这些SDK库需要针对目标应用进行反复的测试，以保证库的问题。同时，SDK的多语言带来的开发和维护工作量都是巨大的，还需要忍受版本长期无法升级的问题。Service Mesh移除了上述的这些短板，通讯管理完全独立于应用之外。使应用开发更关注应用业务本身，将网络层技术透明化和平台化。

InfoQ：当企业决定部署Service Mesh时，对内部不同角色的技术人员（基础研发、业务研发等）会有哪些不同的影响？哪类开发人员需要重点关注呢？

A：Service Mesh会帮助开发团队提升部署能力，更利于项目更高频率的升级。在生产环境上，无论是DevOps形式的团队，还是传统的运维团队，都可以借助Service Mesh的能力，在VM和Kubernetes环境间进行流量切换，或者实施蓝绿发布、金丝雀发布策略等等。平台团队可以更加关注网络性能、路由策略和网络，而无需关心业务代码的语言、类库版本和技术选型等问题。使平台团队和业务开发团队更加专注在自己擅长的领域，从而加速团队的整体能力。

InfoQ：对于治理系统重度依托微服务框架的用户，应用 Service Mesh 要做出较大改动，至少需要将服务发现、路由等功能迁移到 Sidecar 中，对这类用户有没有比较好的建议？

A：从微服务框架切换到Service Mesh的技术难度不大，只需要不再依赖原有框架中的服务发现、路由等功能，而Service Mesh的这些特性是透明、对应用无感知的。但是，这些用户真正需要改变的更多是在组织架构层面，而非纯粹技术角度。Service Mesh给应用开发团队提供了更为灵活的服务管理工具，公司必须调整自己的运作模式来使得Service Mesh的效能最大化。

Service Mesh更倾向于让应用团队能够在统一的平台之下，还能够对各自部署的应用进行管理，包括流量控制、安全、可观察性、容灾、动态发布等。同时保证不同团队间的隔离性。而至于迁移问题，在Service Mesh上，这些都是简单的配置即可完成，只需要停掉应用侧框架的服务发现，通过服务名称直接调用目标应用，即可快速迁移到Service Mesh的环境上。

InfoQ：对于服务化和容器化均不完善的企业，是否可以进行Service Mesh研发？难点在哪里？是否有好的解决办法？

A：Service Mesh特别是istio，可以在VM或者只是普通基于容器的非Kubernetes环境中使用，不过在这种使用方式实现和部署起来并不是那么容易。主要的挑战在于，这些环境中没有Kubernetes提供的服务注册，服务发现，Envoy设置、启动和声明周期管理能力以及跨网络（VPC、Cloud Region等）的mesh设置能力。

这也是Tetrate在提供商业级Service Mesh时特别重视的点，我们提供了基于Kubernetes，VM环境以及两者混合环境的Service Mesh一致性解决方案。

InfoQ：Service Mesh 模式在业务每次远程调用增加 1 跳至 2 跳时，会带来性能损耗，一条实际的调用链路可能包含多次远程调用，性能损耗会被明显放大，有好的解决方案吗？

A：目前公开的Service Mesh中Envoy造成的额外访问延时大概是3毫秒。在这个背景下，应用获得包括安全控制、流量管理和可观察性在内的能力。除非应用对于延迟是极其敏感的，否则这些用户可以在使用前对系统工作在Service Mesh上的效果进行评估。但是对于多数应用来说，这个延迟不会是真正的问题。

很多公开资料包括SkyWalking的实际使用案例看来，绝大多数应用无论集群节点并发流量多大，在单节点点对点模式下，普遍单点很少超过1000TPS/QPS，延迟也在50-100毫秒，甚至更高。在此背景下，3毫秒的延迟不会给系统带来真正的问题。同时，对于分布式调用深度的问题，超过5层的串行深度应用系统，一般已经无法很好的提供优良的响应和SLA，也更不会因为Envoy的额外性能开销，有更明显的降低。多数的深层调用，都是通过低延迟MQ或者批量任务异步化处理的，在这个过程中，几十毫秒（即使包含10层的分布式调用）也不会产生性能问题。

在实际的Service Mesh实践中，Envoy对访问的延迟能够保证稳定，即在高流量下也依然保持在3毫秒左右的延迟，这个是对生产环境最根本的保障。

InfoQ：企业使用Service Mesh 往往需要二度改造或自研，这时会面临哪些风险问题？

A：在北美，包括大型云厂商内部，都有过大量的私有Service Mesh先例，这是一个非常常见的想法。但随着Service Mesh的建立，复杂度不断提供，即使这些厂商有着全球顶尖的技术人才，他们依然觉得维护私有的内部Service Mesh版本工作量巨大、成本高昂。所以，他们在大量转向开源的Service Mesh解决方案，特别是Envoy和Istio。

这两个项目的社区发展都特别迅速，云厂商投入了很大的精力和人力在这两个项目上。单单集成这两个复杂的项目，往往已经是成本巨大的。如果是在内部方案中，甚至往往还不能很好的隔离控制面和数据面的功能，使得项目变得十分的臃肿和难以维护。目前，全球几乎所有主流厂商，都在Istio和Envoy两个社区中进行广泛合作，以开源为核心构建Service Mesh，而非重复造轮子。

这也是Tetrate在这个方向上提供企业级Service Mesh的原因，帮助用户减少这方面的投入，提供高度产品化的解决方案。

针对其他的RPC机制，Envoy和其他所有开源社区一样，需要有更多的人来参与。比如Dubbo协议已经得到初步支持，但性能还需要进一步评估；比如MySQL，PostgreSQL，Redis等等，也需要更多厂商的参与。

随着Service Mesh的更大范围生产应用，会被逐步补齐，我们在SkyWalking的插件贡献中，也能明显的发现顶级社区的强大吸引力和共建能力。

关于Tetrate.io

Tetrate.io是北美Service Mesh服务商，由来自Google，Twitter，IBM，VMWare，华为等公司的技术专家创建，其中包括Istio、Envoy和SkyWalking的创始团队和核心维护者。Tetrate.io今年在Envoy的贡献位于全球第二，第一是Google；Istio的贡献位居第三，第一和第二分别是Google和IBM；在SkyWalking中有近4万行提交，排名第一。

创作场景

Service Mesh 渐热：我们跟专家聊了聊这些疑问该怎么解决