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

腾讯云 Service Mesh 实践:利用 Istio+K8s 进行后台环境管理

  • 2019-10-14
  • 本文字数:3549 字

    阅读完需:约 12 分钟

腾讯云 Service Mesh 实践:利用Istio+K8s进行后台环境管理

在过去的两年中,Service Mesh 迅速在业界走红,从概念期进入到了应用期。为了帮助大家解决 Service Mesh 在落地过程中可能遇到的问题,我们采访了多家互联网企业的应用实践,例如美团点评同程艺龙以及瓜子二手车等,本文我们采访了腾讯高级专项测试工程师黄俊,请他和大家分享腾讯的 Service Mesh 实践。今年 10 月,他将在QCon全球软件开发大会(上海站)2019分享题为《腾讯云上基于 Service Mesh 的后台环境管理实践》的演讲。

为什么需要 Service Mesh?

想要回答“为什么需要 Service Mesh”这个问题,首先得弄明白 Service Mesh 是什么。关于 Service Mesh 的定义,业界似乎已经达成了共识:Service Mesh 是云原生服务通信的基础设施。在黄俊看来,Service Mesh 最关键的部分是将服务通信管理能力从业务应用中剥离下沉至基础设施的思想与实现。


其次,Service Mesh 主要是解决什么问题?“透明无侵入是 Service Mesh 的最大特性。”黄俊表示,“Service Mesh 可以提供服务间一致可见性和网络流量控制,无需修改业务程序代码,即可获得管控服务通信流量与层级观测的能力。”


Service Mesh 主要解决的是传统意义上的“服务治理”,覆盖服务间流量、容错、安全控制和全面遥测。传统的主流解决方法是使用 SDK 类库的方式显式地对业务应用程序进行改造,但是这种方式在提供能力的同时,也带来了相应的维护和使用成本,从而间接影响业务开发迭代的效率,例如,开发团队需要感知并掌握治理框架、需要持续改造应用程序、对开发语言、对主被调服务接入 SDK 版本有依赖等等。而 Service Mesh 的出现,从网络层面自下而上地提出了更好的解决方案与实现,基于服务通信基础设施的定位和无侵入的特性,Service Mesh 可对业务开发透明地提供“服务治理”能力。


在企业技术部门中,黄俊认为开发与基础运维团队应该要格外关注 Service Mesh,并且关注的侧重点还有所不同:


  • 因为无侵入的特性,开发团队是感知不到 Service Mesh 的存在,因此在开发业务过程中,开发团队几乎不需要作任何适配,只需在服务部署上线后,直接下发指令与配置,对通信进行管控和查看观测数据。简而言之更偏向于“用”,Service Mesh 提供的能力作为工具为开发团队服务。

  • 对于基础运维团队而言,Service Mesh 已经成为 PaaS 基础设施的一部分,在“用”的基础上,还要做好“维护”工作,保证 Service Mesh 控制面与数据面的稳定性与可靠性会是重点工作。除此之外,部分大型企业还要为业务团队打造定制化 Service Mesh 工具,包括集成企业自身发布系统、Devops 流程、环境治理平台、微服务治理平台等等。

腾讯 Service Mesh 实践

早期,腾讯自研业务在内部做服务化拆分与部署时就已经在尝试应用 Service Mesh 相关技术来解决服务通信间的路由、容错、限流与监控。当时,腾讯内部多个业务线都有同类工具类落地,不过,都还停留在业务框架层面。近年,随着容器化技术的广泛应用,腾讯自研业务中也逐渐落地了 K8s,Service Mesh 才在腾讯的部分业务中有了真正意义上的落地,例如游戏、社交、工具平台等业务。


为了更清楚的阐述腾讯 Service Mesh 实践,我们将重点介绍一下其是如何利用 Service Mesh 进行后台环境管理。

技术选型:Istio+K8s

腾讯后台环境具有多租户、多分支、多环境的业务特点,需要高精度自定义通信流量管控,可实现动态配置不同租户(用户)请求依赖任意指定环境中的指定分支版本,同时支持在流量层面隔离租户依赖环境。


在技术选型方面,腾讯采用了 Istio+K8s 来实现后台环境的管理。Service Mesh 也有很多实现方式,为什么会选定 Istio + K8s 呢?黄俊解释主要是出于两方面考虑:


  • K8s 已经成为容器编排平台的事实标准,是 CNCF 与业界公认的云原生生态中枢。从广义上讲,Service Mesh 不依赖 K8s,Service Mesh 也不关心服务所运行的计算平台,但是与 K8s 结合能更完整地发挥 Service Mesh 的优势,K8s 的服务(负载)生产到 Mesh 的服务发现与通信接管可以是个自动化的过程。另外,业务容器化也是云原生的必选项。

  • 选择 Istio 的主要原因是社区大势,Istio 与 K8s 原生集成,源自同一个团队。Istio 是对 K8s 服务通信管控能力的建设与完善,更像是 K8s 的下一个迭代。Google Cloud 的 CTO 还曾经预估过,未来两年内会有 90%的 K8s 用户使用 Istio。在 Istio 已经定义了 Service Mesh 的事实标准,XDS v2 已经成为了 Service Mesh 通信的标准数据模型和协议的情况下,选择 Istio 不仅可以服务更多客户,而且可以完善基于 K8s 的容器服务平台。

后台环境管理的实践过程

据黄俊介绍,腾讯基于 Service Mesh 的后台环境管理实践可以分成 3 个阶段:


第一阶段:解决研发过程中开发调试与测试的冲突,开发测试环境与测试环境分离。这一阶段只要一次性把几套固定的环境搭建出来即可,但是一套环境中经常会出现相互冲突,例如测试同学之间的环境冲突。


第二阶段:一键自动化建立全新的测试环境,保证每个人在需要时,都有自己的开发测试环境。这一阶段,主要做了两部分工作:一是把环境进行容器化以便更好地做服务编排,K8s 能够让每个后台服务的搭建变得容易简单;二是对后台请求做精细化的路由管理,我们对 Istio Envoy 中的源码做了很多改造工作来支持更多的私有 RPC 协议。


第三阶段:结合 DevOps、CI/CD 以及自动化测试,在这一阶段,后台环境的持续部署能力将提升整体研发效能。


利用 Istio+ K8s 实现的后台环境管理,不仅降低了多种后台异构带来的环境成本,而且提升了研发测试过程的效率,根据黄俊的介绍整个实践过程的难点主要集中在以下三点:


支持私有 RPC 协议:Istio 不支持私有 RPC 协议的流量管理,而测试开发环境管理的核心就是需要 Istio 支持私有 RPC 协议流量的管理,同时,我们希望复用 Istio 原生的能力,而不是重复造轮子。


解决方案:利用 Istio 支持的 HTTP/gRPC 作为私有协议数据的传输隧道,同时将需要作为流量管理的信息暴露到 HTTP/gRPC header(例如:染色信息)。


支持私有名字服务:私有协议改造后,下发的 HTTP/gRPC 路由规则不生效,host 匹配失败,即私有名字服务解析到的 POD IP 无法匹配 ServiceName、ServiceIP 以及域名。


解决方案:在 Istio-proxy 的服务发现逻辑中记录 Service 和 POD IP 的映射关系,具体流量解析时,再通过 POD IP 反查该 POD 所属的 ServiceName,将反查值作为 host 字段。


支持流量转发给本地 POD IP:Istio-proxy 流量拦截后,透传给相同 POD 下的业务服务时,目标地址为 127.0.0.1,而业务监听的 socket 基本为 POD IP,链路不通。


解决方案:将下发的终点 socket_address 由 127.0.0.1 改为当前 POD 的 ip 地址,不过代价是舍弃 Istio 对 POD 调用自己流量的管控能力。

Service Mesh 未来发展

目前,国内的 Service Mesh 应用和开发基本都源自 Istio,无论是直接优化应用还是重构部分模块,主要投入者还是公有云云计算服务商,作为容器平台能力的补充。 另外,传统的微服务框架开始集成 Service Mesh 的一部分能力作为服务接入的拓展方式,主要面向私有云与传统行业转型。


在落地方面,整个市场还处于早期阶段,但比较乐观的是,随着 K8s 的推广和普及,相比于之前的迟疑,大家对于 Service Mesh 的认可度提高了,各个行业已经逐步有客户在主动尝试并生产应用 Service Mesh。


黄俊表示:“作为技术,Service Mesh 还处于发展期,即使是最火的 Istio 项目也才推出了 1.2 版本,尚未达到 K8s 那样的成熟度。”他认为 Service Mesh 目前存在的问题主要集中在以下两点:


  1. 性能损耗与拓展性:sidecar 主动劫持流量经过两次额外的 TCP/IP 堆栈穿越,与内核上下文切换,开源的版本平均每次调用将产生 5-8ms 延迟,这对敏感型业务来说,是比较难接受的。另外就是对服务通信私有协议的支持需要拓展。

  2. 维护成本:以 Istio 为例,整个微服务化的 Service Mesh 控制面与业务成正比数量的 sidecar,部署、升级、伸缩都需要投入相当大的精力与成本。


至于未来发展,黄俊认为 Service Mesh 的发展还是会围绕云原生服务通信基础设施的方向,作为基础 PaaS 平台的核心组成支撑上层的业务应用平台。另外,各大云服务商也需要在 Service Mesh 产品服务化上持续发力,解决和优化核心技术问题,打造成熟的解决方案和最佳实践,帮助客户迁移和应用 Service Mesh 与容器相关技术。


嘉宾介绍:


黄俊,腾讯高级专项测试工程师,现负责腾讯文档、手 Q 增值服务等质量团队。2014 年加入腾讯,经历了移动 APP/AI 测试的发展历程,目前主要聚焦在如何结合 DevOps 理念来助力团队研发效能提升。


在 QCon 上海 2019 的演讲中,他将重点阐述在腾讯云上如何利用云原生的解决方案 Istio+K8s 来对自研业务后台进行环境管理,过程中涉及到了如何来适配 RPC 私有协议、名字服务等技术细节。以及这套环境治理方案实际对业务在研发过程效率的提升效果,点此了解


2019-10-14 11:015474
用户头像

发布了 497 篇内容, 共 307.4 次阅读, 收获喜欢 1907 次。

关注

评论

发布
暂无评论
发现更多内容

大数据培训:RDD、DataFrame的区别

@零度

大数据 spark

iuap 助力鹏鹞环保打造智慧水务大数据运营管理平台

用友BIP

用友 用友iuap

ModStartCMS 模块化建站系统 Laravel 9.0 版 v3.3.0

ModStart开源

如何编写有效的常见问题解答(内附 5 个最佳示例)

小炮

基于小熊派开发板设计的云端绿化管理系统

DS小龙哥

IoT 3月月更

MVCC 时光机:在 TiDB 的时空自由穿梭丨渡渡鸟复兴会赛队访谈

PingCAP

财富管理2.0时代,券商数字营销突围之路

Speedoooo

数字化转型 解决方案 营销数字化 数字化业务战略 数字营销

Linux之traceroute命令

入门小站

Linux

【专访蓝景科技】5G+实时云渲染赋能数字孪生,共建元宇宙

3DCAT实时渲染

5G 数字孪生 实时云渲染

功效护肤理念增强,透明质酸继续引领护肤热点

易观分析

护肤 医美 透明质酸

Apache SeaTunnel & Kyuubi 联合 Meetup | 见证中国大数据崛起!

Apache SeaTunnel

大数据 开源 大数据平台 apache 社区 Apache SeaTunnel

“东数西算”超级工程上马,利好云计算但暗藏汹涌

行云管家

云计算 混合云 多云 东数西算

4种常见分支模式解析及优劣对比 | 研发效能提升36计

阿里云云效

阿里云 云原生 研发团队 研发 分支管理

改进DevSecOps框架的 5 大关键技术

禅道项目管理

DevOps 敏捷 自动化

web前端培训:React 核心调度功能的实现

@零度

前端开发 React

天翼云基于 KubeEdge 的大规模 CDN 场景落地实践

华为云原生团队

开源 云原生 边缘计算 边缘技术 边缘云

OAuthApp H5 应用开发/云托管平台

unclewang

微服务 前端 .net core H5制作 SaaS平台

安全大讲堂 | 2022产业趋势洞察:网络安全的下一个十年

腾讯安全云鼎实验室

网络安全 未来发展

黄东旭: 关于基础软件产品价值的思考

PingCAP

在线TOML转YAML工具

入门小站

工具

LigaAI完成A轮融资,加速打造全新的智能研发协作平台

LigaAI

行业资讯 智能 LigaAI A轮融资 研发协作平台

方舟开发框架容器类API的介绍与使用

HarmonyOS开发者

方舟 HarmonyOS 开发框架

【51单片机】介绍

謓泽

单片机 3月月更 51

FinClip 黑客马拉松正式开赛,码力集结,等你来战!

Speedoooo

小程序生态 hackathon APP开发 黑客马拉松 黑客松

CRM系统帮助降低业务成本的方式

低代码小观

企业管理 CRM 企业管理系统 CRM系统 客户关系管理系统

三步教企业搭建产品帮助中心

小炮

分库分表中间件的高可用实践讲解

Linux服务器开发

高可用 高并发 中间件 Linux服务器开发 Linux后台开发

3 月亚马逊云科技培训与认证课程,精彩不容错过!

亚马逊云科技 (Amazon Web Services)

架构师 培训

技术平台&应用开发专题月 | 一文搞懂全链路监控系统(上)

用友BIP

用友 用友iuap

你可以不知道KFC疯狂星期四,但不能不知道InfoQ会员周!七天限时福利冲冲冲!

InfoQ写作社区官方

热门活动 InfoQ会员周

项目启动 | 德荣医疗携手用友iuap共谱数字化转型新篇章

用友BIP

用友 用友iuap

腾讯云 Service Mesh 实践:利用Istio+K8s进行后台环境管理_服务革新_田晓旭_InfoQ精选文章