写点什么

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

评论 3 条评论

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

Python代码阅读(第38篇):根据谓词函数和属性字符串构造判断函数

Felix

Python 编程 Code Programing 阅读代码

☕【Java技术指南】「技术盲区」看看线程以及线程池的异常处理机制都有哪些?

码界西柚

Java 线上程序问题 线程异常 10月月更

从Ftrace开始内核探索之旅

金蝶天燕云

Linux内核 Ftrace

SSH工具有哪些?哪款好用?

行云管家

运维 SSH 文件传输 SSH工具

超低延迟直播架构解析

百度开发者中心

音视频 直播技术 智能视频

怎样才能画出清晰明了的时序图

华为云开发者联盟

接口 模型 UML 系统 时序图

java springboot自习室选座预约小程序源码

清风

计算机毕业设计

【万字长文】吃透负载均衡

Java 负载均衡 架构 面试 后端

无处不在的Kubernetes ,难用的问题解决了吗?

望宸

容器 云原生 PaaS KubeVela kubenetes

第六届世界智能大会主题征集活动入选主题公布

InfoQ 天津

开源许可协议介绍

webrtc developer

官方线索|2021科大讯飞全球开发者大会

搬砖人

AI 大会 1024我在现场

10 月 30 日 北京 LiveVideoStack 阿里云视频云专场限量赠票 100 张

阿里云CloudImagine

阿里云 音视频 高清视频 视频编解码 视频云

腾讯云,五轮面试,六个小时,灵魂拷问,含泪拿下 60W offer

收到请回复

Java 面试 大厂Offer

开源应用中心 | KodExplorer高效流畅云端存储&协同办公新体验

开源 开源技术

北鲲云超算平台提供生命科学领域所需要的哪些软件?

北鲲云

新书榜第一的《图解产品》,帮助内卷中的产品经理实现跨越式发展!

博文视点Broadview

产业互联网下半场,SaaS平台的机遇与挑战

雯雯写代码

SaaS

秀到飞起!Alibaba全新出品JDK源码学习指南(终极版)限时开源

收到请回复

Java jdk 面试

关于征集第六届世界智能大会平行论坛活动方案的通知

InfoQ 天津

爱奇艺埋点投递治理实践

爱奇艺技术产品团队

数据治理 埋点 pingback

基于HarmonyOS分布式技术,这群学生赋予冰箱更智能的体验

科技汇

阿里大牛珍藏版:高并发系统设计(全彩版手册)带你从基础走向实战

Java 架构 面试 后端 高并发

等级保护测评机构哪里可以查询?谁能告知一下!

行云管家

网络安全 等保测评 安全等级保护

iOS签名校验那些事儿

百度Geek说

后端

一周信创舆情观察(9.27~10.10)

统小信uos

人社部、工信部颁布人工智能国家职业技能标准,百度参与制定

百度大脑

人工智能

​涉密信息外泄,移动办公信息安全将如何保障?

BeeWorks

产品、

如何选择 Web 的数据存储方式?看我就够了

神策技术社区

存储数据 Web JS SDK sessionStorage

技术干货 | jsAPI 方式下的导航栏的动态化修改

蚂蚁集团移动开发平台 mPaaS

容器 大前端 移动开发 mPaaS 动态化

云小课丨SA基线检查:给云服务来一次全面“体检”

华为云开发者联盟

态势感知 华为云 基线检查 SA 上云合规

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