AICon日程100%就绪,9折倒计时最后一周 了解详情
写点什么

一年覆盖九种语言上千服务,作业帮 Service Mesh 如何大规模落地?

  • 2022-12-01
    北京
  • 本文字数:4663 字

    阅读完需:约 15 分钟

一年覆盖九种语言上千服务,作业帮 Service Mesh 如何大规模落地?

2019 年底,作业帮技术栈比较多元且业务复杂度较高:使用最多的语言为 PHP 和 Golang,约占到总模块数量的 60% 左右;此外还有大量的系统使用 NodeJs、Java、C++、lua、python 编写等,即使是同样的技术栈,也会因为业务特点、团队特点,技术栈上呈现出较大差异;工具型产品侧重客户端,服务端技术偏保守。产业互联网业务,领域驱动,大量使用微服务架构,但由于没有统一的标准,各自团队也在自研服务治理体系的基础设施。


语言栈多元后,业务间的沟通协作就变得困难。跨语言的微服务框架难以落地统一的服务治理标准,致使业务服务治理参差不齐,大大限制了业务的快速迭代和稳定性。


同时作业帮的服务调用方式比较多样化,有 HTTP、gRPC、自研协议等,治理难度非常大,不同的 RPC 协议也会导致服务间通信困难。作业帮当时已有数千个服务,且服务间请求链路较长,一次请求的深度可能就超过一百多、甚至数百。


此时,已经完成容器化进程的作业帮开始着手调研服务治理技术,希望借助 Service Mesh 技术,来解决当时复杂的服务治理问题。


同年,为了适应云原生发展,作业帮进行了组织架构调整,将运维、安全、数据库、架构研发和部分通用中台等统一归纳到了基础架构团队。Service Mesh 的工作也落到了基础架构团队头上。


解决复杂治理问题最大的“拦路虎”是:业务既渴望使用新技术,但又担忧会带来高昂的使用成本,因此宁愿原地停留也不进行升级。那么,作业帮基础架构团队是如何解决这一问题的呢?这次,InfoQ 有幸采访了基础架构团队负责人董晓聪和架构研发团队负责人吕亚霖,为我们详细阐述了作业帮的实践思路和效果。

全自研 Mesh


“基础架构团队在进行服务治理时,既要保证稳定性,还要能够帮助业务提升效率。”董晓聪总结道。具体来说,团队的核心目标就是让 Service Mesh 接管服务治理里大量的非功能逻辑,实现服务的流量控制、可观测性和安全韧性,并且通过能力下沉,让业务透明、无感地接入。


但面对当前市面上各种开源产品,基础架构团队在前期充分调研后,认为这些产品都不太能满足作业帮的需求,因此选择了一条全自研的路。

数据面,更看重性能


数据面上,作业帮更倾向追求极致的性能,而对扩展性的需求并不迫切。这是由于作业帮内部的链路较长(上百 span),对业务来说哪怕是单次请求毫秒级的损失,整体上都会带来较大的影响。


对于主流产品 Envoy,作业帮基础架构团队不太认同它的插件模式。“插件机制引入主要是为了降低开发难度,虽然能有效降低研发成本,但是性能较差,同时提供的隔离也不彻底。”作业帮架构研发团队负责人吕亚霖说道。


因此,基础架构团队用 C++ 自己实现数据面,初期按需求紧迫程度支持了三类协议:第一类是 RPC 数据面,负责服务通信;第二类是对象存储数据面,负责对象存储资源的鉴权管理、流控、分发及性能提升;第三类是加解密数据面,负责提供安全和数据加密的能力。这三种数据面的协议差异性很大,分别对应了 RPC 通信协议、文件读写流协议、加解密协议,且对性能要求极为苛刻。



整体上,基础架构团队主要针对 RPC 协议,采用了 Mesh-proxy 代理方式。对于入流量,直接通过 UDS 转发给了 Server,Server 需要支持 UDS 监听;对于出流量,则与 Istio 类似,用 iptable 拦截,不过团队另用 eBPF 做了优化。


吕亚霖表示,iptable 出流量拦截过程复杂,带来了不少的性能损失,因此团队使用 eBPF 优化内核网络劫持,在 Sock Map 进行映射、省掉中间环节,就可以极大提升劫持性能。eBPF 优化的前提是系统内核是 5.X 版本以上,作业帮使用的是 5.10 版本,主要是 5.10 版本解决了 CO-RE 有利于后期的升级维护,而 Istio 为了适应大部分客户内核低版本情况并没有支持。


根据作业帮此前的测试,以 Envoy 官方数据为例,在 QPS 为 1000 下,Envoy 在模式的 v2-stats-wasm_both 下 P90 响应时间是 2.25 毫秒,相比于 baseline 测试结果,添加了 Envoy 边车之后 P90 时延增加了 1.3 毫秒,且随着并发加大逐步恶化。作业帮自研数据面实测添加了 mesh 边车之后 P90 时延增长比这个数据降低了 0.38 毫秒,随着并发加大比较稳定。当 QPS 从 1000 加到 10000 时,平均响应时间减少 0.4 毫秒。另外在 CPU 耗损上,在 QPS 为 1000 的情况下,Envoy 耗损 0.54 核,作业帮的数据面损耗 0.09 核。这项测试也验证了作业帮数据面的可用性。



事实上,从立项到数据面研发完成,基础架构团队只用了两个月左右的时间。“我们是把问题进行了拆解和聚焦,使用了云原生 Kubernetes 的基座,初期只对 RPC 类流量做了 mesh 劫持。同时聚焦数据面性能本身。”作业帮基础架构负责人董晓聪说道。

控制面,纳入统一管控平台


控制面上,作业帮本身有完整的运维管控体系,即包含服务注册发现相关,还有服务感知的一系列能力。所以作业帮并没有单独做一个 Service Mesh 的控制面,而是基于已有体系扩展,直接实现进行流量管控、通信协议、安全等。


对于作业帮来说,管控面是 DevOps 理念的落地,能更好的贴合自身研发流程和组织管理,比如:统一鉴权、工单体系、审计体系等。


对于 Service Mesh 的控制面,作业帮并没有引入类 Istio 在 Service Mesh 的实现服务注册发现,而是使用原生的 Kubernetes 的注册发现。作业帮基础架构团队认为,在大型的复杂工程中,架构设计的核心目标是复杂度降维,而将服务注册发现引入到 Service Mesh 却是在将复杂度升维,Kubernetes 的服务发现是 node 级别,而 Istio 的服务发现是 pod 级别,服务发现数据是数量级的提升。而对于升维带来的更强计算力和内存需求等问题也没有给出很好的解决方案。比如 Istio 的 xDS 使用全量下发策略,会把整个网格内所有服务发现数据同步给 proxy 边车,这会带来一系列的问题。


另外根据团队观察,很多公司在接入的时候,精力被耗在了 xDS 对接上,从原有协议向 xDS 转换过程中也充斥着各种各样的问题。


基于以上考虑,作业帮并没有使用 xDS 来提供发现机制,而是沿用了 Kubernetes 里注册发现方式,通过 eBPF 来优化 service,也具备路由决策等能力。在基础架构团队看来,这种方式更加轻量级,也与 Kubernetes 社区的结合更为紧密。


另外在安全性方面,团队进行了认证授权、网络拦截等;观测性上,全量埋下了分布式追踪,支持日志的统一观测和监控等。


在作业帮基础架构团队看来,用不用某个协议只是看其能否满足实际需求或者是否认可它的模式。用 xDS 的好处是会有统一标准,但 xDS 能否成为事实标准,还有待时间的检验。


吕亚霖表示,目前将 xDS 当作标准还有一些风险。“xDS 成为标准的前提是升维带来的复杂度被其他方面拆解掉,但它现在的降维手段并不是一个通用方案,我们在看到新方案出来之前是不会跟进的。”不过团队也会继续观望,关键还是要看其能否在大型企业的大规模复杂场景下落地。

超预期的推广速度


研发完成后,基础架构团队开始了“边放量、边灰度、边优化”的循环。对作业帮来说,基础架构团队涵盖了不同方向的小组,团队内就可以完成闭环测试,然后再向业务推广。


实际上,Mesh 在作业帮内部的推广速度远超基础架构团队的预期。据悉,目前作业帮 Mesh 覆盖率已经超过 80%,涵盖了 C++、Python、PHP、Go、Java 等语言栈。董晓聪表示背后的核心原因有多个,一是流量管控和观测,真正帮助到了业务,二是 Mesh 是相对无感接入,三是 Mesh 落地提升了研发效率。


流量管控和观测方面:主要实现了流量管控、安全(认证授权)、可观测性(日志统计、全量分布式追踪)。流量管控上实现了很多业务期待的功能,比如自适应限流。很多情况下业务需要熔断限流,但是不太可能每个服务都进行压测配置限流阈值,同时业内的自适应限流算法与流量以及自身资源相关,也无法实现因下游服务容量问题时主动限流。作业帮将机器学习应用于该领域,实现了智能的流控,当通用模型不适合某些特定流量场景时,也提供基于过去半年的数据,学习和训练特有模型。


接入相对无感:业务几乎不需要改造,只需要兼容 listen uds,其他由基础架构直接升级,然后进行放量观察即可。改造成本极低。


研发效率方面:在原来的微服务开发模式下,模块非常多,业务进行联调和测试的效率非常低。比如联调要经过 CI/CD、发布到测试环境、验证等一系列复杂的过程,而微服务里改动一个需求可能就要改动几十个模块。一个研发每次改动就要重复一遍上述过程。而 Service Mesh 在研发阶段的作用就是使研发可以直接在本地启动服务,并且这个本地服务可以无缝的和远程的 Kubernetes 测试集群中的各个其它服务实现互相调用,免去了复杂的 CI/CD 流程。



“一个业务线里面有一两个服务用了发现效率提升非常明显后,会形成很好的口碑效应,之后该业务其他研发会主动找过来要求升级。”吕亚霖表示。据悉,作业帮内部研发主动升级的比例在 50% 左右。


不过在推广过程中,基础架构团队也踩过坑。一次灰度放量时,某业务线使用了不规范的 HTTP 协议,但 Mesh 拦截 RPC 流量是按标准协议处理的,所以就产生了冲突,该问题影响了服务间的通信。


“这也让我们认识到,多语言栈下的协议确实没有那么规范,而这种不规范更多是因为各个语言,在协议实现层面上的差异导致。”董晓聪说道,“同时也展现了 Service Mesh 这项技术的意义,即接管服务治理里大量的非功能逻辑,实现标准化。”


除了这次事故,其他方面都远远超过了团队的预期,甚至由于需求变多,团队不得不投入更多的人力。


同时这次 Mesh 落地实践也让基础架构团队深刻体验到了内核研发能力的重要性。


“服务的各种小问题会特别容易摧毁业务线对你的信任。问题多了,哪怕是他业务的问题也会怀疑是 Service Mesh 的问题。”吕亚霖表说道,“这些问题都要及时解决,但在这个过程中,团队发现最后这些问题大部分需要在内核层面定位和配合解决。比如业务反馈平响多了几毫秒或者毛刺率变高,都需要在内核底层进行追踪定位,需要基础架构团队有一套分析定位内核的工具,同时内核追踪需要和业务的分布式追踪关联,才能快速定位解决问题。


总体来看,作业帮 Service Mesh 的落地收益比还是很不错的。作业帮基础架构团队只投入了两个专职人力,进行 Service Mesh 的研发和迭代。推广上持续了一年。通过 Mesh 的协议升级,带来了性能和稳定性的提升,比如 PHP、python 很多都是 HTTP1.0 的短链,团队通过 mesh 层进行协议协商升级,在业务无感的情况下将 HTTP 升级到了 2.0,减少网络建连、提升了网络传输速率。同时 Service Mesh 的落地带来了治理能力的大幅提升,全量的分布式追踪、完善的监控报警,以及在协议实现上的标准和统一。

结束语


虽然如此,吕亚霖提醒道,业务体量不大的时候跟风上 Service Mesh 并不会带来太多收益,甚至可能使整体产品的迭代变慢。多语言栈、链路比较长、业务要求比较高的情况更适合接入 Mesh。


“真正落地的时候你就会知道适不适合了,真正引入 Mesh 后发现推广不下去,本质上就说明了不适合。一项技术非常匹配时,推广便是一件水到渠成的事情。”吕亚霖说道。


另外,企业真的要接入 Mesh,也没有必要自研。自研对企业的研发能力要求会比较高。首先,Mesh 自研对 C++ 工程师的研发能力要求很高,但如今很多公司大多是 Java 工程师做基础架构。其次,根据作业帮基础架构团队的经验,团队要有内核研发和定位的能力,对于一些小公司来说可能并不具备这样的条件。


对于当前自研的选择,吕亚霖表示,这是有很多前提条件的。“比如 97% 的容器化、整体内核升到了 5.10、多语言栈、业务链条复杂、对时延敏感等,我们会觉得自研会更有优势。一旦这些前提不在了,自研就不见得比选择现有产品更好。”


嘉宾介绍:


董晓聪,作业帮基础架构负责人

吕亚霖,作业帮基础架构 - 架构研发团队负责人


2022-12-01 09:367234

评论 2 条评论

发布
用户头像
2个人力就做到了全自研, 太牛了吧
2022-12-04 01:42 · 日本
回复
用户头像
当年兴起一个微服务的新潮,大家都把系统架构搞得胡里花俏的,最近也有人反思是否真的需要微服务。比如把,github改造完成微服务后,后悔了,而马斯克最近正在改造推特,发现一个app上千个请求,还把指责他的员工给开除了。我之前也改造微服务,还好改造得不够彻底,最近我又把微服务合并回去了,做成宏服务,然后发现软件跑得更快了,因为没有http远程调用
2022-12-03 14:21 · 北京
回复
没有更多了
发现更多内容

观测云:简化复杂的云账单,让企业轻松掌控云成本

观测云

云账单

HyperWorks二维网格划分及拓扑改进

智造软件

Hypermesh 网格划分 有限元

ChatGPT Search 上线 允许用户像使用搜索引擎一样完成即时搜索

吴脑的键客

ChatGPT Azure OpenAI

突破 RAG 局限,KAG 专业领域知识服务框架正式开源!

可信AI进展

TiDB br日志备份PermissionDenied

TiDB 社区干货传送门

实践案例 备份 & 恢复

Llama 3.2 Vision & Molmo:多模态开源生态系统基础

Baihai IDP

程序员 AI Baihai IDP Llama 3.2 Vision Molmo

CST如何进行局部网格剖分

思茂信息

cst cst使用教程 电磁仿真

用二维码展示信息,有哪些常见应用场景

草料二维码

盘点国内3家主流的巡逻巡更系统

软件大师兄

TiDB Vector 本地部署体验

TiDB 社区干货传送门

8.x 实践 TiDB Cloud TiDB Vector

探讨Java深搜算法的学习笔记

威哥爱编程

Java 算法 DFS

人工智能如何从神话走向科学的?

天津汇柏科技有限公司

人工智能 AI 人工智能

有哪些值得尝试的8款TODO清单工具?

爱吃小舅的鱼

TODO todo软件

鸿蒙网络编程系列42-仓颉版域名解析示例

长弓三石

DevEco Studio 开发实例 HarmonyOS NEXT 网络与连接

【论文速读】| APILOT:通过避开过时API陷阱,引导大语言模型生成安全代码

云起无垠

10分钟写一个tidb-ai机器人帮你解答tidb问题

TiDB 社区干货传送门

新版本/特性解读

Java如何实现企业微信审批流程

威哥爱编程

Java 微信 企业微信开发

WiFi 7: Redefining the Game of Industrial Connectivity

wallyslilly

WiFi7 ipq9574

Emeritus硅谷AI深度研学之旅圆满落幕,探索AI前沿投资洞察!

科技汇

知乎 PB 级数据:超大规模TiDB集群管控实践

TiDB 社区干货传送门

实践案例 集群管理 数据库架构设计 HTAP 场景实践

商协会管理系统(源码+文档+部署+讲解)

深圳亥时科技

Elasticsearch开源仓库404 7万多star一夜清零

吴脑的键客

数据库 搜索引擎

TiDB数据库出现性能问题,如何利用数据库性能诊断工具DBdoctor一分钟诊断!

TiDB 社区干货传送门

性能调优 实践案例 管理与运维 安装 & 部署 应用适配

TiKV Raft Store 内存管理的原理与实现丨TiKV 源码解读(二十三)

TiDB 社区干货传送门

Merge-region 原理及常见问题

TiDB 社区干货传送门

故障排查/诊断

GreptimeDB vs. SQLite —— 高通 8155 平台上的性能对比报告

Greptime 格睿科技

sqlite 数据库 边缘计算 嵌入式 性能报告

智慧停车系统(源码+文档+部署+讲解)

深圳亥时科技

软件测试学习笔记丨Flask框架-集成Swagger文档

测试人

软件测试

1024程序员节 | 华为与开发者共筑智能应用新生态

Geek_2d6073

TiDB 集群组件间开启 TLS(双向认证

TiDB 社区干货传送门

7.x 实践

Rust 在 Android 的编程实践——技术驱动的车云一体化解决方案探索

Greptime 格睿科技

android rust 时序数据库 车云

一年覆盖九种语言上千服务,作业帮 Service Mesh 如何大规模落地?_云原生_褚杏娟_InfoQ精选文章