奔驰在打造未来汽车时的DevOps实践经验

mikea

  l7 d8 p7 X$ H5 y7 R
2 L% j+ K! J+ h: P* y: D* B7 W# f

Siva Mandadi 是来自奔驰北美研发中心的用户交互部门的一名 ITILxf.com" target="_blank" class="relatedlink">DevOps 工程师，他在一次分享中介绍了奔驰通过 DevOps 落地，加速打造未来汽车的实践。本文根据视频资料整理而来，原视频地址：

7 R+ S5 I& `5 ^" z, B7 k! L

https://www.youtube.com

& m* w$ ?- ^, E" [

背景介绍

奔驰对于未来汽车的定义涵盖了很多方面，包括车载音乐、导航、自动驾驶等等，涉及到的实现技术也是多方面的，如机器学习、物联网等前沿技术。这些技术表现在实际应用上，便有了一种“未来感”。举个例子，未来汽车可以根据天气情况，切换车内的主题，比如颜色、音乐等，让车主时刻都保持舒适的状态；或者，如果车主开车回家，在离家还有半小时车程的时候，可以通过车给家里的厨房电器发消息，开始准备煮一顿可口的饭菜。

" W$ v) g' |* v$ B& ^

! d2 |  M* t9 o+ E5 Y

最开始，整个用户交互部门（视频主讲人所在部门）大约有 300 名工程师，他们来自不同国家，分布在美国、德国和印度等不同地域；团队每天大约会执行 60 次构建任务；每周有超过 1000 个、约 1TB 数据量的自研件产生；平均 CI 构建时长为 6 小时。

( T+ x* T: J: r. Y面临的挑战

. w& W3 s4 l" ?  s

随着业务的发展，团队面临着巨大的挑战，主要是在工件的存储与共享、依赖管理、编排、持续构建和仓库不同等方面：

  ?! x3 Z( H& ]9 j

• 自研件存储：每周会产生超过 1000 个自研件，需要耗费近 ITB 存储空间，随着时间推移现有的存储资源很快就出现枯竭。

  
  # j0 c6 W! l# ~" y0 e% |5 ]; [

% \. ?) O+ v" E0 r

• 自研件共享：团队成员分布在世界各地，上传和下载的速度成为瓶颈，开发与 QA 人员通常会抱怨下载速度太慢。比如印度和德国的开发者需要上传，美国这边的 QA 需要下载进行测试就会遇到这种情况。

  
  

• 依赖管理：庞大研发团队的依赖管理也是一个非常头疼的问题，某些功能依赖的软件包在不同的模块中存在着不同的版本，而维护复杂的依赖关系是非常有挑战的一件事情。团队主要使用 Java 和 C++ 开发，并且使用了 maven、conan 作为依赖管理工具。

  
  1 e( x, |' u/ s5 k

3 b0 Z2 ^: [' e0 J% s
, j3 f/ F# t6 p

• 持续集成：持续集成对于这样一个大团队是必须的，每一次的提交都必须通过持续集成（CI）确保提交不会带来任何问题。团队使用了 Jenkins 和 Bamboo 做一些持续集成相关的事情，值得一提的是使用了 Docker Container 作为 Jenkins Agent，通过配置文件根据负载动态创建 Build Agent。然而，由于 Docker 镜像非常大，而且处于不同的地域，导致整个过程也效率较低。

  
  7 _% T; D0 g+ n

2 H( k8 D# [/ w

在遇到上述挑战的同时，在 CI 构建阶段，下载依赖的时候达到 5-6 个小时，这也是难以接受的，并且由于 Artifact 非常大，也会使得整个系统运行缓慢。一种解决方案就是使用 NAS 存储。但是依然存在一些新的挑战：

; R3 L8 x3 X' Q  j! `% U% ^) o8 @

• 价格昂贵。

  
  

) v! B8 E* `9 k! A

• NAS 存储虽然能在一定程度上解决问题，但是相关的设备和维护费用非常昂贵。

  
  * G/ c/ R) T" Q1 C" ^0 c

• 构建次数的限制：由于构建的自研件增长非常快，然而存储空间是相对有限的，所以，实际情况下需要限制 10 次构建。

  
  

: Z1 `+ H: [! f9 J4 h+ E! P

• 共享：共享的问题依然难以解决，尤其是跨地域的共享。

  
  

! L( |  v* l/ y8 l) Z
' c0 j: A1 Y! d, d
! a, J6 r" m6 X7 Y# [8 Z
解决方案

4 [2 j+ p7 m3 N( k+ _

' G/ q! A$ d3 ^$ N9 G- R

在对挑战进行分析之后，认为有如下两种可选的解决方案。一种是增加存储，另外一种方式是采用 Nexus，但需要高可用架构和 REST API 的支持。

这两种选择无疑都需要一个强大的 DevOps 工具。对于跨国研发团队来说，高可用是非常重要的特性，多语言的仓库也是必须的，增加存储显然难以解决根本问题。Nexus 有多语言支持，但是在高可用和 REST API 方面都需要额外的维护。在调研了众多相关产品之后，奔驰的研发团队认为 JFrog Artifactory 是非常不错的选择。

( w4 g5 X* v' L7 x$ b

JFrog Artifactory 提供了非常丰富的功能，比如统一的仓库、一致的 UI、企业级高可用支持、基于 YAML 的预定义配置、丰富的 REST API 支持以及良好的客户支持等等。Artifactory 对开源工具均可以无缝对接，尤其是 Jenkins，因此用户原有的习惯几乎不需要改变，使用之后，整个 DevOps 环境有了很显著的变化。

除此之外，Artifactory 还有诸多非常强大的特性，如 DevOps 全生命周期元数据记录、AQL(Artifactory Query Language) 查询语言、跨语言的服务正向和反向依赖解析、结合 Xray 的漏洞扫描及影响力分析等等。

6 H& O3 G4 ~/ |! f

奔驰通过 Artifactory 实现了统一的依赖管理和集中式的软件包仓库，结合其强大的正反向依赖解析，轻松解决了依赖关系不清晰的问题。Artifactory 的异地同步复制解决了软件包上传和下载的性能瓶颈问题，由于具有缓存机制，使得虽然每天的构建频率增长十倍，但是构建时间却大幅下降。在自研件存储方面，通过 Artifactory 的存储优化节省了大量存储空间，且通过自动清理机制，减少了很多管理成本，也降低了人为操作的风险。

" {; _+ _( X  n8 |. m" E

4 b" |  f' J# w

全球分布的研发中心和人员的角色变更，使得权限的管控变得异常复杂，由于 Artifactory 集中管理了所有语言的二进制包，奔驰在使用 Artifactroy 后轻松地实现了对各地研发人员的细粒度权限管控，在团队内共享也可以很方面地控制相关权限，确保始终满足最小权限模型的要求。

从数据我们可以看出，每日构建的次数增长了 10 倍，每周产生的工件也增长了 10 倍，但是存储只增加了 2 倍，存储优化十分显著。最明显的效果是 CI 构建的时间减少了 3600%，这是非常惊人的。当然，这些都是直观的效果，还有一些是潜在的收益，比如新人熟悉整个项目的时间更短了、开发的周期更短、权限控制更加准确，相应地安全性也大幅提升。

0 j6 t3 J6 Q7 {( _3 p

总结

奔驰所面临的挑战在很多企业中都存在，尤其是大型的跨国开发团队。企业级的高可用，多语言的集中式仓库，跨地域的复制分发以及强大的依赖管理功能都是必须要满足的需求，JFrog Artifactory 在奔驰的实践中提供了切实可行的解决方案，实现了 DevOps 的平稳落地，具有借鉴意义。

原创：付辉，JFrog 资深工程师，专注软件系统架构及企业 IT 转型，曾在 HPE 担任云计算技术顾问、容器架构师、DevOps 架构师等，曾服务客户中石油及中石化、摩托罗拉、阿尔卡特 - 朗讯、华为等等。擅长容器及容器编排技术，熟悉混合云架构、微服务架构、持续集成及交付、DevOps 等。长期参与开源社区开发及翻译工作。
5 j8 I5 U3 j/ ~* I- c