【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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:003541

评论 3 条评论

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

如何开发一个市值管理机器人?

加密先生

机器人开发

YOLOv5全面解析教程⑤:计算mAP用到的Numpy函数详解

OneFlow

人工智能 深度学习

“堆内存持续占用高 且 ygc回收效果不佳” 排查处理实践

京东科技开发者

前端 堆内存 回收器 JavaScrip 企业号 3 月 PK 榜

老生常谈React的diff算法原理-面试版

beifeng1996

前端 React

一起玩转开源数据库!OceanBase DevCon 之开源生态全景解析

OceanBase 数据库

数据库 oceanbase

重磅 | 超级自动化行业黑马九科信息再获数千万A+轮融资 ——电科信息领投,深创投索斯福跟投,老股东信天创投、青松基金追加投资

九科Ninetech

C++入门简单实例

老王同学

c++ 入门

新一代通信协议—— RSocket

老周聊架构

响应式编程 2月月更 rsocket

美团前端常见react面试题(附答案)

beifeng1996

前端 React

FLstudio2023水果编曲软件下载及中文语言切换教程

茶色酒

FLstudio2023

2023年最佳Aspera替代方案,选择适合的Aspera替代方案

镭速

一次线上OOM问题分析

艾小仙

Java OOM 问题排查 排查方法

研发效能度量标准与实践

思码逸研发效能

研发效能

问:React的setState为什么是异步的?

beifeng1996

前端 React

见山,见路,见天地:OpenHarmony的开源共建攀登

脑极体

开源鸿蒙

22道js输出顺序问题,你能做出几道

loveX001

JavaScript 前端

N皇后问题的回溯法实现

老王同学

c++ 八皇后 回溯法

一文看懂:近期不断 “狂飙” 的 ChatGPT | 社区征文

架构精进之路

ChatGPT

美团前端二面面试题

loveX001

JavaScript 前端

Python:Excel自动化实践入门篇 乙【送图书活动继续】

eng八戒

Python Excel Python自动化办公

ChatGPT看技术发展趋势| 社区征文

攻城狮Wayne

人工智能 openai ChatGPT

chianmaker交易初探

liwh1227

区块链 共识算法 联盟链架构

一文深度解读音视频行业技术发展历程

阿里云视频云

云计算

面试官:说说Event Loop事件循环、微任务、宏任务

loveX001

JavaScript 前端

NLP 双数组字典树(double array trie) 基于darts-java改进,增加词性存储。

alexgaoyh

elasticsearch nlp darts-java 词性 double array trie

前端经典面试题(有答案)

loveX001

JavaScript 前端

如何快速理解事务隔离

Dinfan

数据库 innodb 事务隔离

ChatGPT 不仅是 AI 的成功,也是云计算的成功 | 社区征文

多颗糖

云计算 AI 云原生 ChatGPT

志愿者招募令|来!一起Build OceanBase第一次开发者大会

OceanBase 数据库

数据库 oceanbase

根据文本描述生成视频,Tune-A-Video 效果惊艳

Zilliz

计算机视觉

号码隐私保护服务:保障亿万消费者的隐私安全

阿里云视频云

云计算

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