作者 | 商业广告平台团队
导读
从十几个模块到上千个微服务，百度如何构建业界最复杂的微服务系统？Jarvis平台，十年磨一剑，集服务治理、配置管理、链路追踪于一体，打造云原生控制中心。Jarvis2.0，多运行时架构的先驱，实现微服务治理的全新突破。节省耗时、提升效率，Jarvis2.0在60+产品线中部署4w+实例，节省人力与资源。技术爱好者，点击深入了解，一探究竟！
全文6160字，预计阅读时间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。
- 覆盖多语言 Web 无状态应用
不再局限Java语言，统一对Web无状态应用（SpringBoot应用 / 静态网页应用 / Node应用 / Go应用）提供一揽子的微服务治理全家桶，支持业务低成本的使用内容路由、可观测性、流量染色、熔断限流等治理能力。
——————END——————
推荐阅读
908
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
