为了更好地说明一个服务是怎样利用各种基础设施，以及是如何在 Google生产环境中部署的，我们在这里提供一个假想的莎士比亚搜索服务。这个服务的作用是在所有莎士比亚的文献中搜索给定的词语。
整个系统可以分为两大部分∶

• 批处理部分（batch）。给全部莎士比亚文献创建索引，同时将索引写入一个
  
  

Bigtable中。这项任务只需运行一次（如果发现了新的莎士比亚文献，那就需要再运行一次。）

• 一个应用程序前端服务器（frontend），用以接收处理用户请求。该服务器是一直运行的，因为全球范围的用户都需要使用我们的服务。
  
  

批处理部分可以用 MapReduce 框架完成，三个阶段的实现分别如下所示。

• Mapping 阶段∶该程序遍历所有的莎士比亚的文字，将其分成具体的单词。这项任务可以利用多实例并行加速。
• Shufle 阶段∶该程序将上一阶段产生的所有单词和位置等进行排序。
• Reduce 阶段∶将上一阶段产生的单词或位置等按单词合并，产生一个新的单词或位置列表。
  
  

最后，程序将每一个单词或位置列表写入 Bigtable 中，Row Key 就是这个单词。

用户请求的处理过程

图 2-4 显示了一个用户请求的处理全过程。首先，用户使用浏览器访问 hrtps∶//shakespeare. 。为了获得IP地址，用户设备需要请求 DNS服务器（1）。该DNS 请求最后会到达Google的DNS服务器。Google的DNS 服务器会请求 GSLB系统。GSLB通过全局流量负载信息，决定使用哪个 IP 地址回复用户。

图2-4∶ 用户请求处理过程
用户浏览器利用获得的IP地址连接到HTTP服务器，这个服务器（Google前端服务器GFE）负责终结TCP连接，并且反向代理请求到真正的服务器上（2）。GFE 从配置文件中找到该请求对应的后端服务（配置文件中包括所有的 Google服务，例如Web Search、maps以及本例中的 Shakespeare）。GFE再次咨询GSLB系统，获得一个GSLB分配的、目前可用的 Shakespeare 服务器地址，向其发送一个RPC 请求（3）。
Shakespeare前端服务器分析接收到的请求，构建出一个具体查询的 Protobuf 请求。这时 Shakespeare前端服务器需要联系后端服务器来做具体查询。前端服务器也需要联系GSLB服务，获取目前可用的（同时符合负载均衡条件的）后端服务器的 BNS 地址（4）。Shakespeare 后端服务器随后请求 Bigtable服务器来获得最终查询结果（5）。
最终结果被写入一个Protobuf 结构体中，返回给 Shakespeare后端服务器，后端服务器将其回复给 Shakespeare 前端服务器，前端服务器最终根据这个数据结构构建HTML回复给最终用户。
上述这些连锁事件其实一共耗时几百毫秒。因为一个请求涉及很多组件，这些组件都必须相当可靠才行，GSLB 服务如果出现问题将会造成严重故障。但是 Google 依靠严格的测试和灰度发布流程，以及很多主动优雅降级的措施，使得我们可以为用户提供一个非常稳定的服务。由于Google的可靠性举世闻名，人们经常通过访问www 来验证他们的网络服务是否正常。
任务和数据的组织方式
假设压力测试的结果显示，我们的服务器可以每秒处理大概100个请求（100QPS）。通过对用户进行的调查显示，我们预计峰值流量会达到3470QPS，为了处理这些流量，至少需要 35 个任务实例。 但是，由于以下几点考量，我们最终决定至少采用37个实例，也就是 N+2模式∶
● 在更新过程中，有一个任务实例将会短暂不可用，只有36 个实例可提供服务。
● 如果另外一个物理服务器同时也出现问题，那么另外一个任务实例也受到影响，只剩 35 个实例可以对外服务，刚好可以满足峰值要求。

假设，对用户流量的进一步观察显示我们的峰值流量其实是来自全球的。北美洲1430 QPS，南美洲 290 QPS，欧洲和非洲 1400 QPS，亚洲及澳大利亚共350 QPS。为了更好地服务用户，我们需要将服务分别部署在美国、南美洲、欧洲和亚洲。在南美洲，我们选择使用只部署4个实例（而不是5个），将冗余度降低为N+1。这样做的原因是，我们选择在极端情况下牺牲一些用户体验以降低成本。因为当容量不足时，GSLB会将南美洲的用户流量导向其他可用的数据中心，可以节省大概 20%的硬件资源。在有条件的地方，我们还会将任务实例分散在不同的集群中，以便更好地提升可靠性。 因为 Shakespeare 后端服务器需要连接 Bigtable服务读取数据，我们同时也需要合理地安排数据存储。亚洲的后端服务器尝试访问部署在美国的Bigtable会面临延迟问题。所以我们在每个地理区域都存放了 Bigtable 的副本。
利用 Bigtable 的复制功能，我们可以同时达到两个目的∶
● 当 Bigtable 服务出现问题时，可以利用副本提供服务。
● 任务实例可以利用本地 Bigtable 加速数据访问。
虽然 Bigtable仅仅提供最终一致性保障（eventual consistency），但是由于数据更新并不频繁，所以对我们来说这并不是问题。
我们在这一章中介绍了很多术语，在接下来的章节中还会重复引用它们，所以读者并不一定现在就将它们完全记住。

为了更好地说明一个服务是怎样利用各种基础设施，以及是如何在 Google生产环境中部署的，我们在这里提供一个假想的莎士比亚搜索服务。这个服务的作用是在所有莎士比亚的文献中搜索给定的词语。
整个系统可以分为两大部分∶

• 批处理部分（batch）。给全部莎士比亚文献创建索引，同时将索引写入一个
  
  

Bigtable中。这项任务只需运行一次（如果发现了新的莎士比亚文献，那就需要再运行一次。）

• 一个应用程序前端服务器（frontend），用以接收处理用户请求。该服务器是一直运行的，因为全球范围的用户都需要使用我们的服务。
  
  

批处理部分可以用 MapReduce 框架完成，三个阶段的实现分别如下所示。

• Mapping 阶段∶该程序遍历所有的莎士比亚的文字，将其分成具体的单词。这项任务可以利用多实例并行加速。
• Shufle 阶段∶该程序将上一阶段产生的所有单词和位置等进行排序。
• Reduce 阶段∶将上一阶段产生的单词或位置等按单词合并，产生一个新的单词或位置列表。
  
  

最后，程序将每一个单词或位置列表写入 Bigtable 中，Row Key 就是这个单词。

用户请求的处理过程

图 2-4 显示了一个用户请求的处理全过程。首先，用户使用浏览器访问 hrtps∶//shakespeare. 。为了获得IP地址，用户设备需要请求 DNS服务器（1）。该DNS 请求最后会到达Google的DNS服务器。Google的DNS 服务器会请求 GSLB系统。GSLB通过全局流量负载信息，决定使用哪个 IP 地址回复用户。

图2-4∶ 用户请求处理过程
用户浏览器利用获得的IP地址连接到HTTP服务器，这个服务器（Google前端服务器GFE）负责终结TCP连接，并且反向代理请求到真正的服务器上（2）。GFE 从配置文件中找到该请求对应的后端服务（配置文件中包括所有的 Google服务，例如Web Search、maps以及本例中的 Shakespeare）。GFE再次咨询GSLB系统，获得一个GSLB分配的、目前可用的 Shakespeare 服务器地址，向其发送一个RPC 请求（3）。
Shakespeare前端服务器分析接收到的请求，构建出一个具体查询的 Protobuf 请求。这时 Shakespeare前端服务器需要联系后端服务器来做具体查询。前端服务器也需要联系GSLB服务，获取目前可用的（同时符合负载均衡条件的）后端服务器的 BNS 地址（4）。Shakespeare 后端服务器随后请求 Bigtable服务器来获得最终查询结果（5）。
最终结果被写入一个Protobuf 结构体中，返回给 Shakespeare后端服务器，后端服务器将其回复给 Shakespeare 前端服务器，前端服务器最终根据这个数据结构构建HTML回复给最终用户。
上述这些连锁事件其实一共耗时几百毫秒。因为一个请求涉及很多组件，这些组件都必须相当可靠才行，GSLB 服务如果出现问题将会造成严重故障。但是 Google 依靠严格的测试和灰度发布流程，以及很多主动优雅降级的措施，使得我们可以为用户提供一个非常稳定的服务。由于Google的可靠性举世闻名，人们经常通过访问www 来验证他们的网络服务是否正常。
任务和数据的组织方式
假设压力测试的结果显示，我们的服务器可以每秒处理大概100个请求（100QPS）。通过对用户进行的调查显示，我们预计峰值流量会达到3470QPS，为了处理这些流量，至少需要 35 个任务实例。 但是，由于以下几点考量，我们最终决定至少采用37个实例，也就是 N+2模式∶
● 在更新过程中，有一个任务实例将会短暂不可用，只有36 个实例可提供服务。
● 如果另外一个物理服务器同时也出现问题，那么另外一个任务实例也受到影响，只剩 35 个实例可以对外服务，刚好可以满足峰值要求。

假设，对用户流量的进一步观察显示我们的峰值流量其实是来自全球的。北美洲1430 QPS，南美洲 290 QPS，欧洲和非洲 1400 QPS，亚洲及澳大利亚共350 QPS。为了更好地服务用户，我们需要将服务分别部署在美国、南美洲、欧洲和亚洲。在南美洲，我们选择使用只部署4个实例（而不是5个），将冗余度降低为N+1。这样做的原因是，我们选择在极端情况下牺牲一些用户体验以降低成本。因为当容量不足时，GSLB会将南美洲的用户流量导向其他可用的数据中心，可以节省大概 20%的硬件资源。在有条件的地方，我们还会将任务实例分散在不同的集群中，以便更好地提升可靠性。 因为 Shakespeare 后端服务器需要连接 Bigtable服务读取数据，我们同时也需要合理地安排数据存储。亚洲的后端服务器尝试访问部署在美国的Bigtable会面临延迟问题。所以我们在每个地理区域都存放了 Bigtable 的副本。
利用 Bigtable 的复制功能，我们可以同时达到两个目的∶
● 当 Bigtable 服务出现问题时，可以利用副本提供服务。
● 任务实例可以利用本地 Bigtable 加速数据访问。
虽然 Bigtable仅仅提供最终一致性保障（eventual consistency），但是由于数据更新并不频繁，所以对我们来说这并不是问题。
我们在这一章中介绍了很多术语，在接下来的章节中还会重复引用它们，所以读者并不一定现在就将它们完全记住。