描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121324338
*近在分布式系统上的习惯已经从构建和维护到破坏monolithic应用转换成微服务，但是微服务架构和交互的标准化和*实践仍在很大程度上没有定义。在打散一个monolithic应用或是通过scratch构建了微服务之后，许多工程师想知道“接着呢？”在《生产微服务》中，作者从运行超过一千个微服务的高生产准备标准中获取经验。他讨论了适用所有微服务的标准，分享了使微服务处于生产就绪状态的策略。他认为，一个生产就绪状态的微服务，就是稳定的、可靠的、容错性高、伸缩性强、性能高、可监控，并且准备好应对任何灾难、文件和理解。
前言. ………………………….. xii
第 1章 微服务简介. ………….. 1
从单体应用到微服务 ………………………………………… 1
微服务架构 ……….. 7
微服务生态系统 …. 9
第 1层：硬件层 ………………………………………. 10
第 2层：通信层 ………………………………………. 11
第 3层：应用平台层 ………………………………… 13
第 4层：微服务层 …………………………………… 15
组织的挑战 ……… 16
反康威定律.. 17
技术蔓延 ….. 18
更多失效的可能性 …………………………………… 18
资源竞争 ….. 19
第 2章 生产就绪…………… 21
微服务标准化的挑战 ………………………………………. 21
可用性：标准化的目标 ……………………………………. 22
生产就绪标准 ….. 23
稳定性 ……… 24
可靠性 ……… 24
伸缩性 ……… 25
容错和灾备.. 26
高性能 ……… 28
监控 …………. 28
文档化 ……… 29
实现生产就绪标准 ………………………………………….. 31
第 3章 稳定性和可靠性. …… 33
微服务稳定性和可靠性的原则 …………………………. 33
开发周期 …………. 34
部署管道 …………. 36
staging ……… 36
canary ………. 40
生产 …………. 41
让稳定可靠的部署成为强制措施 ……………….. 41
服务依赖 …………. 42
路由和服务发现 .. 44
服务和端点的解除 ………………………………………….. 44
评估你的微服务 .. 45
开发周期 ….. 45
部署管道 ….. 46
服务依赖 ….. 46
路由和服务发现 ………………………………………. 46
服务和端点的解除 …………………………………… 46
第 4章 伸缩性和高性能. …… 47
关于微服务伸缩性和高性能的原则 …………………… 47
了解增长规模 ….. 48
质的增长规模 ………………………………………….. 48
量的增长规模 ………………………………………….. 50
资源的有效利用 .. 50
资源感知 …………. 51
资源需求 ….. 51
资源瓶颈 ….. 51
容量规划 …………. 52
依赖项的伸缩 ….. 53
流量管理 …………. 54
任务处理 …………. 55
编程语言的限制 ………………………………………. 55
高效地处理请求任务 ………………………………… 56
可伸缩的数据存储 ………………………………………….. 56
微服务生态系统的数据库选择 …………………… 57
微服务架构在数据库方面面临的挑战…………. 57
评估你的微服务 .. 58
增长规模 ….. 58
资源的有效利用 ………………………………………. 58
资源感知 ….. 58
容量规划 ….. 59
依赖项的伸缩 ………………………………………….. 59
流量管理 ….. 59
任务处理 ….. 59
可伸缩的数据存储 …………………………………… 59
第 5章 容错和灾备………… 61
用于构建具有容错能力微服务的原则 ……………….. 61
避免单点故障 ….. 62
故障场景 …………. 63
常见的生态系统故障 ………………………………… 64
硬件故障 ….. 65
通信层和应用平台层的故障 ……………………… 66
依赖项故障.. 68
内部故障 ….. 69
弹性测试 …………. 70
代码测试 ….. 71
负载测试 ….. 72
混沌测试 ….. 74
故障检测和修复 .. 75
事故和中断.. 76
处理事故的 5个步骤 ………………………………… 78
评估你的微服务 .. 80
避免故障点.. 80
故障场景 ….. 80
弹性测试 ….. 80
故障检测和修复 ………………………………………. 81
第 6章 监控………………… 83
用于微服务监控的原则……………………………………. 83
关键性度量指标 .. 84
日志 ……………….. 86
仪表盘 …………….. 87
告警 ……………….. 88
设置有效的告警 ………………………………………. 89
处理告警 ….. 89
轮班待命 …………. 90
评估你的微服务 .. 91
关键性度量指标 ………………………………………. 91
日志 …………. 91
仪表盘 ……… 91
告警 …………. 91
轮班待命 ….. 92
第 7章 文档化和理解. ……… 93
微服务文档和理解的原则 ………………………………… 93
微服务文档 ……… 95
描述 ……………………………………………………….. 96
架构图 ……… 96
轮班待命信息 ………………………………………….. 97
链接 …………. 97
开发上手指南 ………………………………………….. 97
请求消息流、端点和依赖项 ……………………… 98
运行手册 ….. 98
问答章节 ….. 99
理解微服务 ……… 99
架构评审 … 100
生产就绪审计 ………………………………………… 101
生产就绪路线图 …………………………………….. 101
生产就绪自动化 …………………………………….. 102
评估你的微服务 102
微服务文档 103
微服务理解 103
附录A 生产就绪检查列表.. 105
附录B 评估你的微服务….. 107
术语表……………………….. 113
索引. …………………………. 119
译者序
微服务在近几年逐渐成为一个热门的技术新名词，受到技术社区的热捧。一些巨头公司，特别是那些互联网公司，用户规模在不断增长，业务需求变得日益复杂，开发团队的规模也随之膨胀，一般的单体应用早已无法满足公司发展的需求。微服务的出现可以说是行业发展到一定阶段的必然产物。确切地说，微服务并不是一门技术，而是一种架构风格。你可以使用任何一门开发语言、任何一种框架来实现一个微服务。微服务容易开发、理解和维护，可以独立部署、独立伸缩，非常灵活。
通过将单体应用分解成微服务，解决了复杂性问题。每个微服务负责处理单一的任务，微服务之间通过定义好的接口相互通信，后组成一个庞大的微服务生态系统。看似我们绕了一个大圈子，其实则不然。
每个微服务就是一个独立运行的应用，分别由专门的团队负责开发，开发人员可以自由选择他们熟悉的技术，也可以采用的技术，而且可以快速做出变更。所以对于开发人员来说，微服务给他们带来了极大的自由度，同时极大地提升了开发速度。
每个微服务可以独立开发、独立部署，而不像单体应用那样牵一发而动全身。每个微服务可以独立演化，在快速做出变更后进行部署，如果有必要，每天可以进行多次部署，因为微服务体积小，所以构建时间短，部署起来也非常方便。
每个微服务都可以独立伸缩，可以根据具体情况为每个微服务部署不同数量的实例，也可以为不同的微服务选择不同的硬件。比如，对于不是很关键的微服务可以使用便宜的硬件，对于负载不是很高的微服务就可以少部署几个实例。而对于高负载的关键微服务则多部署一些实例，并使用更好的硬件。
不过，采用微服务架构的门槛其实是很高的。Martin Fowler认为，一个公司要采用微服务，必须满足三个基本前提条件，即快速配置能力、基本的监控能力和快速部署能力。而除此之外，要成功实施微服务，还有其他很多重要的因素需要考虑。作为 Uber的网站可靠性工程师，Susan Fowler在 Uber内部致力于微服务的标准化，制订生产就绪微服务的标准，并帮助微服务团队成功实施微服务。 Susan基于她在 Uber成功实施微服务的经验，并结合她与其他公司工程师之间就微服务话题进行的讨论，总结出了一套生产就绪微服务的标准。本书列出的一组生产就绪微服务的检查清单可以作为成功实施微服务的参考标准。
不过话说回来，在软件技术领域并不存在什么银弹。微服务并不适合所有公司，在考虑是否采用微服务之前要先了解清楚自己的问题。先仔细想清楚，你的问题一定只能通过微服务来解决吗？如果是，那么你具备了实施微服务的条件了吗？不要只是因为那些巨头公司采用了微服务就盲目崇拜他们，如果走错了路，到后只会给你带来惨痛的教训。
这不是一本描写具体技术实现的书，没有代码，没有具体的开发框架。但是它也不是只空讲理论，本书列出的生产就绪微服务的标准完全来自于 Uber和其他公司的实践，而且从目前来看，可以说是“前无古人，后无来者”的一次针对实施微服务的大总结。
这本书值得所有的技术总监、架构师、网站可靠性工程师和开发工程师一读。先抛开脑子里的代码、开发框架，用宏观的视角审视微服务，了解微服务的本质。所谓“知己知彼，百战不殆”，只有了解了微服务的本质，才能不被其左右。当然，如果你真的需要微服务，而且具备了实施微服务的条件，那么这本书一定会给你带来不可限量的惊喜！
薛命灯 2017年 6月于上海
译者简介
薛命灯，毕业于厦门大学软件学院，具有十余年软件开发和架构经验。技术涉猎十分广泛，从前端到后端，从各种编程语言到分布式软件架构，从企业应用到大数据。在工作之余，爱好摄影和技术翻译，是 InfoQ的优秀社区编辑。
前言
在作为网站可靠性工程师（SRE）加入到 Uber工作之后，我提出了生产就绪标准的倡议，并在 Uber实施了几个月，这本书也随之诞生。Uber庞大的单体 API正逐渐被分解成微服务，在我加入 Uber那会儿，已经有上千个从单体 API分离出来的微服务，它们独立于单体系统运行。每个微服务都有专门的开发团队进行设计、开发和维护，但 85%的微服务几乎没有 SRE。
招聘 SRE和打造 SRE团队不是一件容易的事情， SRE比其他类型的工程师更难找：网站可靠性工程师是一种新型职位， SRE必须（至少在一定程度上）是软件工程、系统工程和分布式系统架构方面的专家。在短时间内为所有的团队配备内部 SRE团队是不可能的，于是我的团队（SRE咨询团队）诞生了。我们的目标很简单：推动这些没有 SRE的团队实施高标准化。
虽然我们的任务很简单，但并没有明确的指示，所以我和我的团队就有了一定的自由空间来定义一系列标准，Uber所有的微服务都可以遵循这些标准。从一开始就让这个庞大组织的每个微服务都遵循高标准不是一件容易的事情，于是在我的同事 Rick Boone（他的微服务高标准为这本书带来了启发）的帮助下，我创建了一个详细的标准检查列表。我相信，Uber的每一个微服务在进入生产环境之前都应该遵循这些标准。
我们需要提炼出一系列原则，并提出具体的要求。后我们提出了 8项原则： Uber的每个微服务都应该具备稳定性、可靠性、伸缩性、容错能力、高性能、可监控、文档化和灾备能力。每个原则都包含了具体的标准，这些标准对每个原则的具体含义进行了定义。重点是，我们要求每个原则都可以被量化，量化结果有助于提升微服务的可用性。如果一个微服务满足了这些标准和要求，我们就说它是生产就绪的。
如何在团队里高效地推行这些标准是接下来要做的事情。我建立了一个流程，对于关键性业务服务（这些服务的中断会拖垮整个应用），SRE团队需要在团队间展开架构评审，收集审计反馈（关于每个服务是否满足生产就绪要求的检查列表），创建详细的路线图（把微服务带向生产就绪状态的详细指南），并为每个服务的生产就绪程度打分。
架构评审是整个流程中为重要的部分：所有相关的开发人员被聚集到一个房间里，他们被要求在 30 min或更短的时间内在白板上画出服务的架构图。我的团队和开发人员可以快速地定位问题。当把微服务和所有相关元素（端点、请求消息流、依赖项等）都画在一起时，每一个故障点都会变得清晰可见。
架构评审卓有成效。每次评审之后，我们会核对检查列表，看看服务是否满足生产就绪要求，然后把结果分享给开发团队的经理和开发人员。我发现，在对服务进行生产就绪评估时，简单的生产就绪与否不足以准确地反映评估情况，所以我们加入了打分机制。每一项要求都对应一个分数，这些分数后汇总成总分。
审计之后是创建路线图。路线图包含服务未能满足生产就绪要求的列表项，以及近期发
生的中断情况、改进措施的描述、任务链接，以及相关开发人员的名字。
在做完这个流程（也被称为“ Susan Flowler的生产就绪流程即服务”）的生产就绪检查之后，下一步是对整个流程进行自动化，以便让 Uber所有的微服务持续地执行这个流程。在写这本书的时候，无畏的 Roxana del Toro正领导着他的 SRE团队对整个流程进行自动化。
生产就绪标准里的每一项要求和实现细节都是我和我的 SRE同事们经过无数个小时的细心工作才总结出来的。我们做了大量笔记，有过无数次的讨论，对微服务的方方面面（它们零零散散，有的领域甚至是一片空白）进行了全面调研。我与 Uber和其他公司的微服务开发团队进行过交流，讨论如何对微服务进行标准化，看看是否存在一组标准原
则可以应用在任意的微服务上，并对业务产生可量化的影响。这本书就是基于这些笔记、
讨论、会议和调研而写的。
在与旧金山海湾地区其他公司的网站可靠性工程师和软件工程师进行交流之后，我才知道，在 SRE领域，乃至整个技术行业，这都是一件非常有意思的事情。当有工程师向我询问微服务标准化和构建生产就绪微服务的相关问题时，我可以给他们提供建议，于是我写了这本书。
在写这本书的时候，关于微服务标准化的资料很少，关于如何构建和维护微服务生态系统的指南也很少，而当那些对单体应用进行微服务拆分的工程师问起“下一步我们该怎么办”时，更是没有一本书能够解答这个问题。我写本书的目的就是希望能够填补这些空白，并解答这个问题。当初我开始着手对 Uber进行微服务标准化的时候是多么希望能有这样一本书啊。
这本书为谁而写
这本书主要是为微服务软件工程师和网站可靠性工程师而写的，他们要么苦于不知道该如何对单体系统进行分解，要么正在着手构建新的微服务，并希望能够构建出稳定的、可靠的、可伸缩的、容错的、高性能的微服务。
不过，书中所提及的相关原则不仅限于以上读者。大部分原则都可以被用于改进任何大小和任意架构的服务和应用。工程师、工程经理、产品经理和公司的高管都会从本书中获益，他们可以借此为他们的应用制订标准，从架构决策中理解组织结构的变更，或者把它们作为推动组织架构演变和运营的指南。
我假设读者对微服务的基本概念、微服务架构和现代分布式系统基础都有所了解，对于已经掌握了这些概念的读者来说，他们可以从书中获得更大的价值。对于还不熟悉这些概念的读者，我在本书的第 1章专门对微服务架构、微服务生态系统、微服务给组织带来的挑战，以及将单体应用拆分成微服务的本质进行了描述。
如何定位这本书
这本书不是关于“如何做”的指南手册：它并没有为每一章所涉及的内容提供任何教程。如果要把它们写成教程，可以写出很多卷，因为每一章的内容都可以写成一本书。
所以，这是一本高度抽象的书，它具有很强的通用性，书中的内容几乎可以被应用于任何一家公司的任意一个微服务上。不过它也足够细致，工程组织可以把它作为切实可行的指南，用于改进和标准化微服务。每个公司的微服务生态系统都各不相同，遵循命令式或填鸭式的步骤指南没有任何意义。所以，我强调的是概念，解释了它们在构建生产就绪微服务方面起到的重要作用，并为每个概念提供示例和实现策略。
当然，这本书不是一本关于如何构建微服务和微服务生态系统的百科全书。首先，我得承认，构建微服务和微服务生
评论
还没有评论。