请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 324|回复: 0

莎士比亚搜索∶SRE负责的一个示范服务

[复制链接]
发表于 2020-11-25 22:42:24 | 显示全部楼层 |阅读模式
. Y; U$ Q; d  r; d0 Y

. J- P; t' ?2 e/ ]7 v& X' \- N2 B- R
为了更好地说明一个服务是怎样利用各种基础设施,以及是如何在 Google生产环境中部署的,我们在这里提供一个假想的莎士比亚搜索服务。这个服务的作用是在所有莎士比亚的文献中搜索给定的词语。  z9 [8 o3 R4 h  _, z2 {1 i) z
整个系统可以分为两大部分∶

( g/ ~) G- J2 P" c0 S% i

% D, x9 k! S2 G6 V
  • 批处理部分(batch)。给全部莎士比亚文献创建索引,同时将索引写入一个

    % h; I  t- u" ?8 D
& J+ f1 {9 @- _+ I2 j* V! @; Y1 Y
6 T: F7 l" t5 \
Bigtable中。这项任务只需运行一次(如果发现了新的莎士比亚文献,那就需要再运行一次。)
& u# t0 q% q; _, O/ n  g7 ?+ @

9 @, a" f9 C) S$ S% N: ~
  • 一个应用程序前端服务器(frontend),用以接收处理用户请求。该服务器是一直运行的,因为全球范围的用户都需要使用我们的服务。
    ) v  `; s* W6 W: s' l  s7 t

. V. ^0 t4 j" F% ^
2 z- T. x+ g, L# M3 R
批处理部分可以用 MapReduce 框架完成,三个阶段的实现分别如下所示。

% Y1 q7 J! M* z: k% [8 [, ^. Z
) c& M: Y$ m: B, G
* _% o0 G2 C. ?, O
  • Mapping 阶段∶该程序遍历所有的莎士比亚的文字,将其分成具体的单词。这项任务可以利用多实例并行加速。
  • Shufle 阶段∶该程序将上一阶段产生的所有单词和位置等进行排序。
  • Reduce 阶段∶将上一阶段产生的单词或位置等按单词合并,产生一个新的单词或位置列表。

    3 m- g2 J3 I; D1 [7 R- b

# l# q: l2 ?) v( M6 H! f6 f; W
. _( i% Z$ `% Z9 {
最后,程序将每一个单词或位置列表写入 Bigtable 中,Row Key 就是这个单词。
, u/ _; t: J2 v" U8 H, r4 i
4 y  D, V; s2 R- k  N

2 }# J4 C' k' {( W8 P( j
用户请求的处理过程
9 o  v2 B/ y. E! w

/ g$ |5 ?2 w1 N% H6 N
图 2-4 显示了一个用户请求的处理全过程。首先,用户使用浏览器访问 hrtps∶//shakespeare.google.com。为了获得IP地址,用户设备需要请求 DNS服务器(1)。该DNS 请求最后会到达Google的DNS服务器。Google的DNS 服务器会请求 GSLB系统。GSLB通过全局流量负载信息,决定使用哪个 IP 地址回复用户。
untitled.png
1 G% ]0 i4 ?" e1 P' O% i! E
图2-4∶ 用户请求处理过程
7 N7 m1 h( J5 R2 X6 H: @4 M用户浏览器利用获得的IP地址连接到HTTP服务器,这个服务器(Google前端服务器GFE)负责终结TCP连接,并且反向代理请求到真正的服务器上(2)。GFE 从配置文件中找到该请求对应的后端服务(配置文件中包括所有的 Google服务,例如Web Search、maps以及本例中的 Shakespeare)。GFE再次咨询GSLB系统,获得一个GSLB分配的、目前可用的 Shakespeare 服务器地址,向其发送一个RPC 请求(3)。
0 e% O2 X  K7 ~9 a  S6 K1 jShakespeare前端服务器分析接收到的请求,构建出一个具体查询的 Protobuf 请求。这时 Shakespeare前端服务器需要联系后端服务器来做具体查询。前端服务器也需要联系GSLB服务,获取目前可用的(同时符合负载均衡条件的)后端服务器的 BNS 地址(4)。Shakespeare 后端服务器随后请求 Bigtable服务器来获得最终查询结果(5)。* k! N, A" W! _, h/ i! G, d- z
最终结果被写入一个Protobuf 结构体中,返回给 Shakespeare后端服务器,后端服务器将其回复给 Shakespeare 前端服务器,前端服务器最终根据这个数据结构构建HTML回复给最终用户。
) I! Y3 `  V: i4 W" F& w上述这些连锁事件其实一共耗时几百毫秒。因为一个请求涉及很多组件,这些组件都必须相当可靠才行,GSLB 服务如果出现问题将会造成严重故障。但是 Google 依靠严格的测试和灰度发布流程,以及很多主动优雅降级的措施,使得我们可以为用户提供一个非常稳定的服务。由于Google的可靠性举世闻名,人们经常通过访问wwwgoogle.com来验证他们的网络服务是否正常。
7 ~% ?5 u: _$ ]2 m- g9 s任务和数据的组织方式5 u3 u3 m6 o9 M  Y) ?
假设压力测试的结果显示,我们的服务器可以每秒处理大概100个请求(100QPS)。通过对用户进行的调查显示,我们预计峰值流量会达到3470QPS,为了处理这些流量,至少需要 35 个任务实例。 但是,由于以下几点考量,我们最终决定至少采用37个实例,也就是 N+2模式∶
* S0 q! d$ P4 C
● 在更新过程中,有一个任务实例将会短暂不可用,只有36 个实例可提供服务。
! t3 s8 h& ~8 n8 T$ Q
● 如果另外一个物理服务器同时也出现问题,那么另外一个任务实例也受到影响,只剩 35 个实例可以对外服务,刚好可以满足峰值要求。
) @( T+ i: k6 _* ~7 t
, t! W; }0 E5 c& C假设,对用户流量的进一步观察显示我们的峰值流量其实是来自全球的。北美洲1430 QPS,南美洲 290 QPS,欧洲和非洲 1400 QPS,亚洲及澳大利亚共350 QPS。为了更好地服务用户,我们需要将服务分别部署在美国、南美洲、欧洲和亚洲。在南美洲,我们选择使用只部署4个实例(而不是5个),将冗余度降低为N+1。这样做的原因是,我们选择在极端情况下牺牲一些用户体验以降低成本。因为当容量不足时,GSLB会将南美洲的用户流量导向其他可用的数据中心,可以节省大概 20%的硬件资源。在有条件的地方,我们还会将任务实例分散在不同的集群中,以便更好地提升可靠性。 因为 Shakespeare 后端服务器需要连接 Bigtable服务读取数据,我们同时也需要合理地安排数据存储。亚洲的后端服务器尝试访问部署在美国的Bigtable会面临延迟问题。所以我们在每个地理区域都存放了 Bigtable 的副本。& }) d0 G" |7 ~& s% q
利用 Bigtable 的复制功能,我们可以同时达到两个目的∶
& y  A. f+ z/ \- F7 [
● 当 Bigtable 服务出现问题时,可以利用副本提供服务。: f5 o- r& ?9 v* a" ?' o; b
● 任务实例可以利用本地 Bigtable 加速数据访问。+ }6 ]7 @7 l1 z0 l6 ]6 u7 s
虽然 Bigtable仅仅提供最终一致性保障(eventual consistency),但是由于数据更新并不频繁,所以对我们来说这并不是问题。
6 }- `* J4 a$ c" {$ [我们在这一章中介绍了很多术语,在接下来的章节中还会重复引用它们,所以读者并不一定现在就将它们完全记住。7 h% F0 T( c3 p4 r# a5 ~

# J+ `6 Y1 K7 p6 }' |+ Z

5 j$ {6 {8 X1 T3 \




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

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-25 09:57 , Processed in 0.156723 second(s), 33 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表