案例研究：

使用 OpenTracing 帮助查找瓶颈

去年秋天，MacLeod Broad 在 Workiva 的平台团队在准备该公司的首批产品之一，当遇到障碍时就使用 Amazon Web Services 。

早期，Workiva 的后端主要运行在Google App Engine上。但随着 Workiva 的 SaaS 产品，Wdesk，一种基于云的管理和报告业务数据平台，将客户群增长到财富 500 强公司的 70% 以上，情况发生了变化。“随着客户需求的增长和产品供应的扩大，我们开始利用更广泛的服务，如 Amazon Web Services 以及其他 Google Cloud Platform 服务，从而创建一个多供应商环境。” 有了这个新产品，具备“同步和链接”功能，通过它，数据“经历了一大堆服务，从新的电子表格系统[Amazon Aurora]到我们所谓的链接系统，然后通过 http 推送到我们现有的系统，然后进行一些计算，结果将传回新系统，”Broad 说。“我们当时进行优化是为了速度。我们认为做了这种极好的优化，然后它会变成一个微观优化，这并没有真正影响系统的整体速度。”

Broad 团队面临的挑战听起来可能为其他公司所熟悉，这些公司也从单体系统转向更分散的基于微服务的系统。Broad 说：“我们有许多人从事这方面的工作，他们都在不同的团队中，因此很难了解问题是什么以及瓶颈在哪里。”

“每个服务团队都经历着不同的架构迭代，很难了解每个团队系统中的实际内容，”他补充道。“我们有循环依赖关系，其中有三个或四个不同的服务团队不确定问题的真正位置，需要大量的来回沟通。因此，我们浪费了很多时间说，‘这个哪一部分比较慢？根据应用场景的不同，哪一部分有时很慢？随着时间推移，哪一部分会逐渐变慢？这个进程的哪一部分是异步的，因此，它是否长时间运行并不重要？我们在做的哪些是多余的，其中哪一部分是错误？’”

简而言之，它是跟踪的理想用例。Broad 说：“跟踪系统可以一目了然地解释体系结构，缩小性能瓶颈并归零，通常只是帮助在高级别指导调查。”“一眼就能做到这一点，比在会议或三天的调试中要快得多，而且比从不找出问题得过且过要快得多。”

Workiva 的后端代码在 Google Compute Engine 、App Engine 和 AWS 上运行，Broad 知道他需要一个与平台无关的跟踪系统。“我们正在研究不同的追踪解决方案，”他说，“我们决定，由于市场似乎是一个不断发展的市场，我们不想被一个供应商卡住。因此，OpenTracing 似乎是避免供应商限制我们实际使用的后端的最简捷方法。”

Broad 说，一旦他们将 OpenTrace 引入到第一个用例中，“跟踪使得瓶颈所在位置变得非常明显。”尽管每个人都认为是 Workiva 的现有代码减缓了速度，但事实并非如此。Broad 说：“看起来现有代码速度很慢，只是因为它能够达到到我们下一代服务的水平，而且它们需要很长时间才能处理所有这些请求。”“在瀑布图上，你可以看到每个请求在得到响应时所做的完全相同的工作。因此，对于被分页的每个响应，每个服务请求看起来都完全相同。然后，就不用费神去思考‘为什么它再次做所有这些工作？’”

使用 OpenTrace 的跟踪功能，“我的团队能够查看跟踪，并针对另一个团队提出优化建议，而无需查看他们的代码，”Broad 说。“我们命名跟踪的方式可以说明请求是执行 SQL 调用还是创建 RPC。因此，可以非常简单地说，‘好吧，我们知道它能处理所有这些请求。处理一次缓存一次。’我们基本上完成了。所有这些调用立即变成了亚秒级的调用。”

在第一个用例成功后，参与尝试的每个人都回去重新编排了他们的产品。跟踪功能已添加到几个更多的用例中。Broad 说：“我们希望尽早度过最初的实施难关，而不会让整个部门一起渡过难关。”“现在，许多团队在启动新服务时添加它。我们现在确实比以前更将推动采用。”

一些团队很快就赢了。软件工程师 Michael Davis 说：“跟踪让我们能够立即了解如何改进我们的（工作空间）服务。通过查看每个调用的花费时间以及最常使用哪些调用的组合，我们能够在单个修复中将平均响应时间减少 95%（从 600ms 到 30ms）”。

Workiva 的大部分主要产品现在都使用 OpenTracing 进行跟踪，将数据推送到 Google StackDriver。即使未完全使用跟踪功能的产品，也具有一些组件和库。

Broad 指出，由于一些工程师正在使用 App Engine，并且已经拥有平台的 Appstats 库分析性能的经验，因此他们不需要花太多时间才能习惯使用 OpenTracing。但其他人则有点不情愿。“我认为，使用 OpenTracing 的最大障碍是担心引入跟踪和 StackDriver 的成本会是多少，”他说。“人们也非常关心将中间件添加到他们正在处理的任何内容中。有关传递上下文以及如何完成这些工作的问题很常见。我们的许多 Go 开发人员对此都很好，因为他们已经以这样或那样的形式这样做了。我们的 Java 开发人员并不热衷于这样做，因为他们使用了其他不需要该功能的系统。”

但好处显然超过了人们的担忧，而今天，Workiva 的官方政策是使用追踪。 事实上，Broad 认为跟踪天然符合 Workiva 现有的日志记录和指标系统。“这是我们在内部展示的方式，也是我们设计使用方式的方式，”他说。“我们的跟踪记录在与我们的应用指标和日志记录数据完全相同的机制中，并且它们被推送的方式完全相同。因此，在创建和记录所有数据时，我们对待这些数据完全一样。我们有一个内部库，用于日志记录、遥测、分析和跟踪。”

对于 Workiva，OpenTracing 已成为一种重要工具，通过观察使用模式来聚焦最佳优化和确定什么是微观优化。Broad 说：“在某些项目中，我们经常假设客户正在做什么，我们针对这些疯狂的测试案例进行优化，这些案例的 1% 是同用户实际非常相符的。”“这样是非常有益的，‘好吧，我们在每个执行 X 的请求上添加 100 毫秒，如果最坏的情况，我们也只需要添加 100 毫秒，这仅发生在千分之一的请求或一百万个请求中的一个。’”

与许多其他公司不同，Workiva 还跟踪客户端。Broad 说：“对我们来说，用户体验很重要，如果 RPC 执行后还需要 5 秒才能在浏览器中显示，则 RPC 执行需要 100 毫秒就不重要了。”“因此，对于我们而言，这些客户端响应时间非常重要。我们跟踪它，看看加载的哪些部分需要很长时间。我们正在研究什么是“加载”的定义。是当你访问到它，还是当它被渲染时，或者当你可以与它交互时？我们计划使用跟踪来关注和更好地了解这些内容。”

这还需要根据外部和内部时钟的差异进行调整。“在时间纠正之前，这是非常恐怖的；我们的跟踪比什么都更具有误导性，” Broad 说。“因此，我们决定在响应标头上返回一个时间戳，然后让客户端根据该时间调整其时间，而不是更改其内部时钟，而只需计算客户端收到时响应时间的偏移量。如果最终出现一种不可能的情况，客户端的 RPC 调用持续了 210 毫秒但响应返回时间并不在这个范围内，那就必须得重新调用请求。”

Broad 对 OpenTracing 对公司产生的影响感到兴奋，并且也在展望该技术还能实现什么。一种可能性是使用跟踪实时更新文档。他表示：“使文档与现实保持同步是一项重大挑战。”“例如，我们刚刚运行了跟踪模拟，或者我们刚刚在此新部署上运行了烟雾测试，但是结果显示架构与文档不匹配。我们可以找到是谁的责任，并通知他们进行更新。这是我希望在未来通过追踪获得的功能之一。”