Google SRE主管:使用开源软件打造类似Google的开发和生产环境(2)
让我们来看一下 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 功能能及时的发布. 在第二个例子当中,SRE 经常会通过命令行参数来更改服务的特性而不需要重新编译和打包.很多时候程序的配置被写在命令行里,这样只要更改命令行就能服务实现不同的功能.例如你能配置一个服务使用英文而另一个服务使用中文而不需要重新打包. gflag 定义 flag 为全局变量,你可以用 DEFINE flag 去在任何文件里定义命令行标志,在其他文件中通过 DELCLARE_flag 来实现调用.使用 gflag 你将摆脱手动分析 args,能使程序更加简洁易读. 3.2 日志服务—glog库第二个提到的是 Google 的 glog 库,实现了程序中标准的日志服务. glog 定义了不同的日志类型,而开发者可以通过 LOG 类型来简单的实现将不同的日志存储在不同文件中的目的. glog 提供了 CHECK 宏,能帮助程序检测一些不可恢复的错误并终止程序.在这个例子中如果写失败将终止程序并将 stacktrace 输出到日志中方便 SRE 和 DEV 来 debug. glog还提供详细日志服务,详细日志通过命令行参数来控制.通过 vmodule 和 v 两个参数可以控制不同的模块产生不同的日志. glog 还提供系统信号处理,在程序被系统信号终止的时候,他能自动生成出错点的 stacktrace 方便 SRE 和 dev 来 debug. glog可以和其他的日志管理程序一起实现日志的重定向等服务. 3.3 单元测试库—Google test(编辑:ASP站长网) |