微服务架构革新：百度 Jarvis2.0 与云原生技术的力量

2024-07-30
上海
本文字数：5227 字
阅读完需：约 17 分钟

作者 | 商业广告平台团队
导读
从十几个模块到上千个微服务，百度如何构建业界最复杂的微服务系统？Jarvis 平台，十年磨一剑，集服务治理、配置管理、链路追踪于一体，打造云原生控制中心。Jarvis2.0，多运行时架构的先驱，实现微服务治理的全新突破。节省耗时、提升效率，Jarvis2.0 在 60+产品线中部署 4w+实例，节省人力与资源。技术爱好者，点击深入了解，一探究竟！

全文 5227 字，预计阅读时间 16 分钟。

01 业务背景介绍

随着云计算和微服务架构的飞速发展，百度 Jarvis2.0 的诞生标志着一个新时代的到来。作为业界领先的广告技术平台，百度商业产品矩阵通过效果广告和展示广告两大类，以及基木鱼、观星盘等营销工具，为广告主提供了一个强大的营销生态系统。这些工具不仅帮助客户精准传达营销诉求，更是在广告检索系统中架起了一座桥梁，实现营销目标的高效达成。

在广告存量竞争日趋激烈的今天，百度的商业产品不断演进，以小步快跑的方式，加速新功能的孵化与上线。这种快速迭代的需求，推动了商业平台采用统一的微服务架构，微服务模型采用“应用粒度”描述（类似 Dubbo3.0 / SpringCloud / ServiceMesh）。遵循“高内聚低耦合”的设计原则，从最初的十几个模块扩展到 1K+微服务，构建了一个庞大而复杂的服务网络。经过十多年的演变，商业平台的微服务架构成为了业界最复杂的微服务系统之一。

商业平台系统复杂度的主要驱动力来自业务产品的演化和组织的演化，其理论依据就是康威定律。

然而，随着微服务数量的激增，如何保证系统的高效运行和稳定性成为了一个巨大挑战。为此，百度基础技术团队研发了 Jarvis——一个面向复杂业务系统的应用托管平台。Jarvis 不仅提供了分布式服务框架和统一配置管理，还包括了分布式链路跟踪、容量规划、高可用性及数据化运营等微服务治理能力。作为内部开发平台，Jarvis 致力于简化业务研发人员的操作流程，降低他们对基础设施的认知负担，使他们能够更加专注于创新和业务发展。

按照“平台工程”社区主要贡献者和 Humanitec 的产品负责人 Luca Galante 的说法，平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。Jarvis 平台就是平台工程的一种经典实践。

Jarvis2.0 的推出，更是将百度的微服务治理推向了新的高度，整合了微服务治理生态，定义了一套适合百度商业 Web 技术栈的治理方案，为云原生技术的发展注入了新的力量。

02 云原生进阶的目标

Jarvis 平台提供贯穿微服务生命周期（开发、测试、部署、运维）的自助服务工具，通过屏蔽基础技术栈的复杂性，高效支持业务发展。十年微服务治理经验沉淀，我们形成了完整的治理生态，蕴含在 10+ 治理组件（JVMTI 探针、Launcher、蜂鸟、流量录制、日志采集、应用诊断等）和 10+ Starter（ConfigStarter、StarlightStarter、JdbcStarter、AcutatorStarter、RedisStarter 等）。

△商业平台治理生态发展史

尽管现有的组件在解决特定问题上有所成就，但它们往往缺乏统一的标准和语言无关的实现，导致控制能力分散，使用体验不连贯，效率提升空间巨大。当 Kubernetes 统一了容器编排管理系统之后，这些纯技术性的底层问题，便开始有了被广泛认可和采纳的基础设施层面的解决方案。Kubernetes 容器编排效率和容器虚拟化方面的卓越表现，也能让发布效率问题得到更优雅的解决。因此我们在探索一种全新的架构，旨在整合云原生的先进技术与现有的治理组件，以提升治理效率，让业务团队能够快速享受到云原生带来的红利。

这一架构升级的目标是双重的：

业务尽可能不改动原有代码的前提下完成上云；
进一步提升治理效率，解决当前问题：

应用全版本发布慢
平均耗时 30 分钟+，95 分位值 100 分钟+，核心服务上线 45-60 分钟。
容器隔离性差，经常出现资源被其他业务容器抢占（特别是磁盘 IO）导致的线上问题。
发布态治理操作慢
线上切流只能走配置上线，止损慢。
调优单个指参数（修改数据库连接池参数、日志级别等）耗时长（30min+/次）。
全链路灰度只能通过增加机器来物理隔离，效率低、资源浪费大。
监控迭代效率低、业务自定义难
监控探针升级频繁，数万个 Pod 线上推全需 1-2 月。
Argus 3.0 易用性差、高阶功能缺失且已不再迭代。

在公司全栈上云的背景下，2023 年 Jarvis 团队协同 EKS、智能监控、ENS 以及 iRegistry 团队，实现了 Jarvis 应用的 Kubernetes 部署，通过定义一套开放式的微服务控制面标准协议，打造云原生控制中心，实现了微服务治理组件的统一管理和调度，提升了平台的运维发布治理效率。

弹性容器服务（Elastic Kubernetes Service，简称 EKS）是公司云原生化的平台载体，通过 Kubernates、OpenKruise 等新架构提供云原生基础设施。
智能监控平台（Intelligent Monitoring）是针对云原生场景构建的新一代 Prometheus+Grafana 监控服务。
弹性名字服务（ElasticNamingService，简称 ENS），云原生时代的名字服务，与 EKS 天然融合。
镜像仓库(iRegistry)，分布式全托管的镜像制品管理服务。

△Jarvis2.0 产品功能图

03 商业平台多运行时落地实践

商业平台研发部的云原生微服务托管平台 Jarvis2.0 整合微服务治理生态，从控制面和数据面、部署面三个角度，定义了一套适合当前百度商业 Web 技术栈的微服务治理方案。

我们首次引入了多运行时架构，所谓的多运行时（Multi-Runtime）架构，其实是借鉴了 Service Mesh 的思路，不同之处在于 Service Mesh 引入了 Sidecar 模式重点解决服务间通讯需求，但是 Multi-Runtime 架构则提出将各种各样的分布式能力全部外移到独立 Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime” （多运行时）架构。

Jarvis2.0 通过定义一套开放式的微服务控制面标准协议，实现数据面的统一管理和调度。数据面，则展现出生态的多元化，例如多语言的 Proxyless、跨语言的 Envoy 代理、JVMTI agent 等技术各施所长。一套 CRD 治理标准协议，下发多套治理数据面，从而将原来分散、割裂的基础组件通过合理的架构组装在一起，来满足多元化的微服务场景。

包括以下 3 个核心部分：

运行时 Moonlight（数据面）：运用 Multi-runtime 的架构设计，Sidecar 边车部署。以统一标准、易扩展、非侵入方式整合 Starlight、环境变量、诊断、Launcher、探针、安全、Debug 等 10+组件，实现启动管理、监控、诊断、动态调优、安全管控等治理能力。
部署面：结合镜像分层自动构建、OpenKruise Cloneset 原地升级、KubeVela OAM 引擎应用编排能力，支持业务应用原地升级、多集群一体化部署编排和灰度发布；结合 OpenKruise Sidecarset 的组件管理能力，实现 Moonlight 等 Sidecar 的自动注入、原地升级和灰度发布。
控制面 Gravity：遵循云原生 Service Mesh 动态通信控制协议 xDS，提供统一的控制面标准协议，实现请求内容路由、流量权重路由、路由标识全链路传递、路由控制秒级生效的动态路由和参数调优、诊断、集群日志检索的指令下发。

3.1 运行时 Moonlight（数据面）

△运行时 Moonlight 架构图

△运行时动态治理

Moonlight 伴生方式部署在每个应用容器上，因此对启动时间和内存消耗极其苛刻。我们最终采用了 GraalVM Native Image 技术，使用 SpringBoot Native 编译 Moonlight，使 Moonlight 完全脱离了 JDK 运行，5 秒内启动，仅占用 128M 内存。

包含以下核心通路：

探针植入通路：支持探针动态植入、卸载、热升级。Native 化后，标准的 JVMTI 能力和反射难以使用，需要非常特殊的适配，属于业界首创。
动态治理通路：以 xDS Client 为中心监听治理信息，面向应用进程提供统一治理信息获取通路。关键能力如下：
流量染色：扩展探针无侵入 Tracing 能力，跨进程、跨线程传递流量标识，全链路染色。
限流熔断：利用探针实现织入式限流、熔断。
参数调优：支持日志级别、数据库连接池调优，并能快速扩展其他调优能力。
配置热升级：结合 Kubernetes 部署机制和 Java 动态代理特性，秒级更新配置。
应用诊断：以旁路方式，按需诊断应用。集成大量的开源可插拔工具，JVM 监控命令（Jstack、Jinfo、Jstat、JMAPHISTO 等）Arthas、性能火焰图、系统环境工具（lsof、env 等）。
静态治理通路：基于 Launcher 组件，实现 Jar 包自动替换，随业务重启生效。
监控报警通路：涵盖 Metrics、Tracing、Log 等数据类型，满足异构语言和场景的监控数据汇总分析与异常报警需求。
Metrics 通路为微服务提供开箱既用报表和报警，支持分平台配置和算法推荐阈值。
Tracing 通路日处理 70+亿条调用数据（峰值流量 40w/min），支持在百亿条数据中 10s 内检索出单个请求路径。

3.2 部署面

部署面承担了业务应用和 Moonlight Sidecar 的高效部署工作，能够支持超大规模集群的一体化管理、灰度升级和原地发布、组件自动注入。

部署面比较复杂，这里大致介绍下其中两项关键技术。

镜像自动化分层构建

基于 Jib 实现 SpringBoot 应用 / 静态网页应用 / Node 应用 / Go 应用，自动构建 Docker 镜像，避免 RD 同学编写维护 Docker file，开箱即用。Jarvis 平台用户开发完代码后，直接通过 iPipe 发布版本自动构建 Docker 镜像，并自动推送到 iRegistry 仓库。另外，对 fat-jar 进行分层构建 Docker 镜像，能够大幅减少镜像拉取耗时，相比在 Opera 平台的全量拉取，耗时缩短 75%。（业务代码升级一般仅 classes 层发送变动，上线是仅需要拉取 classes 层即可，classes 层一般 10K 左右，1s 内即可拉取完成。）

△fat-jar 解压文件目录

△jarvis 应用镜像分层方案

多集群一体化灰度发布

基于阿里巴巴和微软共同开源的云原生应用规范模型 OAM，对应用模型进行了抽象，借助 K8S+OpenKruise CloneSet\Rollout +KubeVela OAM 完成集群的多集群一体化管理、灰度发布和原地升级。

Jarvis 用户仅需要设置平台暴露的业务参数（应用版本、配置版本、实例数、资源套餐、外网权限、AFS 等），然后 Jarvis 借助 OAM 模型描述出应用信息、部署目标集群、上线工作流步骤。一键发起 app 上线时，Kubevela 会根据 App OAM 模型的定义，按照工作流步骤，自动将 App 部署到目标 K8s 集群。（差异化集中配置，工作流分发配置到集群）

△部署面架构图

△部署关注点分离

3.3 控制面 Gravity

Gravity 集注册中心、配置中心和控制面于一体。与 Istio 非常类似，控制平面和 Moonlight Sidecar 的交互均采用业界流行的 xDS 协议。它能实现低延迟、高时效、自动保活的注册发现能力，同时支持 10w+容器的无损上下线、请求内容路由、流量权重路由、路由标识全链路传递、路由控制秒级生效，比 zk 注册同步，更快更稳更强。

值得一提的是，xDS 原生数据模型对非服务通讯控制的定义比较薄弱。我们复用 xDS 相关内容并实现了一套易用丰富完备的控制协议，实现各标准组件执行行为的动态可调控，支持限流、熔断、日志级别、超时、参数调优、应用诊断等控制命令。

△Gravity+Starlight 框架

△xDS 协议扩展出控制能力

无损上下线：Gravity 与 BaikalDB 深度定制，对业务进行分组轮询缓存，内部统一事件通知总线，定向长轮询通知机制，确保秒级服务发现。
异常节点自动剔除：（client 发起剔除）starlight 自动统计调用质量，动态剔除有问题的远程节点；（server 主动剔除）一旦服务自身状态健康检查持续有问题，自动停止心跳等待异常恢复；（控制面主动剔除）Gravity 全局统计僵尸节点，自动清理掉。
灰度发布：借助探针，跨进程、跨线程传递 Trace 信息时携带定制的路由标识；Starlight RPC 框架识别路由标识接住 xDS 通信协议全流程自动调整流量行为。
无侵入动态治理：Gravity 扩展出 MDS\DDS 协议覆盖控制需求（比如业务字段限流和熔断、日志检索命令等），管控 Moonlight 操纵多运行时自动治理，借助探针运行时织入熔断限流或者修改框架参数，实现业务无感治理。

04 项目收益

Jarvis2.0 覆盖了商业平台、闪投、CRM、品牌广告、手机百度、文心一言、小度云平台、健康商城等 60+产品线的 3K+个 Web 后端服务，部署了 4w+实例（200w+CPU 核）。上线节省耗时 2.14PD/天；核心治理功能使用 2K 次，节省人力 30PD+/天。

上云收益显著，主要体现在上云效率、治理效率和稳定性、扩展性四个方面：

接近零成本上云

Springboot 应用 \ 静态网页应用 \ Node 应用等自动生成 Docker 镜像，无需代码改造；开箱即用 Promethus+Grafana 云原生监控（200+监控报表、9+基础报警）。

部署治理效率数倍提升

稳定性显著提升

线上推全治理组件（数万个 Pod）从 1-2 月降到 1 天；线上切流从 3-5pd+降低到 3-5s。异常点摘除从 30 分钟+降低到 3-5s。依靠灰度，XSTP 线下环境全新搭建从 40 分钟降到 20 分钟，节省人力 1.6PD/天。熔断限流只需界面操作，无需代码改动或者上线重启。单个指标调优（数据库连接池、日志级别）从 120 分钟+降到 3-5s。