AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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

  • 2019-12-09
  • 本文字数:3145 字

    阅读完需:约 10 分钟

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

有人把 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 万行提交,排名第一。


2019-12-09 13:004033

评论 3 条评论

发布
用户头像
愿景不错,基建的童鞋们加油。我们等着用。哈哈
2019-12-10 09:58
回复
用户头像
Service Mesh仍然任重道远
2019-12-09 14:16
回复
同意!
2020-01-06 20:12
回复
没有更多了
发现更多内容

AI 技术在图书馆业务中的应用

北京木奇移动技术有限公司

软件外包公司 AI技术应用 图书馆信息化

IPv6检测指标中的IPv6授权体系是什么意思?(国科云)

国科云

让通义灵码越用越懂你?使用记忆功能,打造你的专属编程搭档

阿里巴巴云原生

简单了解一下数据安全定义以及意义

行云管家

网络安全 数据安全 堡垒机

四维图新与阿里云达成战略合作,联合打造汽车行业一揽子解决方案

科技汇

2025校招/社招Java八股文面试题库,横扫大厂后端岗

Geek_Yin

Java 程序员 java面试 Java面试题

聚焦科学智能|第412期双清论坛“AI for Science:战略与行动”在京召开

ModelWhale

科学智能 AI4S

现代财务——智能技术背景下的企业变革

智达方通

全面预算管理 财务管理

Java集合必会14问(精选面试题整理)

Geek_Yin

Java 程序员 java面试 Java面试题

阿里云可观测 2025 年 5 月产品动态

阿里巴巴云原生

怎么才能知道你的Mac的系统性能呢?Geekbench 5性能测试

Rose

mac苹果设备电量信息实时显示AirBattery免费

Rose

基于生成式物理引擎的AI模型训练方法论

申公豹

人工智能

鸿蒙Next仓颉语言开发实战教程:订单列表

幽蓝计划

流批一体向量化引擎Flex

Apache Flink

大数据 flink 流批一体

梁汝波:字节跳动要以持续智能突破,坚定服务产业应用

新消费日报

ZAB 与 Paxos:分布式一致性算法的工程实践与深度对比

异常君

zookeeper 分布式 ZAB PAXOS Java.

动漫与游戏产业用到堡垒机的必要性你知道吗?

行云管家

网络安全 等保 堡垒机 游戏行业

HPE SPP 2025.05.00.00 - HPE 服务器固件、驱动程序和系统软件包

sysin

SPP

Ableton Live 12 Suite for mac v12.2中文:音乐制作软件

晨光熹微

让通义灵码越用越懂你?使用记忆功能,打造你的专属编程搭档

阿里云云效

通义灵码

中东AI迷雾里的中美棋局

脑极体

AI

CAD看图软件可以进行标注吗?

在路上

cad cad看图 CAD看图王

电线电缆行业MES系统:实现智能制造与全流程追溯

万界星空科技

制造业 mes 万界星空科技mes 电线电缆行业 电线电缆mes

超实用!手把手教你Dify版本升级

王磊

苹果访达Finder增强工具TotalFinder 中文版,让效率提升!

Rose

如何使用CAD看图软件放大图纸文字?

在路上

cad cad看图 CAD看图王

火热报名中丨暨2025第三届中国SRE大会,将于6月26日在上海召开

雅菲奥朗

AI 可观测性 2025SRE大会

【JeecgBoot AIGC】AI知识库实战应用与搭建

JEECG低代码

AI大模型 AI应用 AIGC JeecgBoot

感谢艾瑞白皮书“点名”,但网易的挖掘机器人真不是“打游戏送的”

网易伏羲

数字孪生 人机协作 网易伏羲 工程机械

这几道Java集合框架面试题在面试中几乎必问

Geek_Yin

Java 程序员 java面试 Java面试题

Service Mesh渐热:我们跟专家聊了聊这些疑问该怎么解决_架构_张晓楠_InfoQ精选文章