Google 的全球生产环境架构

原视频 Google Tech Talk 的链接： https://youtu.be/dhTVVWzpc4Q

网络层

• Google Edge network，是 Google 分布全球各地的服务器网络

• Data Center 通过国际骨干网 B4 连接

• Data Center 内部使用 Jupiter 连接。Jupiter 可以把多个交换机（一般是几百个）虚拟成一个交换机。Jupiter 的带宽大约是 1.3PB/s

• 一个发给 google 的 web request 通过 edge network 之后，到达 Google frontend （GFE）。GFE 进行 reverse proxy （反向代理），将 request 发送给内部 service

• Global software load balancer （GSLB）在三个层面做 load balance

  • 地理位置层面的 load balance，比如发往 google.com 的 request
  • 针对不同产品的 load balance，比如 google maps, youtube
  • RPC load balance

所以，用户浏览 google.com 时，request 通过当地的 ISP，到达 Google edge network，到达 GFE，然后通过 GSLB 进行 load balance，然后通过Jupiter，转送到 service。整个过程的耗时在 ms 级。

Data Center

Data Center 的层级关系是：

• 一个 campus 可以有多个数据中心。campus 类似于 region 或 availability zone 的概念。图中展示的是一个 campus，包含两个 data center
• Data center 有多个 cluster。图中每个 data center 有两个 cluster ，用方形表示。
• cluster 有很多排（row）
• 每排有很多服务器机架（rack）
• 每个机架上有很多台机器 （machine）

Campus > Data center > Cluster > Row > Rack > Machine

Cluster 的管理

Cluster 需要高效地管理里面的服务器资源。 Google 内部，有 job 的概念。每个 job 有很多子 task（关于 job 和 task 的概念，可以参考之前Netflix Titus 架构 部分的内容）。job 还定义了期望使用多少资源。

工程师们使用内部软件运行 job。job 被发送给 Borg （Borg 是 Google 内部的容器管理工具，暂时未开源）。Borg master 询问 scheduler 应该由哪几台机器来运行 job。得到回应后，将请求发给指定的机器 Borglet，开始运行 job。如果job 失败，应该会被自动重新运行。

Google 使用 Borg name service （BNS）来定位服务器上的 task。格式是 /bns/<cluster>/<user>/<job name>/<task number> 。

BNS 地址需要映射到 IP:port 地址，并且保证同步。

Lock service

这个 BNS 映射到 IP 的信息，存储在另一个内部服务 Chubby 中。Chubby 是一个分布式系统中的锁服务，它下面还提供一个可以用类似 API 方式操作的文件系统，并使用 Paxos 算法来实现各个服务器之间的异步一致 （asynchronous consensus）。这个映射信息就是在 Chubby 里面。

存储系统 storage

• HDD + SSD：在存储系统的最底层，是机械硬盘和固态硬盘。
• D：意思是 disk，用来管理 HDD + SSD。D 提供的服务是存储临时数据，主要是给运行中的 job 使用。
• Colossus 是基于 google file system 开发的分布式文件系统，运行在 cluster 之内，支持永久保存数据，支持复制、加密等等。
• Bigtable 是一个NoSQL 数据库。Bigtable 可以保存有序的数据。在 cluster 之间进行复制时，bigtable 保证 eventually consistent。
• Spanner 是一个 NewSQL 数据库。旨在实现具有 NoSQL 一般可扩展性的关系型数据库。

通过 Borg， Google 将服务器集群实现的和单独一台电脑一样，可以运行 job 也可以存储数据。但是分布式系统会面临机器损坏的情况。举个例子，如果一个job 运行到一半，机器坏了，怎么办？

Monitoring

上面那个问题是通过监控的办法解决的。 Borgmon 是 Borg 的监控工具。图中， Borgmon 存在于很多层级。Borgmon 获取各个 task 的运行状态信息，然后最后向上汇总到 global borgmon。而 cluster borgmon 除了把信息汇总给 global borgmon，还发送给 google 的 time series database （时序数据库）以及 alert manager 警报系统。例如当某个 cluster 的错误率异常高的时候，会触发警报。

还有一个辅助工具 Prober ，负责给 task 所在服务器发送请求，并监控响应时间。这是从另一个角度观察服务器的健康状况。Prober 也将信息汇总给 borgmon。

Inter-task communication 任务之间的通讯

task 和其他 task 之间进行通讯使用 Stubby。Stubby 是一个 RPC（远程进程调用） 服务，基于 http，使用 protobuf 协议 。或者可以简单的说，task 之间使用 protobuf 进行 RPC。

从代码到 production

Google 以他们使用 mono repo 出名。他们的代码管理 工具 叫做 Piper（类似于 git）。到2016年为止， Piepr 管理了10亿文件，20亿行代码，9百万个源码文件，总过大约 86 TB 的数据，3500万次 commit。

当提交代码时，工程师写一份文档 changelist，会有其他工程师使用 Rietveld 做 review，项目管理者最终同意发布。提交代码到 code repo 时，系统会自动运行一个presubmit check检测。比如静态代码分析等。 检测通过后，代码进入 repo。

代码提交成功后，Blaze （Google 的 build tool，它的开源版是 Bazel ）将代码编译成二进制文件。Blaze 的使用，需要工程师指定 build 的 output 输出，dependencies 依赖等等。

另一个工具 Continuous testing，从 repo 获得最新代码后开始运行自动化测试。通过后，一个叫 Rapid 的工具会调用 Blaze 来生成 MPM （Midas Package Manager）package。MPM 给软件加上名字、版本号，以及签名以确保软件的 authenticity。最后 MPM package 被 Sisyphus 部署到 production。Sisyphus 是 google 的 deploy 工具，可以做 deploy 过程中很多复杂而又繁琐的工作。并且可以指定 deploy 的方式，比如是立即通过 canary 的方式 deploy，还是指定未来某个时刻 deploy。

总结

所以，假设说工程师开发一个功能发布到 Google 上，整个流程和期间用到的工具是：

• Piper 做代码提交， Blaze 做 build
• Rapid 编译成 MPM
• 运行： Borg，间接使用 Chubby
• 用户的请求：通过 edge, GFE, B4, GSLB, Jupiter 到达 google 里某台服务器
• task 之间通讯：Protobuf，Stubby
• Spanner 作为数据库，保存数据
• Borgmon 和 Prober 做服务器监控
• 未来发布新功能，使用 Continuous testing，Rapid，Sisyphuys

微信公众号：网站架构札记