写点什么

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

评论 3 条评论

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

华为丁耘,解读百尺竿头的中国5G

脑极体

融合与共生之下,区块链都能“+”什么?

CECBC

区块链 大数据

后疫情时代,华为云会议如何定义未来会议?

华为云开发者联盟

视频 会议

详细讲解:python中的lambda与sorted函数

计算机与AI

Python

极客时间架构师培训 1 期 - 第 4 周总结

Kaven

UBBF2020:智能联接,共创行业价值新增长

DT极客

腾讯技术官又曝神作,两份堪称‘千古绝唱’操作系统笔记现已被全网疯传

编程 操作系统 计算机

分配时间戳和生成水位线

小知识点

scala 大数据 flink

解释一下==和equals的区别,你以为就这么简单?那你就草率了

小Q

Java 学习 架构 面试 基础

netfilter/iptables 原理

为为

Service Mesh Linux Kenel

推荐一款MySQL开源客户端,免费+跨平台+使用便捷!

王磊

MySQL

远程触发Jenkins的Pipeline任务的并发问题处理

小Q

Java 学习 编程 架构 并发

容器技术为什么会这么流行

架构师修行之路

Docker 容器 分布式 微服务

华为云专家带你解读文本情感分析任务

华为云开发者联盟

内容 数据 分析

BATJ内部Java求职面试宝典,尤其应届生如果还没有学过那后悔去吧,也许你已经错过N多家大厂offer;

Java架构师迁哥

甲方日常 30

句子

工作 随笔杂谈 日常 心情

打通Docker镜像发布容器运行流程

架构师修行之路

Docker 容器 分布式 微服务

技术心得丨一种有效攻击BERT等模型的方法

华为云开发者联盟

学习 AI

Underlay网络:如何立住可靠又支持大规模无收敛的“人设”

华为云开发者联盟

云服务 交换机

优秀开源项目、博客、书籍整理

铁匠

收藏教程 资源汇总

CECBC区块链专委会副主任吴桐主讲全国社保基金数字货币讲座

CECBC

区块链 数字货币

面向对象编程会被抛弃吗?这五大问题不容忽视

Java架构师迁哥

Python 疑难问题:[] 与 list() 哪个快?为什么快?快多少呢?

Python猫

Python 学习 编程 程序员

随机森林原理介绍与适用情况(综述篇)

计算机与AI

数据挖掘 学习 数据科学 随机森林

「红黑树」背了又忘?深入本质,他也不过是一棵二叉树

小松漫步

Anaconda安装使用和akshare库使用

MySQL从删库到跑路

Python 数据分析 Windows 10 Anaconda akshare

Tensorflow2.0安装使用

MySQL从删库到跑路

人工智能 tensorflow Anaconda Jupyter Notebook

Kubeless 函数部署遇到了问题,如何 Debug? | 玩转 Kubeless

donghui

Serverless kubeless

技术解读丨分布式缓存数据库Redis大KEY问题定位及优化建议

华为云开发者联盟

云计算 华为 技术

OpenResty 项目脚手架

铁匠

lua nginx openresty

图解 K8S 源码 - QoS 篇

郭旭东

Kubernetes Kubernetes源码

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