首页>会议文档 >

Minghua Ye-使用开源软件打造类似Google的开发和生产环境

page:
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境
Minghua Ye-使用开源软件打造类似Google的开发和生产环境

Minghua Ye-使用开源软件打造类似Google的开发和生产环境

所属会议:GOPS 2016全球运维大会 上海站会议地点:上海


下载

手机看
活动家APP客户端

扫二维码下载
或点击下载
Android iOS

10460次
浏览次数
GOPS 2016全球运维大会 上海站所有文档 GoogleSRE孙宇聪-分布式共识系统在高可用架构中的应用 腾讯 周小军-大规模Web Server集群的高效运维 存储及数据中心行业分析师张广彬-你以为你以为的超融合就是超融合? 迅达云成李孟-CDN、DNS的部署与优化 360 李洪亮-360网络运维自动化演进之路 携程 陈剑明-携程基于应用的自动化容量管理与评估 京东商城韩建飞-多快好省运营大规模弹性云集群 ZStack张鑫-为什么说IaaS不是容器的未来 IBM 刘光亚-BlueDock –行业容器混合云管理平台详解 阿里云 李斌-CaaS在微服务开发运维中的最佳实践 《PaaS实现与运维管理》作者余何-沉默的大多数——中小企业IT运维的互联网之路 UnixHot运维社区创始人赵舜东-中小企业运维与自动化运维实践 首都在线周东波-运维背后的逻辑 B站 devops梁晓聪-B站运维系统从无到有的演进之路 中交兴路车联网许颖维-中小企业如何优雅地管理多机房服务器账号 数人云肖德时-基于Mesos打造高可用微服务系统实践 YY 互娱 刘亚丹-基于DevOps理念的私有PaaS运维平台实践 跟谁学资深运维专家郭宏泽-Devops传统企业中的生产实践 携程旅行网沈强-呼叫中心座席接入异地双活技术实现 美国道富银行 李卓-用户导向的全球研发团队运维转型之路 蓝鲸 党受辉-如何从零打造百人级别的DevOps团队 优维科技 王津银-运维,为DevOps持续交付而生 金山云赵帅-Docker在devops中的应用 Oracle, InnoDB团队Principle Software Developer赖铮-MySQL 5-7中的InnoDB的新特性及亮点 唯品会 师陈群-唯品会大规模Redis集群存储架构演进 涂彦-从0到300,腾讯游戏运维团队成长解密 北京蓝海 科黎卫-运维管理的场景化思维 阿里云周正中-PostgreSQL内核优化及生产实践那些事 微信事业群- 技术架构部周汤-微信支付数据库管理实践 阿里巴巴 范伦挺-阿里大数据计算平台运维实践 文太友-DNS运维之路 eBay Cloud Services 李健-eBay Hadoop 海量集群自动化运维实践 西山居 尹会生-大数据时代运维的机遇与挑战 中国太平洋保险集团胡罡-建设金融服务云,开启服务新模式 恒丰银行 潘文杰-Openstack在恒丰银行的生产实践 擎创信息屈中冷-见微知著 - 海量运维数据分析的价值 中国银联 鲁逸丁-中国银联云运维平台:产品、场景与技术 中国人寿 桂林-中国人寿自主研发自动化运维平台成功要素 苏州研发中心徐军-中国移动DCOS平台研发与运维实践经验总结 OStorage 李明宇-OpenStack Swift对象存储在SSD上的优化 百度 总监杨一-Openstack在百度开放云的系统改进 网易 黄文宇-云时代下游戏运维 孙杰-传统大型企业的云技术转型实践与思考 盛大 胥峰-盛大游戏万台服务器自动化运维实战 蘑菇街 赵成-从0到1:蘑菇街运维技术管理体系建设分享 优云软件蒋君伟-CMDB+自动化的管理融合 大众点评 张冠宇-亿级别PV的大型互联网公司运维架构演变 百度 张乐-持续交付:高效率和高质量可以兼得 UnitedStack有云许长豹-OpenStack-运维可视化 韩晓光-传统运维 VS 互联网运维 从哪来到哪去 太平洋保险杜颖君-传统保险企业运维平台化探索之路 腾讯 梁定安-夯实海量运营质量的三个运维实践经验 Ucloud 许杨毅-IaaS平台运营的数据之魅 《海量运维、运营规划之道》作者唐文-海量运维与运营规划之道2-0 京东 范超-从618京东大促看电商业务运维 上海交通大学 刘骋昺-爱奇艺Hadoop平台的运维管理实践 蓝鲸 党受辉-我们的承诺,你们的蓝鲸 听云廖雄杰-运筹帷幄--追溯应用性能问题的根源 Google SRE孙宇聪-SRE:Google运维揭密 Chris-如何制定服务的SLO Twitter 郭斯杰-Twitter千亿级消息中间件的DevOps实践与经验 大河云联 庞俊英-网络运维的昨天、今天和明天 腾讯 刘昕-移动端用户体验优化:一秒钟法则及实践 华为 张丹-大型实时对战手游的移动网络用户体验优化 云智慧高驰涛-详解APM数据采样与端到端 杭州数云罗兴峰-APM应用与整合分享 携程 刘以初-后微软时代 高效运维发起人萧田国-重新定义运维:我们的下一站 金山企业信息化专家万勇-破局灯下黑 Akamai中国祝一格-利用CDN简化Web运维和实时可视能力 凤凰网,原IT总监王建新-大型互联网公司和创业公司内部IT运维分析 携程网 雷兵-传统企业网络安全运维的转型与变革 绿盟科技候奎宇-互联网+下的安全服务实践 上海豌豆 李睿-CTF赛之攻防对抗的艺术 找钢网 卞军军-B2B创业型企业的安全运营与驱动 平安科技 刘瑞恺-微信公众号的自动化安全监

文档介绍

Minghua Ye-使用开源软件打造类似Google的开发和生产环境

演讲实录

前言

如果大家对 App Engine 还不熟悉的话,简单来说 App Engine 就是 Google 提供的 paas,一个开发、托管网络应用程序的平台,使用户的程序能在 Google 的数据中心运行。


作者在本文中分析他在 Google 的一些经验,鉴于作者的 App Engine 背景。本文很多话题里都涉及跟 App Engine 相关的应用。


1、云平台至关重要的可扩展性




当7年前,我刚刚开始在 App Engine 的 SRE 生涯的时候,App Engine 还是在 Google 内部一个很渺小的服务,活跃用户,流量都远远不能和 Google Search 这样的巨无霸相提并论。


而在短短的7年时间 App Engine 实现的指数型的增长,现如今已经成为了 Google 云平台的重要组成部分。


应用程序开发者在 App Engine 上部署了上千万的应用。在其中不乏一些很重要的客户和很有趣的用例。


上图里我提及到的这些应用开发者们都在它们的网站公开描述了它们在 AE 上的实现。大家如果有兴趣做深入的案例研究可以直接搜索相关的关键字。


值得一提的是威廉王子和凯瑟琳王妃在2011的大婚,皇室选择了 Google 的云计算平台作为婚礼网站和婚礼实时直播平台的提供者。而作为运维小组的 SRE 也得到了皇室的感谢。


在短短的几天之内,网站接受了 15m 的访问和超过 42000QPS 的峰值流量。他们之所以选择 AE,最重要的原因是看中了 AE 系统的自动可扩展性。


网站开发者仅仅部署了网站的源代码,而后台容量的自动扩展和流量的自动均衡都由 AE 系统自动完成,而不需要开发者或者 SRE 的任何干预。


另外一个很重要的客户是 Workivia,Workivia 向全球500强公司提供财务报表的提交服务。众所周知,财务报表的提交时限性很强,而且不容许有失败和错误出现。


这对云平台的稳定性和容错性就有更高的要求,它们选择AE原因也恰恰在于由 Google 提供的高可靠 SLA。


同时 AE 的自动扩展功能使他们能够在繁忙的税季有足够的后端冗余去处理用户请求,而在淡季又能够通过自动减少后端容量已到达节约开支的目的。


最后要提到的是 Spotiy,作为互联网音乐流媒体的主要提供者,它们主要看中的是 Google 云平台的一致性和宽容度,不论你是处理每秒7个事件还是70万个,服务都能保证一至的用户体验。


所以说可扩展性对于一个云平台来说是至关重要的。


2、可扩展系统的基石




Google App Engine 采用了和大多数其他 Google 内部服务一样的微服务架构。而不得不提到的是这些微服务的共同点和它们所依赖的通用内部平台。


分布式锁和存储服务


首先不得提到的则是 Google 内部自己实现的分布式锁和存储服务 chubby。


在 Google 内部基本上所有的服务都依赖于 chubby 所提供的一系列功能。chubby 本身并没有开源,但是 Google 将 chubby 的实现细节和 API 通过一篇研究论文发表了。


这篇研究论文也恰恰催生了一批开源的实现,而其中最有名的就是大家都知道的 Apache zookeeper。


而大家也能看到 chubby 所提供的功能在单机环境就类似于大家熟知的锁和寄存器,而 chubby 或者 zookeeper 恰恰是把这种基础的服务拓展到了分布式的环境,是的软件开发者能在分布式的环境中轻松的应用单机开发中常用的方法和理论。


服务的自动发现


当你有很多松耦合的微服务组建在运行的时候,如何能够自动发现并寻址到这些服务,就变的非常重要。服务的自动发现在 Google 也是通过 chubby 来实现的。


BNS 是在chubby上实现的地址协议,chubby 提供小文件读写的一致性,这样就能通过写入 BNS 地址和真实 IP:port 绑定,来实现服务发现。


当服务需要解析一个 BNS 地址的时候,他只要通过一致性的读取相应文件即可。etcd 和基于 etcd 的 skydns 则是服务发现在开源环境中的实现。


流量负载均衡


当你有很多松耦合的微服务组建在运行的时候,你同样面临的问题是如何能够实现流量负载均衡。


在 Google 内部负载均衡是通过 Google generic service loadbalancer 服务来实现的。你如果使用 Google 的云平台的话,Google 可以提供给你网络即3层,或者 HTTPS 即七层的自动负载均衡。


在 AWS 也有类似的 Elastic loadbalancer 实现。在很多情况下,用户还可以通过 HApxoy 或者 engineX 来实现一些简单的负载均衡。


Protobuf


最后值得一提的是 Google 的 RPC 子系统和 Protobuf。Google 在近期开源了 gRPC 也就是 Google 内部使用的 RPC 子系统的开源实现。


gRPC 使用 http2 作为传输层,同时使用 Protobuf 作为接口描述语言和消息格式。


2.1 分布式锁和存储




让我们来看一下 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 功能能及时的发布。


在第二个例子当中,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




最后要提到的是 Google 开源的单元测试库 Googletest,提供两个方面的功能:


一个是单元测试;


一个是虚拟测试;


单元测试被广泛应用于 Google 的代码库,基本上每个实现都有单元测试,而且测试的覆盖率会自动报告。


虚拟测试则广泛应用在复杂服务的测试中,在写单元测试的过程中,被测部分的复杂依赖则通过 mock 来实现,是开发者能专注于单元测试中。


×

打开微信扫一扫,分享到朋友圈