云原生：运用容器、函数计算和数据构建下一代应用 ([美] 鲍里斯·肖勒（Boris Scholl） etc.) (Z-Library)

📄 File Format: PDF

💾 File Size: 2.2 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

O’Reilly精品图书系列 云原生：运用容器、函数计算和数据构建下一代应用 Cloud Native：Using Containers，Functions，and Data to Build Next-Generation Applications （美）鲍里斯·肖勒（Boris Scholl）　（美）特伦 特·斯旺森（Trent Swanson）　（美）彼得·加索维 奇（Peter Jausovec）　著 季奔牛　译 ISBN：978-7-111-65324-0 本书纸版由机械工业出版社于2020年出版，电子版由华章分社（北京 华章图文信息有限公司，北京奥维博世图书发行有限公司）在中华人 民共和国境内（不包括中国香港、澳门特别行政区及中国台湾地区） 制作与发行。 版权所有，侵权必究 客服热线：+ 86-10-68995265 客服信箱：service@bbbvip.com 官方网址：www.hzmedia.com.cn 新浪微博 @华章数媒 微信公众号 华章电子书（微信号：hzebook）

📄 Page 3

O’Reilly Media，Inc.介绍 O’Reilly以“分享创新知识、改变世界”为己任。40多年来我们 一直向企业、个人提供成功所必需之技能及思想，激励他们创新并做 得更好。 O’Reilly业务的核心是独特的专家及创新者网络，众多专家及创 新者通过我们分享知识。我们的在线学习（Online Learning）平台提 供独家的直播培训、图书及视频，使客户更容易获取业务成功所需的 专业知识。几十年来O’Reilly图书一直被视为学习开创未来之技术的 权威资料。我们每年举办的诸多会议是活跃的技术聚会场所，来自各 领域的专业人士在此建立联系，讨论最佳实践并发现可能影响技术行 业未来的新趋势。 我们的客户渴望做出推动世界前进的创新之举，我们希望能助他 们一臂之力。 业界评论 “O’Reilly Radar博客有口皆碑。” ——Wired “O’Reilly凭借一系列非凡想法（真希望当初我也想到了）建立 了数百万美元的业务。” ——Business 2.0 “O’Reilly Conference是聚集关键思想领袖的绝对典范。” ——CRN “一本O’Reilly的书就代表一个有用、有前途、需要学习的主 题。”

📄 Page 4

——Irish Times “Tim是位特立独行的商人，他不光放眼于最长远、最广阔的领 域，并且切实地按照Yogi Berra的建议去做了：‘如果你在路上遇到岔 路口，那就走小路。’回顾过去，Tim似乎每一次都选择了小路，而 且有几次都是一闪即逝的机会，尽管大路也不错。” ——Linux Journal

📄 Page 5

译者序 随着“云计算”的兴起，越来越多的公司开始“上云”。很多公 司的上云之路是从传统应用的迁移开始的，但越来越多的创新企业开 始直接基于云基础设施来设计、开发新一代应用。于是“云原生应 用”这个概念这两年也变得愈发火热。这种“诞生在云上的公司”往 往具备很多不同寻常的特质，这使其具有快速爆发的潜力。利用公有 云丰富的IaaS、PaaS和SaaS产品，公司可以实现业务的高度弹性，也便 于实现数据驱动的运营。毫无疑问，“云原生”正悄然改变着软件开 发的传统思维和模式。 随着云原生的成功和普及，我们可以看到除了创新企业，被软件 渗透的各行各业也都开始关注这一领域，并进行尝试。云原生这个概 念涵盖的内容很广泛，也有很多新的框架和工具可以使用。传统开发 人员和架构师在接触云原生这个概念后往往会从寻找一个时髦的框架 和工具开始云原生之旅。译者本人也不例外。但随着使用的深入，越 来越多的困难和挑战会随之而来。和所有技术一样，云原生也不是一 颗“银弹”。其本质是一个理念，而在这个理念的背后是云计算、容 器、函数计算等核心技术，而这些技术扩展开又会涉及很多特定的技 术和最佳实践。市面上已经有很多书在阐述这些特定的技术了，但是 能够把这些技术综合起来，围绕云原生去系统地介绍这些技术的基础 概念和知识、应用场景和最佳实践，是这本书最大的特色。 作为一名云计算领域的老兵，翻译这本书的过程也是我翻新知识 的过程。翻译的过程中很容易会将新的概念、技术与我已经了解的老 概念和技术联系起来，帮我理清其中的关系。本书不是一本可供你查 阅所有细节的工具书，也不是一本让你看得津津有味却又无从下手的 纯理论书，它更像一本参考手册，你可以从中了解云原生的前世今 生，也可以了解其核心应用场景，更重要的是它还总结了很多经验性 的东西，这些最佳实践就像最后的临门一脚，让你能够快速从理论走 入实践。

📄 Page 6

本书的翻译前后花了两个多月的时间，为了保证专业词汇翻译的 准确性，在翻译的过程中我查阅了大量相关资料。同时部分专业词汇 也保留了英文，对于大多数专业人员而言，这些英文词汇往往比中文 更容易理解。在翻译中，我尽量使用平直的语言，对部分内容做了意 译，希望能使读者更顺畅地去理解书中的内容。然而，个人的时间和 能力有限，书中难免会存在疏漏和不尽如人意之处，希望各位同仁不 吝赐教，不胜感激。 最后，我想感谢思岚科技CTO黄珏珅、运维负责人陈轶群对本书 翻译提供的帮助和指导。同时也感谢我的家人，在我将大量业余时间 投入翻译的时候义无反顾地承担起了大部分家庭事务。没有你们的帮 助和支持，我无法顺利地完成翻译工作。 愿各位读者能从本书中获益。 季奔牛 2020年2月25日

📄 Page 7

前言 不同公司和行业的精神领袖常常会重述Watts Humphrey的观点： “任何企业最终都将变成一家软件企业。”他对形势的判断确实非常 准确。软件正在冲击每个企业的现状，悄然改变着世界。Netflix彻底 颠覆了我们收看电视和电影的习惯，Uber改变了运输业，而Airbnb正 在挑战酒店业。这一切在几年前还是不可想象的，但现在各种创新企 业正借助软件的力量渗透到各行各业中去，并为这些行业带来新的思 维方式和商业模式。 前面提到的这几家公司常常被称为“诞生在云上的公司”，这句 话的意思是这些公司的产品都是在各类云服务的基础上构建的。在云 上构建这些服务使得公司能够快速响应市场，满足客户需求。云计算 可以带来很多好处，比如可以快速更新和修改、易于使用新技术，并 利用云端资源的集群优势来降低成本，改善经济效益。以云原生的方 式构建的服务还可能带来新的商业模式。利用这些服务，公司可以重 新审视现有的商业模式并考虑向新的业务模式转变，例如基于订阅的 商业模式。我们通常把这类服务称为云原生应用。 随着云原生应用的成功和普及，越来越多的企业开始采用云原生 架构来开发软件，有些甚至把云原生的理念运用到了传统企业软件 中。 容器、函数和数据是云原生应用的核心。对于这些特定的技术， 已经有很多书去阐述了。云原生应用整合了所有这些技术，使得云计 算的优势得到了充分发挥。作为作者，我们看到有很多人正努力尝试 利用这些技术来设计和开发云原生应用，因此我们决定写这本书。其 目的是提供一些基础知识，来帮助开发者和架构师更从容地开启云原 生应用设计之旅。 本书一开始先讲基础知识，让读者了解一些分布式系统的基本原 理及其与云原生应用的关系。然后再进一步介绍容器和函数等相关技 术。接着，本书介绍服务间的通信模式、服务的弹性和数据模式，并 讨论在什么情况下应该使用这些技术。最后，会总结一些经验性的东 西，例如如何结合DevOps方法、如何兼顾可移植性，以及一些最佳实 践。这些最佳实践对于打造一个成功的云原生应用是非常有帮助的。

📄 Page 8

这本书不会手把手教你如何实现一个满足特定业务需求的云原生 应用。但是在读完这本书之后，你应该会知道如何去设计、构建和运 维一个成功的云原生应用。在你去实现一些业务需求的时候，操作指 南固然很有用，然而系统地理解云原生应用的基本原理和构建方法， 才能使你的团队掌握打造成功的云原生应用的能力。 排版约定 本书的排版遵循以下约定： 斜体（Italic） 表示URL、电子邮件地址、文件名和文件扩展名。 等宽字体（Constant width） 用于程序示例，以及段落中引用的程序元素，如变量或函数名 称、数据库、数据类型、环境变量、语句声明和关键字。 等宽粗体（Constant width bold） 表示应由用户输入的命令或其他文本。 等宽斜体（Constant width italic） 表示应替换成用户提供的值或由上下文确定的值。 该图标表示提示或者建议。 该图标表示一般说明。 该图标表示警告或警示。

📄 Page 9

O’Reilly在线学习平台（O’Reilly Online Learning） 近40年来，O’Reilly Media致力于提供技术和 商业培训、知识和卓越见解，来帮助众多公司取得成功。 我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图 书、文章、会议和我们的在线学习平台分享他们的知识和经验。 O’Reilly的在线学习平台允许你按需访问现场培训课程、深入的学习 路径、交互式编程环境，以及O’Reilly和200多家其他出版商提供的 大量文本和视频资源。有关的更多信息，请访问 http://oreilly.com。 联系我们 请把你对本书的意见和疑问发给出版社： 美国： O’Reilly Media，Inc. 1005 Gravenstein Highway North Sebastopol，CA 95472 中国： 北京市西城区西直门南大街2号成铭大厦C座807室（100035） 奥莱利技术咨询（北京）有限公司 如果你对本书有任何评论或技术疑问，欢迎发送电子邮件到 bookquestions@oreilly.com。

📄 Page 10

要了解O’Reilly的图书、培训课程、会议和新闻的更多信息，请 访问我们的网站，地址是 http://www.oreilly.com。 我们的Facebook页面：http://facebook.com/oreilly。 我们的Twitter页面：http://twitter.com/oreillymedia。 我们的YouTube页面：http://www.youtube.com/oreillymedia。 致谢 我们要感谢O’Reilly的编辑Nicole Taché，以及技术审稿人和预 览版的审稿人对本书的宝贵贡献。此外，我们要感谢Haishi Bai和 Bhushan Nene，他们提出的细致评论和建议提高了这本书的质量。 Boris要感谢他的妻子Christina以及他的孩子Marie和Anton，感 谢他们在他写书的时候给予的理解和支持。 Trent要感谢他的妻子Lisa和他的儿子Mark，感谢他们在这段时间 的支持与理解。 Peter要感谢他的妻子Nives，正因为有她的支持、鼓励和理解， Peter才能把几乎所有的业余时间都花在写书上。

📄 Page 11

第1章　云原生简介 什么是云原生应用？为什么不仅在云端我们会采用云原生模型， 甚至边缘计算也开始使用该模型，是什么使得云原生应用具有如此吸 引力？此外，到底该如何设计和开发云原生应用呢？这些问题都将在 本书中得到解答。但在我们深入了解云原生有关内容、原理和方式方 法之前，我们先来了解一些云原生生态中的基本概念和设想。这些基 础概念和设想是构建云原生应用及其运行环境的根基。

📄 Page 12

1.1　分布式系统 在刚开始构建云原生应用时，开发者们遇到的最大障碍之一是这 些应用服务往往运行于不同的机器之上，所以需要考虑机器间的网络 通信模式。他们甚至自己都没意识到，其实这就是分布式系统。分布 式系统看上去就像是一台机器在工作，但其实它由一组独立的机器组 成，它们之间通过网络相连接。这样的系统可以将计算任务分配到不 同的机器上，这种分配任务的能力使得应用服务在具有可扩展性、可 靠性的同时也更加经济。例如，大多数云服务供应商会使用便宜一些 的商用机，然后依靠软件的解决方案来处理诸如高可用和可靠性等常 见问题。

📄 Page 13

1.1.1　分布式系统的误区 在初入分布式系统世界的时候，大多数的开发者和架构师会做一 些错误的或毫无根据的假设。Sun Microsystems公司的研究员Peter Deutsch早在1994年就意识到了几个有关分布式系统的误区，那时候还 没有人知道云计算是什么。由于云原生应用的核心也是分布式系统， 所以这些误区在今天仍然存在。 下面是Deutsch列出的几个误区，其含义同样适用于云原生应用： 网络是安全的 即使在云端，你也无法保证网络是安全的。各种服务通常会部署 在不同的机器上，所以在开发这些服务时你需要把潜在的网络故障考 虑进去。我们稍后将在本书中讨论这个问题。 延迟是不存在的 人们常常混淆延迟和带宽，但是理解这两个概念的差异很重要。 延迟指的是数据从发送到接收需要多少时间。而带宽指的是在给定时 间窗口内可以传输多少数据。因为延迟对用户体验和性能有很大影 响，所以你应该注意以下事项： ·避免频繁的网络调用和一些不必要的请求。 ·在设计云原生应用时，可以考虑采用缓存、内容分发网络 （CDN）、多区域部署等技术或方法来使得数据离客户端更近。 ·采用“发布/订阅”模式，以通知有新数据到达，并将其存储在 本地以便可以立即使用这些数据。第3章会详细介绍包括“发布/订 阅”在内的各种消息通信模式。 带宽是用之不尽的 现如今，网络带宽似乎不再是一个大问题了。但事实上，新的技 术和边缘计算等新领域会开辟一些需要更高带宽的新场景。举个例

📄 Page 14

子：据测算，一辆无人驾驶汽车每天大约会产生50 TB的数据。这样的 数据量就需要你在设计云原生应用时考虑到带宽使用情况。“领域驱 动设计”（DDD）模式和类似“命令查询职责分离”（CQRS）这样的数 据模式在此类带宽要求较高的场景下是很有用的。第4章和第6章将更 详细地讨论如何处理云原生应用中的数据。 网络是安全的 诊断和安全是两件开发者们常常在出问题后才会去反思的事情。 网络总是安全的这个假设是极其错误的。作为一个开发者或者架构 师，你必须在设计时就将安全问题列入优先事项，例如，考虑采取纵 深防御的策略。 拓扑结构是不变的 “宠物与牲畜[1]”这个类比随着容器技术的出现而变得越来越普 及。它的意思是你不会像对待具有其自身属性（如静态IP）的特定实 体（宠物）一样对待机器。相反，你会把机器视为没有特殊属性的群 体的一员。这个理念对于云原生应用而言非常重要，因为云计算旨在 提供弹性，机器的数量会随着计算资源的消耗和请求数的变化而变 化。 一个管理员可以搞定一切 在传统的软件开发过程中，通常都会有一个人来负责软件的运行 环境、安装和升级应用程序。但是在现代的云计算架构和DevOps理念 下，这种情况已经发生了改变。一个现代的云原生应用一般会由很多 服务组成，这些服务需要协同工作，但是它们往往由不同的团队开 发。因此要让一个人完全搞明白整个应用是如何工作的几乎是件不可 能的事情，更别说去修复问题了。所以你需要确保你的应用有完善的 治理措施，使得排查故障变得相对容易。在这本书中，我们会介绍一 些相关概念，如发布管理、解耦、日志与监控等。第5章会详细介绍云 原生应用的一些常见的DevOps实践。 传输是没有成本的 站在云原生的角度，这个误区有两个解释。首先，数据通过网络 传输，而网络流量在大多数的公有云平台上都是要收费的。大多数云

📄 Page 15

服务商对入网流量[2]不收费，但是对出网流量[3]会收费。其次，传输 的数据与对象之间的转换是有成本的，例如序列化和反序列化除了会 带来网络延迟外通常还会产生一些额外的昂贵开销。 网络通信都是一样的 这个误区现在几乎不值一提了，因为几乎每个开发人员和架构师 都知道在构建应用程序的时候必须考虑到不同的网络协议。 如前所述，尽管这些误区很早以前就已经提出来了，但是在步入 云原生的世界时，这些错误的假设仍然值得警惕。在这本书中，我们 将教你一些模式和最佳实践，这些模式和最佳实践都充分考虑了分布 式系统中这些常见的误区。 [1] 宠物类比的是传统服务器或虚拟机，每一个都被照顾得很好，不可 或缺。牲畜类比的是云端服务器实例，量多、可替代、短生命周期。 [2] 又称下行流量，指数据从公网进入云服务器产生的流量。 [3] 又称上行流量，指数据从云服务器流出到公网产生的流量。

📄 Page 16

1.1.2　CAP定理 提到分布式系统就不得不提一下CAP定理。CAP定理指出，任何一 个通过网络连接的、共享数据的分布式系统最多只能同时满足以下三 个需求中的两个： ·一致性（Consistency，C）：指所有节点访问同一份最新的数据 副本。 ·可用性（Availability，A）：指系统提供的数据或服务必须一直 处于可用状态。 ·分区容错性（Partition tolerance，P）：指系统在遇到网络分区 故障的时候，仍然能够对外提供服务。 现实情况是，网络分区故障经常会出现（记得前面所提到的， “网络是安全的”是分布式系统的误区之一），所以你必须考虑到这 一点。然而这样的话你就不得不在追求一致性还是高可用性之间做出 取舍。很多NoSQL数据库（如Cassandra）会选择追求高可用性，而像 关系型数据库会为了遵循ACID原则（原子性、一致性、隔离性和持久 性）而追求一致性。

📄 Page 17

1.2　十二要素应用 在基础架构即服务（Infrastructure as a Service，IaaS）和平 台即服务（Platform as a Service，PaaS）发展的早期阶段，人们就 发现需要一种新的方式来开发更适用于云计算的应用程序。举个例 子，传统数据中心在需要扩容时经常采用纵向扩容的方式，即通过增 加单台物理服务器的计算资源来进行扩容。而在云端，通常采用的是 横向扩容的方式，即通过增加虚拟服务器的数量来分担负载。这种扩 容方式要求应用程序是无状态的，而这个特点也是十二要素（12- factor）应用的宣言之一。十二要素应用这一方法论是由Heroku的工 程师从云端应用开发的最佳实践中总结出来的，可以被认为是云原生 应用的基础。尽管云计算一直在不停地发展，但是十二要素宣言中的 这些原则仍然适用。以下是十二要素的内容及其对于云原生应用的意 义： 1.基准代码 一份基准代码，多份部署。 一个应用只有一份基准代码，但是这份代码可以部署到多个环境 中，如开发环境、测试环境和生产环境。在云原生架构中，这个原则 可以解释成一个服务或者函数只有一份基准代码，它们各自拥有自己 的持续集成（Continuous Integration，CI）和持续部署 （Continuous Deployment，CD）工作流。 2.依赖 显式地声明依赖关系并隔离依赖。 声明和隔离依赖在云原生应用的开发中很重要。很多问题是由缺 少依赖项或依赖项的版本不同造成的，其根源在于内部部署环境和云 端环境是有差异的。通常，你应该用类似Maven或npm这样针对不同语 言的管理工具来管理依赖项。现在，容器技术已经大大减少了由依赖 产生的问题，因为依赖项都会在Dockerfile中进行声明然后被打包进 容器中。对系统依赖而言，Chef、Puppet、Ansible和Terraform是很 好的管理和安装工具。

📄 Page 18

3.配置 在环境中存储配置。 配置和代码应该严格分开，这样你才能够轻松地配置不同的环 境。例如，在测试环境中，你可以有一个测试配置文件，这个文件中 包含的连接字符串和其他信息都是指向这个测试环境的。如果你想把 这个应用部署到生产环境中，那么你只需要替换掉这个配置文件就可 以了。现在很多平台都支持外部配置，比如使用Kubernetes的配置管 理或者使用云端环境中的托管配置服务。 4.后端服务 把后端服务当作附加资源。 后端服务指的是程序运行所需要的通过网络调用的各种服务。举 两个在云原生应用领域的例子，比如像缓存服务和数据库服务 （Database as a Service，DbaaS），这些都是后端服务。在访问这 些后端服务时，一个比较推荐的做法是通过外部配置系统来获取这些 服务的配置信息。这样做的好处是降低耦合度，这也是云原生应用的 一个基本原则。 5.构建、发布和运行 严格分离构建和运行阶段。 正如你将在第5章中看到的DevOps相关内容，建议使用CI/CD的一 些实践来实现全自动地构建和发布应用。 6.进程 用一个或多个无状态的进程来运行应用。 如前所述，在云端的应用应该是无状态的，任何需要持久化的数 据都应该存储在外部。这样做才能实现弹性，而弹性是云计算的目的 之一。 7.数据隔离

📄 Page 19

每个服务管理自己的数据。 这是微服务架构的一个关键原则，同时也是云原生应用的一个常 见模式。每个服务管理自己的数据，这些数据只有通过该服务的API才 能获取。这意味着即使属于同一个应用，一个服务也无法直接访问其 他服务中的数据。 8.并发 通过进程模型进行扩展。 云原生应用的两大优势是可扩展性和更有效的资源利用。你可以 通过独立横向扩展单个服务或者函数来实现更高的资源利用率。 9.易处理 通过快速启动和优雅退出来最大化应用的健壮性。 容器技术和函数已经能够满足第一点了，因为它们的启动速度都 很快。但后一点常常被忽略，在设计一个服务时就应该考虑到程序崩 溃和规模收缩问题，这种情况下容器或者函数的实例数量会减少，我 们要特别注意这一点。 10.开发环境与线上环境等价 尽可能地保持开发环境、预发布环境和生产环境相同。 你可以利用容器技术来打包服务所需的依赖项，这样可以减少环 境的不一致带来的问题。但还是会有一些比较棘手的情况，比如在你 的开发环境下，有些受托管的服务是不可用的。第5章会介绍一些技术 和方法来使得你的环境尽量保持一致。 11.日志 把日志当作事件流。 在分布式系统中，记录日志是一件很重要的事。因为有那么多的 服务在同时运行，又是跑在不同的节点上的，如果你没有一个很好办 法来记录日志，一旦你的应用出问题了，那你就抓瞎了。十二要素的

📄 Page 20

这一条就是告诉你可以把日志当作事件流来处理，把这些事件流输出 到一个外部系统中统一记录。 12.管理进程 把后台管理任务当作一次性进程来运行。 这一点的意思是你应该把管理任务当作是一个短期进程来执行。 函数和容器都是执行这些任务的好工具。 你会在本书中再次了解上述要素，因为它们与云原生应用息息相 关。