Large Project DevOps and CI/CD

1. 前言

这一章主要探讨一下有哪些值得关注的话题. 这里我们先不给出解答, 接下来我们再好好具体分析.

1.1 什么算是 “大型项目”

定义什么是大型项目不是三言两语就可以定义清楚的, 为了避免歧义, 我们做出一些定义, 这些定义的词在不同的公司虽然名字一样, 但是含义可能大不相同, 我们先统一一下语境:

  1. App: 一个有着明确的使用者, 和具体功能的应用.

  2. Resource: 一个 App 里会包含很多 Resource, 一部分是用于计算的, 一部分是用于存储的. 这些 Resource 往往都有版本控制, 部署时常用 immutable 的模式部署.

  3. Service: 和 Resource 是同一级的概念, 只不过 Service 是提供服务的.

  4. Project: 一个 Project 是一个大型的业务单元. 里面包含很多 App.

  5. Product: 跟编程无关, 跟商业相关的顶层概念, 也就是在你的商业模式中你的客户用的你的产品.

我们就以 Amazon.com 商店举例. Amazon.com 在线商店就是一个大型的产品. 里面包含了很多个 Project, 例如:

  • (Project) Amazon.com 在线商城网站: 主要负责给客户使用

    • (App) 网站的 Web App: 里面可能包含一个 EC2 Web 服务器集群 和许多个 AWS Lambda 微服务.

    • (App) 网站的库存管理系统

    • (App) 网站的订单处理系统

  • (Project) 在线商城的数据中台: 主要给内部使用, 包括数据

    • (App) 业务数据库, 为商城网站提供服务

    • (App) 业务数据管道, 负责将数据传输给其他的子系统

    • (App) 数据分析平台, 负责对数据进行分析: 里面可能包含对流数据进行处理的管道, 以及对批数据进行处理的 ETL Job. 我们可能有几十个这样的管道和 ETL Job.

    • (App) 数据可视化面板, 负责提供实时的关键指标

虽然我们还没有展开讲, 但是我们已经很清晰的感受到了大型项目的复杂性了. 根据企业实践经验, 通常一个无论多牛逼的技术领导, 只要他还要抓具体的架构和代码, 就很难同时管理多个 Project.

  1. 通常业内的顶级大牛的极限是管理一个 Project 这个级别的复杂度.

  2. 一个在 Google, Microsoft, Amazon, Facebook 这种级别公司能做到比 Senior 还要高 1 到 2 级的技术骨干通常是负责 App 级的项目.

  3. 而一个经验丰富的 Senior 级的优秀工程师通常是负责 App 下一个或一组 Resource 或 Service.

由于我的能力有限, 我现在是在 #2 这个档次, 不过我希望能研究一下 Project 这个级别的系统架构的问题.

1.2 部署的粒度

所谓部署的粒度就是指在一次部署的时候部署的 Resource 的数量多少, 影响范围多广. 你可以理解为一个 deploy 脚本能做的事情的 Scope. 部署的粒度没有一个标准答案. 举例来说, 假如我们有一个 Web Service 和很多个 Microservices. 一次部署是部署所有的呢? 还是只部署一个 Microservices? 总的来说我们倾向于在你觉得工作量可接受的前提下粒度尽量小, 因为反正你可以用程序将多个部署聚合成一个.

在生产实践中, 大型项目有如下特征:

  • 通常包括多个互相之间有部分独立, 又有部分互相依赖的 App (也可以称作子系统).

  • 每个 App 下

  • 有 1 + N 的部署模式