新書推薦：
《
小欢喜2：南京爱情故事
》
售價：HK$
75.9
《
分解工作法：聪明人如何解决复杂问题
》
售價：HK$
65.8
《
翡翠鉴赏（全彩珍藏版）
》
售價：HK$
75.9
《
艺文志·石川啄木：日本的第一个现代人
》
售價：HK$
74.8
《
DK葡萄酒大百科：一本关于葡萄酒的百科全书
》
售價：HK$
547.8
《
未来简史 从智人到智神（2025白金纪念版）
》
售價：HK$
86.9
《
社区矫正（第六版）：美国地方治理的新议题及其比较
》
售價：HK$
107.8
《
动物与人体的比较解剖书
》
售價：HK$
98.8
|
| 內容試閱：
|
|
前言如果你正在阅读本书，那么你可能对分布式追踪的字面意思已经有些想法了。你可能也不知道它们代表什么，我们只知道，你是长鼻袋鼠（封面上的动物）的粉丝。我们保证不评判你的身份，一视同仁。不管怎样，阅读本书是为了深入了解分布式追踪，以及如何运用它了解微服务和其他软件的性能和操作。考虑到这一点，我们从简单的定义开始。分布式追踪（也称为分布式请求追踪）是一种相互关联的日志记录，可以帮助你可视化运行中的分布式系统，以便做性能分析、在生产环境中调试，分析故障或其他问题的根本原因等。它使你能够准确地了解定的服务在整体中发挥的作用，从而询问和回答有关服务和整个分布式系统性能的问题。非常简单，下本书见！什么？为什么每个人都在要求退款？呃……我们被告知你需要的不止这些。好吧，我们再谈谈软件，别是分布式软件，以便更好地理解分布式追踪能解决的问题。分布式架构和你开发、部署、运维软件的艺术和科学在不断变化。多年来，随着硬件和软件的更新，极大地扩展了应用程序的边界。虽然这里有一个有趣的题外话，如何“起死回生”，但为了简洁起见，我们把重点放在过去20 年左右的变化上。在虚拟化和容器化兴起之前，如果你想部署某种基于网络的应用程序，你的应用程序需要一台专用的物理服务器。随着应用程序的流量上升，你需要增加服务器的物理资源（例如增加内存），甚至需要新增几台服务器，每台服务器上都运行一份应用程序的副本。在单体服务器进程中，这种横向扩展往往会在成本、性能、公司开销之间形成不利的局势。运行多个服务器实例意味着你要复制服务器的所有功能，而不是独立地扩展各个子组件。在传统基础设施中，你经常被迫决定，在带来额外容量的同时，你可以接受多少分钟（或几小时）的性能低谷，服务器的运行成本不小，所以如果没有必要，为什么要在峰值容量下运行？最后，随着你的应用程序规模、复杂性、开发人员的增加，测试和验证变更变得越发困难。随着公司的发展，开发人员掌握整个代码库将成为历史，更不用说整个系统了。越来越小的变更增加了涟漪效应的概率，当它们的影响从一个组件辐射到另一个组件中时，就会导致整个应用程序宕机。不过，随着时间推移，这些问题已经迎刃而解了。抽象出如虚拟物理硬件细节的软件，从而将物理服务器拆分为多个逻辑服务器。Docker 和其他容器化技术扩展了这一概念，为更重的虚拟机提供了一个轻量级、用户友好的抽象，将“谁来部署软件”的问题从运维转移到了开发者。云计算的普及，以及其按需增加资源的概念解决了资源扩展的问题，因为只需要点击一个按钮就可以增加定服务器的内存或CPU 核心数量。最后，微服务架构的想法出现了，通过围绕松散耦合的独立服务构建大型应用，解决了越来越大和越来越复杂的面向软件的业务所带来的复杂性。当今大多数应用程序都是以某种形式分布的分布式应用，即使它们没有使用微服务架构。一个简单的客户端服务器应用程序就是分布式应用，一个经典问题是，“调用服务器超时，是响应丢失，还是服务器还在运算？此外，它们可能有各种分布式依赖关系，例如云提供商的数据存储服务，或者提供从分析到推送通知等各种服务的第三方API 主机。为什么分布式软件如此受欢迎？分布式软件的征非常明显：可扩展性分布式应用程序响应需求更简单，扩展效率更高。例如，如果有很多人登录你的应用程序，你就可以只扩展登录服务。可靠性一个组件的故障不应该导致整套应用程序崩溃。分布式应用程序更有弹性，因为它们通过各种服务进程和主机分割功能，确保即使一个依赖服务离线，也不会影响应用程序的其余部分。可维护性分布式软件更容易维护，有以下几个原因。服务彼此分离，可以使其专注于一组较小的责任，进而提高每个组件的可维护性。此外，你可以更加自由地增加性和功能，而不需要自己实现（和维护）它们。例如，通过依赖某些云提供商的语音转文本服务在应用程序中添加语音转文本功能。就分布式架构的好处而言，这些只是冰山一角。当然，并不全是阳光和玫瑰，生活中也会有小雨……深层系统软件架构师们经常说的深层系统，主要示例就是分布式架构。[1] 这些系统之所以引人注目，不是因为其广度，而是因为其复杂性。如果考虑分布式架构中的某些服务或服务类别，你应该能够识别出其中的区别。缓存节点池的扩展范围很广（例如，你只添加更多的实例处理需求），但其他服务扩展的方式不同。请求可能会穿过三层、四层、十四层或四十层不同的服务，并且每个层可能都有你不知道的依赖。即使你的服务相对简单，你的软件可能也会依赖他人编写的代码、或者依赖云供应商提供的托管服务，甚至依赖管理其状态的底层编排软件。最终深层系统的问题还是人的问题。对于一个人，甚至一组人来说，即使只是了解单个请求关键路径上的服务并维护，很快都会变得不切实际起来。图1 是你作为服务所有者可以控制的范围和隐性的责任范围。这种微积分模型导致了运维压力和加班，因为你被迫与其他服务所有者处于被动状态，不停地救火，并试图弄清楚你的服务之间是如何交互的。我们需要重新想办法去理解分布式架构软件的健康状况和性能。简单地查看堆栈追踪或观测 CPU 和内存利用率图表不足以说明问题。随着软件规模的扩张——深度和广度，如果仅靠日志和指标这样的遥测数据，它们就不能提供快速定位生产故障所需的清晰度。理解分布式架构的难点扩展你的软件的同时，带来的是令人兴奋的新挑战。一时之间，故障和崩溃都变得更加难以捉摸。你负责的服务可能正从你无法控制的来源，接收错误的格式或意料之外的数据，因为管理该服务的是地球另一端的团队（或一个远程团队）。你认为坚如磐石的服务出现故障，突然在你的所有服务中发生连带的故障和错误。借用推上的一句话，你的手上有一个微服务连环凶杀谜案（见图2）。让我们在延伸一下这个比喻，监控有助于找出尸体的位置，但它不能揭示谋杀的原因。分布式追踪为以下三个主要难点提供了解决方案，以便你能轻松地理解整个系统，从而填补那些空白：混沌状态随着应用程序分布的越来越广，故障的一致性开始降低。也就是说，因果之间的距离变大了。云供应商的文件存储服务中断可能会导致每个服务都发生巨大的级联延迟，或者在多次跳转后的定服务中出现一个难以诊断的故障，这阻碍了你定位故障的根本原因。不一致性分布式应用程序在总体上是可靠的，但单个组件的状态却远不如它们在单体或非分布式应用程序中的一致性。此外，由于分布式应用程序的每个组件都设计得十分独立，所以导致这些组件的状态会出现不一致。例如，当有人部署服务时会发生什么情况？其他组件是否知道该做什么？这对整个应用程序会造成什么影响？无法归一根据定义，与服务性能有关的关键数据是离散的。当一个服务在几百个主机上有上千个副本在运行时，你如何定位该服务的故障？你如何将这些故障关联起来？分布式应用程序的最大优势也是理解其实际运作方式的最大阻碍！如此一来，你可能也会不禁问道，“我们应该怎么解决这些困难？”剧透一下：分布式追踪。分布式追踪提供了什么帮助？分布式追踪以核心工具的姿态出现，管理深层系统正在爆炸的复杂性。它提供跨请求生命周期的上下文，以此描绘系统架构之间的交互和轮廓。不过，这些个别的追踪数据仅仅只是开始。总的来说，追踪数据可以为你提供与分布式系统相关的实际运行状态，让你不仅可以关联服务的数据（例如，大多数错误都发生在一个定的主机或定的数据库集群中），还可以过滤、排序其他遥测类型的重要性。实际上，分布式追踪数据所提供的上下文帮你缩小了问题的范围，与你的调查的内容相关，你因此避免了猜测，也不用再去检查更多的日志和仪表盘。这种方式的“分布式追踪”实际上是现代可观测平台的核心，它是分布式架构的关键组件之一，而不是某个外部单点工具。什么是追踪？最简单的理解方式是，从请求的角度考虑软件。每个组件都在做响应其他服务请求（也称为RPC，远程过程调用）的某种工作。可能是某个普通的网页从服务端点请求一些结构化数据呈现给用户，也可能是某个高度并行的搜索过程。工作的实际性质并不重要，尽管我们会在后面讨论一些适合于某些风格的追踪模式。虽然分布式追踪可以在大多数分布式系统中发挥作用，正如我们在第4 章中讨论的那样，但其优势在模拟服务之间的RPC 关系上，表现非常亮眼。除RPC 关系外，考虑一下每个服务的工作。也许它们正在验证授权用户角色、执行数学计算，或者只是将数据从一种格式转换为另一种格式。这些服务通过RPC相互通信，发送请求、接收响应。不管它们在做什么，这些服务的共同点是：它们所执行的工作都需要一定的时间。图3 说明了服务和RPC 的基本模式。我们把每个服务所做的工作称之为span（跨度），就像工作需要花费的时间跨度一样。这些span 可以用元数据（属性或标记）和事件（也称为日志）来注解。服务之间的RPC 通过模拟请求的性质、顺序的关系来表示。这种关系通过追踪上下文传播，追踪上下文指有唯一标识符的追踪数据及其内部的所有span。服务各自创建span 数据然后将其转发到一些外部进程中，那些外部进程会将span 聚合到追踪数据中，分析，进而获取更多关键信息，然后存储起来，用于后续的分析。图4 是一个简单的追踪示例，显示了两个服务之间的追踪数据，以及第一个服务内部的子追踪。分布式追踪能把调用所经过的所有服务的逻辑请求过程展示为一个统一的逻辑请求链，这缓解了分布式架构中的混沌状态。在分析、呈现指定的业务逻辑的执行过程时，它确保所有相关的数据都是耦合的。它允许使用定的API 或其他路由的服务间关系查询，解决了一致性问题，继而你可以提出诸如“当其他服务关闭时，我的API 会怎么样？”这样的问题。最后，它提供一种方法，确保进程可以独立地向收集器贡献追踪数据，以便收集器后续聚合所有追踪数据，这样就解决了无法归一的问题，从而可视化请求，并理解跨多个数据中心、区域或其他分布的请求。考虑到这些，你能用分布式追踪做什么呢？分布追踪理解分布式系统的关键因素是什么？我们整理了一些真实案例，如下所示：? 一家以交易邮件和发送消息作为主要业务的公司，后端实现了分布式追踪，其中包括追踪对Redis 的调用。追踪数据很快显示出系统中存在不必要的Redis 循环调用，原因是从缓存中拉取的数据比实际需要的多。删除这个不必要的调用后，该公司发送邮件的时间可以减少100~1000 毫秒。这相当于每发送一封电子邮件的时间减少了大约85%，这是针对一个每天发送超过10 亿封电子邮件的平台！公司不仅能够发现不必要的调用，还能够验证删除它对其他服务的影响，并量化工作的价值。? 一家工业数据公司在使用了分布式追踪数据后，他们能够在主数据库负载超过基线的期间，轻松比对这些请求。查看聚合统计的相关性能的历史数据，分析事故期间单个请求的上下文，如此一来，大幅缩短了定位事故根本原因所需的时间。? 一家以健康和健身业务为主的公司，应用程序中添加了分布式追踪。当他们分析文档数据库的性能时，工程师能够找出可合并的重复调用，通过提高代码效率，减小了应用的延迟。? 一家视频交付平台使用分布式追踪排除了系统依赖的托管服务产生的延迟问题。比服务供应商更快更积极地找出 Kafka 云服务的管道问题，从而对事故做出快速反应，并恢复所需的性能。以上这些只是一部分用户案例，分布式追踪同时证明了在团队中产生的价值，这些团队试图通过测试管道的可见性、Google 的全局搜索技术，以及开源项目的基石诸如OpenTelemetry 这样的项目，更好地理解持续集成系统。那么现实的问题是：什么是分布式追踪？分布式追踪和你分布式追踪是理解分布式软件的一种方法。这解释就好比说：水是湿的，虽然帮助不大，但也没什么错。事实上，理解分布式追踪最好的办法是：看它在实践中的表现，这也是本书的来源！在接下来的章节中，我们会覆盖三个要点，只有掌握这些要点，你才能在你的应用程序中实现分布式追踪，我们还会讨论一些解决分布式架构中的问题的策略。你会学到一些不同的埋点分布式追踪的方式，以及可供你使用的追踪、监控风格。我们会讨论如何收集埋点产生的所有数据，以及收集、存储追踪数据的各种性能考虑和成本。之后，我们介绍如何从追踪数据中创造价值，并将其转化为有用的运维信息。最后，我们对分布式追踪的未来做一些展望。在本书结尾时，你应该对分布式追踪的世界有所了解，并且掌握何地、何时、以及如何为你的软件实现它。最重要的，分布式追踪实践的目的是让你可以更容易的构建、运维、理解你的软件。我们希望本书中的经验教训可以帮助你在你的公司里构建下一代监控、可观测性实践。排版约定本书使用了以下排版约定。斜体（Italic）表示新术语、URL、电子邮件地址、文件名和扩展名。等宽字体（Constant width）表示程序片段，以及正文中出现的变量、函数名、数据库、数据类型、环境变量、语句和关键字等。粗体等宽字体（Constant width bold）表示应由用户原封不动输入的命令或其他文本。等宽斜体（constant width italic）表示应该由用户输入的值或根据上下文确定的值替换的文本。代码示例补充材料（代码示例、练习等）可在GitHub（https://github.com/distributedtracing-in-practice）上下载。如果有技术问题或代码示例出现问题，请发送邮件至 bookquestions@oreilly.com。本书是要帮你完成工作的。一般来说，如果本书提供了示例代码，你可以把它用在你的程序或文档中。除非你使用了很大一部分代码，否则无需联系我们获得许可。比如，用本书的几个代码片段写一个程序就无需获得许可。销售或分发O’Reilly图书的示例需要获得许可，引用本书中的示例代码回答问题无需获得许可，将书中大量的代码放到你的产品文档中需要获得许可。我们很希望但并不强制要求你在引用本书内容时加上引用说明。引用说明一般包括书名、作者、出版社和ISBN，例如：“Distributed Tracing in Practice by Austin Parker， Daniel Spoonhower， Jonathan Mace， and Rebecca Isaacs with Ben Sigelman (O’Reilly). Copyright 2020 Ben Sigelman， Austin Parker， DanielSpoonhower， Jonathan Mace， and Rebecca Isaacs， 978-1-492-05663-8. ”。如果你觉得自己对示例代码的使用超出了上述许可范围，请通过permissions@oreilly.com 与我们联系。O’Reilly 在线学习平台（O’Reilly Online Learning）近40 年来，O’Reilly Media 致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。公司独有的专家和改革创新者网络通过O’Reilly 书籍、文章以及在线学习平台，分享他们的专业知识和实践经验。O’Reilly 在线学习平台按照您的需要提供实时培训课程、深入学习渠道、交互式编程环境以及来自O’Reilly 和其他200 多家出版商的大量书籍与视频资料。更多信息，请访问网站：https://www.oreilly.com/。联系我们任何有关本书的意见或疑问，请按照以下地址联系出版社。美国：O’Reilly Media， Inc.1005 Gravenstein Highway NorthSebastopol， CA 95472中国：北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035）奥莱利技术咨询（北京）有限公司勘误、示例和其他信息，请访问https://oreil.ly/distributed-tracing 获取。对于本书的评论和技术性问题，请发送电子邮件到errata@oreilly.com.cn。要了解更多O’Reilly 图书和培训的信息，请访问https://oreilly.com。我们的Facebook：http://facebook.com/oreilly。我们的Twitter：http://twitter.com/oreillymedia。我们的YouTube：http://youtube.com/oreillymedia。感谢Austin Parker别感谢O’Reilly 成就这本书的各位，编辑Sarah Grey， Virginia Wilson 和Katherine Tozer，不知疲倦地索引、修改、重绘，并确保内容适合页面的制作人员。感谢我们技术审查人员的见解和反馈，使得本书更加完善！我还要感谢 Ben Sigelman 以及其他Lightstep 的同事，谢谢你们的支持。事实上，没有你们，什么都没有。感谢我的父母，感谢我的父亲每天给我的灵感。我爱你们。还有我的妻子。团结，Austin。Daniel Spoonhower感谢Lightstep 支持Austin 和我完成这项工作的每一个人，别是那些回答我关于他们实施和使用追踪经验问题的人。感谢Bob Harper 和Guy Blelloch 帮助我理解清晰写作的价值（并且在截止日期之前给我一些写作实践）。我还要感谢我的家人为我寻求写书的时间。Rebecca Isaacs感谢同事的经验、建议和好主意，他们中的许多人对在生产环境中进行分布式追踪的效用寄予厚望。还要感谢Paul Barham 在追踪和分析分布式系统方面所富有的见解和智慧。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
