Google SRE主管：使用开源软件打造类似Google的开发和生产环境

让我们来看一下 chubby 会提供哪些在分布式环境下至关重要的服务：

• 第一、不同微服务间的同步,通过独占锁的实现,只有一个服务是能获得独占锁并更新共享的信息.
• 第二、有一些服务需要实现主从分配,多个服务用例能通过masterelection库,竞选出真正的主实例.而且从实例能自动转换成主实例,如果主实例不可用.
• 第三、是序列号这个在存储和网络中都会经常要用到.
• 第四、则是我前面提到的 BNS 服务.
• 第五、chubby 本身是一个文件系统,所以可以用于分布式的文件存储.事实上,在 Google 很多服务用 chubby 存储一些不大的配置文件,这样能实现在线的和同步的,不需要重启服务的配置更新.

2.2 自动注册的服务发现

自动服务发现使服务能够实现自动扩展,你可以随时增加服务的容量,增加或更改服务运行的数据中心,而作为 devops 则不需要上游系统做任何更改.

当一个服务用例失败的时候,RPC 传输和负载均衡中间件能自动发现并将不健康的用例自动从负载均衡的备选用例中剔除,从而实现真正的无人值守.

2.3 谷歌云平台上的负载均衡

刚才提到了在 Google 的云平台上有现成的负载均衡可供用户使用.而且用户也能通过使用第三方的软硬件来自行实现负载均衡.

2.4 Protobuf

不得不提到的是 Google 开源的 Protobuf 库提供给不同的语言开发者一个统一的通讯协议,服务定义和存储格式.

Protobuf 重要特性是向后兼容性,比如说应用在08书写的 Protobuf 格式的日志,在2017年能够继续被使用和分析,即使是 Protocol buffers 已经被更新很多次.

在接口描述语言和消息格式里面,你可以任意添加新的阈值而不影响服务的向后兼容性.这一点在大规模微服务实现中非常重要.

当你的服务用例数足够大,你则不可能在不影响服务质量的前提下,同时更新所有的服务用例.所以前端和后端必须保证向后兼容的特性,否则在升级过程中会造成数据的丢失或损坏.

在大型的开发团队里,更要求前端和后端能独立开发,独立部署,独立测试,而 Protobuf 的向后兼容的特性,恰恰是这样的开发部署模式成为了可能.

Protobuf 还提供跨平台和语言的兼容性,所以 node.js 的前端能很自然的使用 Protobuf 与 C++ 的后端通信.

更值得一提的是,恰恰是 Protobuf 的这种特性像 Google 这样使用一个单一代码库的公司能在内部部署成千上万的相互依赖的松耦合的微服务.

3、使用Google service(C++)的核心类库

接下来我想谈谈我在作为一个软件开发者的一些体会,SRE 是 Dev＋Ops 的合体,所以参与开发也是 SRE 日常工作的一个重要组成部分.

众所周知 Google 广泛的使用各种开源软件打造它的平台,而作为开发者 Google 也向开源社区回馈了很多内部使用的工具的类库.

我将举例几个跟 SRE 相关比较紧密的库逐一讲解,我选择了 C++ 的版本因为我主要从事 C++ 的开发所以比较熟悉.

这些类库大多也都有其他语言的实现,值得一提的这些库基本上被所有的 Google 内部服务调用.

3.1 命令行库—gflags

首先提到的是 Google 的命令行库叫 gflags.在 Google 几乎所有的服务参数和特性都可以通过命令行参数来调教和更改.在很多时候新的服务特性往往是通过命令行参数来启用或者禁用.

举个例子,如果在某次的部署当中新的服务实现了 A,B,C 三种新功能,但是通过部署测试发现 B 功能不能正常工作,这是SRE往往采用命令行参数来禁用b功能,从而使 A,C 功能能及时的发布.

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!