领英大规模工程基础架构：概述

基础架构 规模 移动 Craftsmanship

摘要：

这一系列博客文章将介绍促进领英内部数百位工程师的创新精神，帮助他们以敏捷、高质量、高效率地方式持续发布新软件所使用的工程基础架构（技术、过程、工具、文化）。这是系列文章的第一篇，将概括介绍整体架构、工作流，以及规模。

正文：

这一系列博客文章将介绍促进领英内部数百位工程师的创新精神，帮助他们以敏捷、高质量、高效率地方式持续发布新软件所使用的工程基础架构（技术、过程、工具、文化）。这是系列文章的第一篇，将概括介绍整体架构、工作流，以及规模。

如上图所示，领英针对iOS和Android开发了原生应用，以及针对移动和桌面浏览器的linkedin.com网站。这四类客户端均调用同一套共享的API前端，借此与领英的各种中间层和后端服务交换数据。四种客户端提供了高度一致且类似的用户体验和功能。

我们使用了四个主代码库（Repo），每个对应一个平台：iOS、Android、Web（移动和桌面浏览器客户端共享同一个代码库以及大部分逻辑），以及API。每个主代码库还包含十几个专门针对特定个平台开发的库（Library）代码库。四个主代码库每个包含超过5,000个文件，代码行数均超过50万行，总共有大约200个人负责提交代码。一个代码库的提交速率峰值约为每小时15次，每天60次，每周250次。我们使用了主干开发（Trunk development）的模式，即每个代码库只有一个分支，每个人的提交，以及我们的发布操作都从这一个分支进行，每天会进行多次。

代码流程大致如下图所示，每个步骤和整个流程会多次进行迭代：

1. 为重大功能制定架构设计文档，并且必须通过设计审阅。

2. 所有功能进行自动化测试，大部分功能具备Sphinx文档。功能、测试和文档均提交至同一个代码库。

3. 所有代码变更须进行代码审阅，并需要同时通过所有者ACL（访问控制列表以及每个文件的所有者）和平台ACL（访问控制列表，并通过专家确保代码完整性、一致性，以及在特定平台上的最佳实践遵循情况）进行“发布”。

4. 在预提交提交阶段，将代码正式提交至代码库之前，每次提交必须通过代码库中进行的静态分析、构建，以及自动化测试（单位/布局/场景，每个代码库共进行了约4,000次测试，且数量还在增加中）。如果预提交阶段有任何步骤失败，提交将被拒绝。同时进行的多个提交可并发执行预提交流程。

5. 一旦提交至代码库，提交的内容必须通过提交后阶段相同（甚至更严格）的一系列测试，以确保所有提交在合并后依然可以为每次提交生成高质量、可发布的构建。如果提交后测试失败，提交可能被自动恢复，或由随时待命的工程师立刻修复。如果提交后测试成功，构建将被发布至Artifactory等待发布给用户设备（iOS和Android）或部署至生产站点（Web和API）。

6. 对于iOS和Android，每次成功的构建会通过应用内置的更新功能立刻发布给Alpha渠道（移动团队）。每周会有一个iOS构建和三个Android构建通过MDM（移动设备管理）系统、应用内置的更新功能、TestFlight（iOS）或Play Store（Android）的Beta渠道发布给Beta渠道（公司员工和Beta公测用户）。如果没发现什么严重问题，每周三我们会将某一个Beta构建通过Apple的App Stora和Google的Play Store发布给生产渠道（所有领英用户）。

7. 对于Web和API，每次成功的构建会自动部署至负责运行自动化测试的EI和Staging（测试环境）。如果运行通过，该构建会自动部署至生产环境的金丝雀（Canary）设备，通过这些设备为请求提供服务，并与其他生产设备进行对比，通过各种度量值（HTTP 200/400/500返回代码、异常、Fanout、延迟等）进行统计分析，这一过程也叫做EKG。如果EKG通过，待命工程师会将其部署至生产环境，随后队列中的下一个构建将成为下一个候选部署。我们会在每个工作日的大约早9点、12点，以及下午3点进行部署。

8. 所有新功能和WIP（Work In Progress，未完工程）均可得到LiX'es（LinkedIn eXperiment）的保护，因此开发过程中只能被相应的功能团队所访问，随后将逐渐扩大至公司或公开范围，借此征集反馈并进行A/B测试，如果发现重大问题会立刻撤回。一旦全面推出，为确保代码库整洁和易于维护，还必须移除LiX'es。

我们将这种工程过程称之为“3x3”：每天发布三次，代码提交时间和最终发布给用户的时间之间不超过三小时！

作者：Ning Zhang，阅读英文原文：Engineering Infrastructure at Scale: Overview