有人把 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 万行提交，排名第一。
评论 (2 条评论)