2.SRE：Google运维解密 --- Google 生产环境：SRE 视角

1.硬件
	物理服务器：代表具体的硬件
	软件服务器：代表一个对外提供服务的软件系统

	1.10台物理机组成一个机柜
	2.数台机柜组成一个机柜排
	3.一排或者多排组成了一个集群
	4.一个数据中心包含多个集群
	5.多个相邻的数据中心组成了一个园区

	物理服务器的系统管理软件:
		1.管理物理服务器
		  google Borg (下一代，Kubernetes)
		  Apache Mesos

		  Borg 负责运行用户提交的任务。该任务是可以无限运行的软件服务器，或者是批量任务。每个任务可以由一个或多个实例(task)
		组成(有时候由几千个实例组成)。通常这样组织是为了提高冗余度。当 Borg 启动一个任务的时候，它会为每一个实例安排一台物理
		服务器，并且执行具体程序的时候启动它。Borg 同时会不断地监控这些实例，如果发现某个实例出现异常，会终止该实例，并重启它。
		有时候会在另外一个服务器上重启。
		  因为任务实例与机器并没有一对一的固定关系，所以我们不能简单的用ip地址和端口来指代某一个具体任务实例。为了解决这个问题，
		我们加了一个抽象层。每个 Borg 启动某一个任务的时候，它会给每个具体的任务实例分配一个名字和一个编号，这个系统成为 Borg
		名字解析系统(BNS)。当其他任务实例连接到某个任务实例的时候，使用 BNS 名字建立连接，BNS 系统负责将这个名字转换成具体IP
		地址和端口进行连接。举例，一个BNS地址可能是这样一个字符串 : /bns/<集群名>/<用户名>/<任务名>/<实例名>，这个 BNS 地址
		最终将解析为 IP地址:端口。
		  Borg 还负责将具体资源分配给每个任务。每个任务都需要在配置文件中声明它需要的具体资源(如，3CPU核心，2GB内存等)。有了
		这样的信息，Borg 可以将所有的任务实例合理分配在不同的物理服务器上，以提高每个物理服务器的利用率。同时Borg还关注物理
		物理服务器的故障域属性(failure domain)属性。例如，Borg 不会将某个任务的全部实例都运行在某一个机柜上。因为这样一来，
		机柜交换器将成为整个任务的单点故障源。
		  如果一个任务实例资源使用超出了它的分配范围，Borg 会杀掉这个实例，并且重启它。

	   2.存储
	   	存储系统由多层结构组成：
	   		1.最底层由称为D的服务提供(Disk)
	   			D是一个文件服务器，几乎运行在整个集群的所有物理服务器上，用户访问数据的时候并不需要记住具体到某个服务器上去获取。
	   		2.D服务的上一层被称之为 Colossus, Colossus 建立了一个覆盖整个集群的文件系统。Colossus 文件系统提供传统文件系统的
	   		操作接口。Colossus 是 GFS的改进版本。
	   		3.构建于 Colossus 之上，有几个类似数据库的服务可供选择：
	   			1.Bigtable 是一个 nosql 数据库，可以处理PB的数据。Bigtable 是一个松散存储的，分布式的，有顺序的，持久化的多维
	   			  映射表。它使用 Row Key,Column Key 以及时间戳做索引。映射表中的值是按原始字节存储的。Bigtable 支持 '最终一致性'
	   			  的跨数据中心复制模型。
	   			2.Spanner 是可以提供 SQL 接口以及满足一致性要求的全球数据库
	   			3.另外几个数据库系统，例如 Blobstore 也可用。

	   	3.网络
	   		基于 OpenFlow 协议的软件定义网络(SDN)。网络带宽也需要合理分配，带宽控制器(BwE)负责管理所有可用带宽，不仅仅是降低成本，还可以
	   	  解决以前在分布式路由模式下难以解决的流量迁移问题。
	   	    有些服务包括运行在不同集群上的任务，这些集群通常是遍布全球的。为了降低分布式集群的服务延迟，我们希望能够将用户指派给距离最近的，
	   	  有空余容量的数据中心处理。我们的全球负载均衡系统(GSLB)在3个层面上负责负载均衡工作。
	   	  1.利用地理位置信息进行负载均衡DNS请求。
	   	  2.在用户服务层面进行负载均衡。
	   	  3.在远程调用(RPC)层面进行负载均衡。
	   	    每个服务的管理者在配置文件中给服务起一个名字，同时指定一系列的BNS地址，以及每个BNS地址可用的容量(通常，容量的单位是QPS，每秒请求
	   	  数量)。GSLB 会自动将用户流量导向合适的位置。

	   	4.分布式锁服务
	   		Chubby集群锁服务提供一个与文件系统类似的API来操作锁。Chubby 可以处理异地，跨机房级别的锁请求。Chubby 使用 Paxos 协议来提供分布式
	   	  一致性。
	   	    Chubby 是实现主实例选举(Master-Election) 过程的关键组件。

	   	5.监控与报警系统
	   		Borgmon 

	   	6.软件基础设施
	   		google 的底层软件基础设施的设计目标是最高效的使用google的硬件基础设施。代码库大量使用了多线程设计 方式，一个任务实例可以同时利用很多
	   	  cpu。
	   	    所有的 google 服务之前都使用远程调用(RPC)通信，称为Stubby，开源实现为 gRPC。
	   	    Protocol Buffer 是 Google RPC 的传输格式，与 Apache Thrift 类似。比 XML 有很多优势，更为简单易用，数据大小比 XML格式要小3~10倍，
	   	  序列化和反序列化速度要快100倍，并且协议更加明确。

	   	7.研发环境
	   		google 软件工程师全部使用同一个共享软件仓库开发。

2.莎士比亚搜索：一个示范服务
	提供一个假想的莎士比亚搜索服务：
		1.批处理：给莎士比亚文献创建索引，同时将索引写入 Bigtable 中。(只处理一次，除非发现新的文献)
		2.一个应用程序前端服务器(frontend)，接收用户请求。该服务一直运行。

	批处理部分可以用 MapReduce 框架完成, 3个阶段实现分别如下：
	1.Mapping 阶段 
		遍历所有的文字，将其分成具体的单词。可以利用多实例并行加速。

	2.Shuffle 阶段
		该程序将上一阶段产生的所有单词和位置进行排序。

	3.Reduce 阶段
		将上一阶段产生的单词或位置等按单词合并，产生一个新的单词或位置列表。


3.用户请求过程
	1.用户访问 https://shakespeeare.google.com，为了获得ip，用户设备需要请求 DNS 服务器。该 DNS 请求最后会到达 google 的 
	  DNS 服务器。google 的 DNS 服务器会请求 GSLB 系统。GSLB 通过全局流量负载信息，决定使用哪个 ip 地址回复用户。
	2.用户浏览器利用获得的 ip 地址链接到 http 服务器，这个服务器(google 的前端服务器)负责终结tcp链接，并且反向代理到真正的服务器。
	  GFE 从配置文件中找到该请求对应的后代服务(配置文件中包括所有的google服务，例如 web search,maps ...)。GFE再次咨询GSLB系统，
	  获得一个 GSLB 分配的，目前可用的 Shakespeare 服务器地址，向其发送一个 RPC 请求。
	3.Shakespeare 前端服务器分析接收到的请求，构建出一个具体查询的 Protobuf 请求，这时 Shakespeare 前端服务器需要联系后端服务器来
	  做具体查询。前端服务器也需要联系GSLB服务，获取目前可用的(同时符合负载均衡条件的)后端服务器的BNS地址。
	4.Shakespeare 后端服务器随后请求 Bigtable 服务器来获取最终查询结果。最终结果被写入一个 Protobuf 结构体中，返回给 Shakespeare 
	  后端服务器，后端服务器将其回复给 Shakespeare 前端服务器，前端服务器最终根据这个数据结构构件 html 回复给用户。