云系统管理:大规模分布式系统设计与运营.html.pdf
《云系统管理:大规模分布式系统设计与运营.html.pdf》由会员分享,可在线阅读,更多相关《云系统管理:大规模分布式系统设计与运营.html.pdf(315页珍藏版)》请在三一文库上搜索。
1、译者序 我们这一代人是幸运的,因为我们生在变革的年代,亲眼见证了蒸汽机发明以来最重要的技术成就计算机和互联网的 兴起。 在我们儿时,连机械化都是一种梦想,仅仅在十年之前,还无法想象一部手机就可以拥有过去大型计算机的能力,过去只有 在科幻小说中才能看到的情景,而今已经十分普遍。世界仿佛变得很小,一切都在我们的指尖之下,这就是科技的力量。 科技的发展帮助人类不断创造出更高质量、更低价格的产品,而产品之后的设计思想更为重要。我们今天拥有似乎无穷无尽 的网络资源和计算能力,不仅是因为硬件技术的发展,更为关键的是分布式计算的出现,它将非关即开的数字化设备模型化为传 统上的“模拟”系统,增进了系统的伸缩性
2、和可靠性。借助这一关键的思路,我们才有了今天724运行的各种线上系统,以及 引人遐想的“云计算”。 本书是几位供职于全球最大规模技术公司的专家的力作,全方位地介绍了大规模分布式系统的设计和运营,内容十分充实, 不仅介绍了有关分布式系统架构、应用和设计原则的理论知识,更有Google、Facebook等公司的成功案例分析,在附录中还 介绍了分布式系统的由来以及成熟度模型、设计文档等模板。尽管本书的主题是运营,但是其中系统阐述了运营与开发的关系, 包括DevOps等全栈融合思想,对于这种环境下的开发人员也极有教益。细细阅读,不仅能够了解许多分布式计算的关键概念和 思想,还可以深深体会技术的发展过程
3、,以及大规模网站运营中的经验和教训。在艰苦的翻译期间,我们的思想也受到了很大的 冲击,感受到技术发展对运营思想甚至整个企业经营思想的影响。掩卷之时也有一份担心,我们是否已经捕捉到原书的精髓,并 将其准确传达给读者? 本书的翻译工作主要由姚军和陈志勇完成,徐锋、刘建林、吴兰陟、宁懿、姚红斌、白龙、陈美娜、谢志雄、方翊、陈霞、 林耀成、管军凯、吴玥、余骆、耿飞等人也为翻译工作做出了贡献。 译者 2016年3月 前言 下面的表述是否真实? 1)最为可靠的系统是使用廉价、不可靠的组件构建的。 2)Google为数十亿用户服务所用的技术遵循的模式,与你处理数千名用户的系统所遵循的模式相同。 3)某种过程
4、的风险越大,你越应该尝试。 4)某些最重要的软件功能是用户从未发现的。 5)你应该随意选择一些机器,并关闭其电源。 6)Facebook在接下来六个月中所要发布的代码,其功能可能已经在你的浏览器中出现了。 7)每天多次更新软件所需要的人工很少。 8)随时待命并不一定是一种紧张、痛苦的体验。 9)你不应该监控机器是否启动。 10)运营和管理可以通过试验和证明的科学原理进行。 11)Google已经对僵尸攻击时的对策进行了演练。 这些表述都是真实的,当你读完本书,就会知道原因。 本书讲述的是大规模云服务(数百万甚至数十亿用户使用的基于互联网的服务)的构建和运行。每天,都有越来越多的企业 采用这些技
5、术,因此,本书是为所有人写的。 本书的目标读者是系统管理员和他们的经理。你无需计算机科学的背景,但是你应该有Unix/Linux系统管理、联网的经 验,以及操作系统的概念。 我们重点关注构建和运营组成“云”的服务,而不是指导云服务的使用。 云服务必须是可用的、快速的和安全的。考虑到云的规模,这将是独特而杰出的工程成就。因此,云规模服务设计不同于典 型的企业服务。可用性很重要,因为互联网是724开放的,用户处于各个时区。快速的重要性在于用户会因为慢速的服务而感 到沮丧,所以缓慢的服务会被更快的竞争者所取代。安全的重要性则在于,作为他人数据的托管者,我们义不容辞(而且负有法 律责任)地要保护人们的
6、数据。 这些要求是互相交织的。如果网站不安全,当然也就不可能可靠。如果网站速度不快,可用性也就不足。如果网站下线,当 然就不可能快速。 最明显的云规模服务是网站。但是,还有一个巨大的无形互联网访问服务生态系统,这些服务不是通过浏览器访问的。例 如,智能手机应用通过API调用访问云服务。 在本书余下的部分中,我们倾向于使用“分布式计算”而非“云计算”。云计算是一个营销用语,对不同的人有不同的含 义。分布式计算描述了使用许多机器(而非单一机器)提供应用程序和服务的一种架构。 本书介绍的是不受时间影响的基本原理及方法。因此,我们不推荐使用特定的产品或者技术。我们可以提供前5种最流行的 Web服务器、
7、NoSQL数据库或者持续构建系统的对比,但是如果这么做,本书就会在出版的那一刻过时。相反,我们讨论的是 选择这些系统时应该注意的特质,提供一种工作模式。这种方法的意图是帮助你在技术不断变化的漫长职业生涯中始终做好准 备。当然,我们将用具体的技术和产品说明我们的观点,但是不代表我们支持这些产品和服务。 本书有时看似理想化,这是故意为之。我们想为读者提供事物将会如何发展、该坚持什么原则的愿景,目的是更上一层楼。 关于本书 本书分为两个部分设计和运营。 第一部分捕捉我们在大规模、复杂、基于云的分布式计算系统设计上的想法。在引言之后,我们从下向上逐层介绍设计的每 个要素。我们从系统管理员(而非计算机科
8、学家)的角度介绍分布式系统,要运营一个系统就必须理解其内部原理。 第二部分描述如何运营这些系统。前面几章介绍最基本的问题。后面几章深入更为复杂的技术活动,然后是概要规划和将以 上要素组合起来的战略。 最后是附加材料,包括运营团队的评估系统、被歪曲的分布式计算历史、正文中提及的表单模板、建议阅读的材料以及其他 参考材料。 我们满怀兴奋之情介绍本系列书籍中的一个新特征:运营评估系统。这个系统由一系列评估活动组成,你可以用它们评估自 己的运营,找出需要改进的领域。评估问题和“搜索”建议可以在附录A中找到。第20章是该系统的说明。 致谢 没有我们所在社区及来自全球的帮助及反馈,本书就不可能出版。Dev
9、Ops社区慷慨地提供了帮助。 首先,我们要感谢我们爱人和家人:Christine Polk、Mike Chalup、Eliot和Joanna Lear。他们的爱和耐心成就了一切。 之所以我们能够看得更远,那是因为我们站在巨人的肩上。某些章节在很大程度上得到了下列人士的支持和建议:John Looney和Cian Synnott(第1章);Marty Abbott和Michael Fisher(第5章);Damon Edwards、Alex Honor和Jez Humble(第9章和第10章);John Allspaw(第12章);Brent Chapman(第15章);Caskey Dicks
10、on和Theo Schlossnagle(第16章和17章);Arun Kejariwal和Bruce Yan(第18章);Benjamin Treynor Sloss(第19章);Geoff Halprin(第20章和附录A)。 感谢Gene Kim“有策略”的启发和鼓励。有几十位人士帮助过我们有些人提供奇闻轶事,有些人审核某些部分或者整 本书。感谢他们所有人的公平方式是按照字母顺序排列,并预先向我们遗漏的所有人道歉:Thomas Baden、George Beech、 Raymond Blum、Kyle Brandt、Mark Burgess、Nick Craver、Geoff Dalga
11、s、Robert P.J.Day、Patrick Debois、Bill Duane、Paul Evans、David Fullerton、Tom Geller、Peter Grace、Elizabeth Hamon Reid、Jim Hickstein、Zachary Hueras、Matt Jones、Jennifer Joy、Jimmy Kaplowitz、Daniel V.Klein、Steven Levine、Cory Lueninghoener、Shane Madden、Jim Maurer、Stephen McHenry、Dinah McNutt、Scott Hazen Muel
12、ler、Steve Murawski、Mohit Muthanna、Lenny Rachitsky、Amy Rich、Adele Shakal、Bart Silverstrim、Josh Simon、Joel Spolsky、Desiree Sylvester、Win Treese、Todd Underwood、Nicole Forsgren Velasquez和Dave Zwieback。 最后(但并非不重要),感谢Addison-Wesley的所有人,特别要感谢Debra Williams Cauley将我们引见给Addison- Wesley,并在整个过程中为我们掌舵;感谢Michael
13、 Thurston对本书初稿的编辑和改进,使之更加完美;感谢Kim Boedigheimer的协调工作以及在我们惊慌的时候帮助我们保持镇静;感谢我们的LaTeX奇才Lori Hughes;感谢产品经理Julie Nahil;感谢文字编辑Jill Hobbs;还要感谢John Fuller和Mark Taub忍受我们的特殊要求! 第一部分 设计:构建系统 第1章 分布式世界中的设计 概述分布式系统的设计。 第2章 为运营而设计 为了实现平稳运营而应该具备的软件功能。 第3章 选择服务平台 物理机和虚拟机,私有云和公共云。 第4章 应用程序架构 创建Web和其他应用程序的基本组件。 第5章 伸缩性
14、设计模式 扩增服务所用的基本组件。 第6章 弹性设计模式 创建可幸免于故障的系统的基本组件。 第二部分 运营:运行系统 第7章 分布式世界中的运营 分布式系统运行方式概述。 第8章 DevOps文化 DevOps文化、历史和实践简介。 第9章 服务交付:构建阶段 如何构建服务和准备投产。 第10章 服务交付:部署阶段 服务如何测试、批准和投产。 第11章 升级运行中的服务 如何在不停机的情况下升级服务。 第12章 自动化 创建工具和自动化运营工作。 第13章 设计文档 书面交流设计和意图。 第14章 随时待命 处理异常情况。 第15章 灾难准备 通过规划和实践强化系统。 第16章 监控基础知识
15、 监控术语和策略。 第17章 监控架构与实践 监控组件和方法。 第18章 容量规划 在需要之前规划并提供附加资源。 第19章 建立KPI 通过计量和反思科学地推动行为。 第20章 卓越运营 持续改善的战略。 第三部分 附录 附录A 评估 附录B 分布式计算和云的起源及未来 附录C 伸缩性术语和概念 附录D 模板和示例 附录E 推荐读物 后记 最后的一些想法。 参考文献 作者简介 托马斯A.利蒙切利(Thomas A.Limoncelli)是具有国际声誉的作家、演说家和系统管理专家。在Google NYC的7年中, 他曾经担任Blog Search(博客搜索)、Ganeti和各种内部企业IT服务
16、项目的SRE。他现在于Stack Exchange公司任SRE,该公 司主办ServerF和Stack-O网站。Thomas的第一份有报酬的系统管理工作是1987年在德鲁大学学习时获 得的,此后在小型和大型公司中任职,包括AT&T/Lucent贝尔实验室等。他的著名作品包括Time Management for System Administrators(OReilly)和The Practice of System and Network Administration,Second Edition(Addison- Wesley)。他的爱好包括草根行动,为此进行的工作在州乃至国家的层面上得到
17、公认。Thomas目前住在新泽西州。 斯特拉塔R.查卢普(Strata R.Chalup)已经领导和管理复杂IT项目多年,所担任的职务包括项目经理和运营主管。Strata曾 经撰写过管理方面的多篇论文,并且与许多团队合作,在各种志愿组织(包括BayLISA和SAGE)应用其管理技能。她于1983年 在波士顿的MIT开始管理VAX Ultrix和Unisys UNIX,在硅谷度过了.com年代,为iPlanet和Palm等客户构建互联网服务。2007 年,她与Tom和Christina一起编写了The Practice of System and Network Administration,S
18、econd Edition。Strata的 爱好包括学习新技术(如Arduino和各种2D CAD/CAM设备)和园艺。她住在加州的圣克拉拉县。 克里斯蒂娜J.霍根(Christina J.Hogan)在系统管理和网络工程上有20年的经验,足迹遍及美国硅谷、意大利和瑞士。她 在小型创业公司、中等规模技术公司和大型跨国公司获得了经验,多年担任安全顾问,客户包括eBay、Silicon Graphics和 SystemExperts。2005年,她和Tom因为合著的The Practice of System and Network Administration一书而分享了 SAGE杰出成就奖。她
19、拥有数学学士学位、计算机科学硕士学位、航空工程博士学位和法学文凭。她还曾在某F1车队担任空气动 力学家6年之久,并代表爱尔兰参加1988年国际象棋奥林匹克竞赛,现居瑞士。 引言 本书的目标是帮助你构建和运行最佳的云规模服务。什么是我们希望创建的理想环境? 商业目标 简单地说,理想环境的最终结果是满足商业目标。这听起来有些乏味,但是实际上在全公司注目的焦点上切入,共同实现同 一个目标,是十分激动人心的。为此,我们必须理解商业目标,并且由此倒推出应该构建的系统。 满足商业目标意味着了解这些目标、制定计划实现它们并且消除沿途的障碍。定义良好的商业目标是可计量的,这些计量指 标可以自动化收集。自动化生
20、成的仪表盘使每个人了解进展,这种透明度能够增强信任。 下面是商业目标的一些例子: 通过网站销售我们的产品。 在99.99%的时间内提供服务。 每个月处理x百万笔订单,每月增长10%。 每周两次推出新功能。 在24小时内修复重大缺陷。 在我们的理想环境中,业务和技术团队以可预测和可靠的方式满足他们的目标和项目目标。因此,两类团队都信任其他团队 能够满足未来的目标。结果是,团队可以更好地制定计划。他们可以制定更为积极的计划,因为确信外部依赖不会失效。在这种 情况下,计划可以更加积极,这种方法会形成向上的螺旋,加速整个公司的进展,惠及每个人。 理想系统架构 理想的服务是在稳定的架构上构建的,它能够满
21、足当前的服务需求,并且在系统变得较为流行、接收更多流量时提供明显的 成长路径。这种系统对故障具备弹性,架构不会对故障感到意外,将其作为异常情况对待,而是接受硬件和软件故障作为信息技 术(IT)物性的一部分。结果是,这种架构包含应对故障的冗余和弹性特征,组件失效时系统仍可存活。 组成服务的每个子系统本身也是服务。所有子系统都可以通过应用程序编程接口(API)编程,因此,整个系统是互联子服 务的生态系统,这称作面向服务架构(SOA)。因为这些系统都使用相同的底层协议通信,具有管理上的一致性。每个子服务 相互松散耦合,因此这些服务可以独立伸缩、升级或者替换。 基础设施的几何结构采用电子方式描述,这种
22、电子描述由IT自动化系统阅读,然后在没有人为干预的情况下构建生产环境。 基于这种自动化,整个基础设施可以在其他地方重建,软件工程师利用自动化建立环境的微版本,供个人使用。质量和测试工程 师利用自动化创建用于系统测试的环境。 无论我们是使用物理机器还是虚拟机器,也不管是使用我们运行的还是由云提供商托管的数据中心,都能实现这种“基础架 构即代码”。对于虚拟机,显然有API可以用于准备新机器。但是,即使使用物理机器,从裸机到工作系统的整个流程也可以自 动化。在我们的理想世界中,自动化使组合物理和虚拟机器创建环境成为可能。开发人员可以从虚拟机构建环境,生产环境可能 包含物理和虚拟机的组合。额外容量的临
23、时和意外需求可能需要在一段时期内将生产环境扩展到一个或者多个云提供商。 理想的发行过程 理想的环境具备从代码开发到运营的平稳流程。传统上(不是在我们的理想环境中)顺序是这样的: 1)开发者在存储库中登记代码。 2)测试工程师将代码投入一系列测试。 3)如果所有测试通过,发行工程师将构建一个用于部署软件的“包”。大部分文件来自于源代码库,但是有些文件可能必 须来自其他来源,如图形部门或者文档编写者。 4)创建一个测试环境;如果没有采用“基础架构即代码”模式,这可能需要花费数周。 5)软件包被部署到测试环境中。 6)测试工程师进一步执行测试,重点是子系统之间的交互。 7)如果所有测试成功,则将代码
24、投入生产环境。 8)系统管理员升级系统同时寻找缺陷。 9)如果有缺陷,则将软件回滚。 人工进行上述步骤会招致许多风险,这是因为事先得具备合适的人员、上述步骤每次都以相同的方式完成、没有人会犯错误 且所有任务都会及时完成等假设。 错误、程序缺陷和偏差当然会发生因此缺陷会被传递到下一个阶段。发现错误时,工作流倒转,负责前一阶段的团队 成员被告知需要修复他们的问题。这意味着工作无法取得进展、损失了时间。 对某种高风险过程的典型反应是尽可能少做。因此就产生了尽可能少发行的念头,结果是“重大发行版本”每年只投放一两 次。 但是,将许多更改一次性批量进行,实际上造成了更大的风险。如何确保同时发布的几千项更
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统管理 大规模 分布式 系统 设计 运营 html
链接地址:https://www.31doc.com/p-5518374.html