×

扫描二维码登录本站

QQ登录

只需一步,快速开始

标签: 暂无标签


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


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



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


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



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



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



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



用户请求的处理过程


图 2-4 显示了一个用户请求的处理全过程。首先,用户使用浏览器访问 hrtps∶//shakespeare.google.com。为了获得IP地址,用户设备需要请求 DNS服务器(1)。该DNS 请求最后会到达Google的DNS服务器。Google的DNS 服务器会请求 GSLB系统。GSLB通过全局流量负载信息,决定使用哪个 IP 地址回复用户。
untitled.png
图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的可靠性举世闻名,人们经常通过访问wwwgoogle.com来验证他们的网络服务是否正常。
任务和数据的组织方式
假设压力测试的结果显示,我们的服务器可以每秒处理大概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),但是由于数据更新并不频繁,所以对我们来说这并不是问题。
我们在这一章中介绍了很多术语,在接下来的章节中还会重复引用它们,所以读者并不一定现在就将它们完全记住。






上一篇:SRE的核心工作之一:需求预测和容量规划
下一篇:SRE的基本指导思想
FYIRH

写了 198 篇文章,拥有财富 1122,被 1 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部