如何调试分布式系统：与微服务调试工具“Squash”创始人 Idit Levine 的对话

本文要点

• 在开发与生产中，对应用的监控和调试能力非常重要。相对于调试单体应用，调试基于微服务的应用更具挑战性，因为难以将一个原生调试器附着于通过整个网络通信的多个进程上。
• 当前，调试微服务的最好方法依赖于获取对所有事物和依赖的追踪情况，其中需要使用一些工具，例如实现 OpenTracing API 标准的工具。这些工具可以捕获时间、事件时间和标签，并（异步地）收集带外关联数据。
• OpenTracing 类工具非常强大，但是此类工具也有其局限性和未尽之处。由于在运行时记录应用状态的日志可能代价高昂，并导致一些性能开销，我们需要限制所采集的信息量。
• Squash 是一种开源的微服务调试工具。它编排附着于微服务上的运行时调试器（在部署到 IaaS 或 CIaaS 中的容器中运行），并提供一些为开发人员所熟悉的特性，例如设置断点、跳过代码段、查看并修改代码等。
• 我们应该为分布式应用提供与单体应用相同的可观察性和控制级别。对于集成这类可观察性，例如记录日志、追踪和进程中调试，服务网格可能是最适用的技术。

近期，InfoQ 与 solo.io 的 CEO Idit Levine 进行了一次座谈。Idit 新创立了一种开源微服务调试器，称为“Squash”。在此次座谈中，她介绍了观察和调试分布式系统和应用中的挑战。

InfoQ： Idit，您好，欢迎来到 InfoQ！请您做个自我介绍，并简单介绍一下您的新创企业 solo.io ？

Levine：Daniel，你好，感谢邀请。我是 solo.io 的创始人和 CEO。solo.io 以简化云技术栈为主要宗旨。自从我作为首批员工加入 DynamicOps 以来，我已经从事云管理领域工作近 12 年（DynamicOps 是开发 vCAC 的公司，之后被 VMware 收购）。

最近，我出任 EMC 云管理部门的 CTO。在 EMC，我领导、设计并实现了项目 unik 及 layer-x 项目，前者是一种自动化 Unikernels 编译和部署的开源平台，后者是一个实现跨集群调度的开源框架。

尽管 solo.io 目前处于隐秘运行阶段（stealth mode），但是我对开源社区依然秉持一如既往的承诺。这就是为什么我们近期推出了 Squash 。Squash 是一个用于调试微服务应用的开源平台。我们计划改进 Squash，并在不远的将来为社区提供其它一些有价值的工具。

InfoQ： 您能简要介绍一下近五年中运维和架构监控的发展情况吗？云、容器和新架构类型微服务如何影响着监控和调试？

Levine：在开发和生产中，监控应用的状态是十分重要的。对于单体应用，问题非常直观，因为我们可以将原生调试器附着于那些获取应用状态及其整体演进情况的进程上。

监控基于微服务的应用向我们提出了更大的挑战，尤其是当应用是由成百上千的微服务组成时。由于事实上任何请求可能被多个微服务运行多次处理，甚至可能在不同的服务器上，因此要跟上应用发展的“脚步”，并在出现问题时识别导致问题的原因，实现困难是指数级别的。

当前，主要的解决方法是依赖于一些工具对所有事务和依赖进行追踪，例如实现 OpenTracing API 标准的工具。这些工具捕获时间、事件和标签，并（异步地）收集带外数据。OpenTracing 支持用户执行关键路径分析，并识别由于共享资源所导致的瓶颈。用户也可以对他们认为有用的数据记录日志，例如不同变量的值、错误消息等。

InfoQ：作为一种支持在 IDE 中调试运行于容器编排上微服务应用的工具，我们一直在关注 Squash 的发展。我们十分希望了解该项目的目标，以及创建该项目的合理性。

Levine：OpenTracing 类工具非常强大，但是此类也有其局限性和未尽之处。由于在运行时记录应用状态的日志可能代价高昂，并导致一些性能开销，我们需要限制所采集的信息量。一种做事方法是跟踪事务的一个子集，而非全部事务。对采集样本的规模做调优，是在采集信息量和性能与支出代价这两个方面间的权衡。

这样做会产生一个后果，就是在识别问题中可能会缺失部分所需的信息。而获取这些信息，需要再次运行应用，并等待采集数据。进一步讲，OpenTracing 并非一种运行时调试器，它不允许在运行时更改变量，去探索对问题的可能解决方案。任何试图修复问题的努力，都需要包裹代码、运行应用，并再次等待数据。要解决问题，我们可能必须做多次这样的迭代。这一做法令人望而却步，并且代价高昂。

我们希望 Squash 能补充 OpenTracing 工具的不足之处。Squash 的主要目标是提供一种调试微服务应用的高效工具。Squash 编排附着于微服务上的运行时调试器，提供一些开发人员所熟悉的特性，例如设置断点、跳过代码段、查看并修改变量等。更重要的是，Squash 运行开发人员可以无缝地跟踪应用，并在微服务间跳跃。Squash 负责所有必须的管道，使得开发人员可以聚焦于自身的代码，并解决他们切实关注的问题。Squasl 可与一些广为采用的现有 IDE 集成，可使得 Squash 易于访问和采用。

Squash 在设计就是为监控应用的生命周期提供必要的能力，不仅在开发阶段支持开发稳健的代码，而且在生产阶段支持在出现难题时快速采纳代码。

InfoQ：Squash 的未来规划是什么？

Levine：我们认识到，Squash 可以借助于服务网格（例如 Istio ）和代理（例如 Envoy ）技术，支持在不暂停整个服务的情况下调试在网格中运行的应用。鉴于此，我们刚刚官方推出了用于 Envoy upstream 的 Squash http Enovy 过滤器。下一步，我们将与 Istio 团队合作，配置 Squash 项目使用 Istio。

我们也收到了社区对集成 Squash 到更多平台的请求，例如 Mesos 和 Docker Swarm。我们还希望能与 Cloud Foundry 集成。我们已添加了对更多调试器的支持，例如 Java、Node.js 和 Python。最后，我们期待能支持更多的 IDE，包括 IntelliJ IDEA 和 Eclipse。

此外，我们正与 OpenTracing 社区的牵头人接洽，意在将 OpenTracing 集成到 Squash 中。这将使用户可以通过 OpenTracing 识别并放大两个服务间的延迟，进而使用 Squash 解决问题。

InfoQ： 您谈及了 Unikernels，我们希望您能就该技术的未来地位发表看法。Bryan Cantrill 有一句著名的论断，即 Unikernels 不适用于生产环境，也是完全不可调试的。您对此怎么看？

Levine：我相信 Unikernels 将在未来占有重要的一席之地，尤其是在 IoT 领域。Unikernels 在轻量级踪迹、安全、性能等方面的优点非常适用于 IoT 设备，因为 IoT 设备的存储有限，用户希望其中加入的代码最小化，而非一个面面俱到的操作系统。

我相信对于构建和运行 Unikernel，unik 是一种非常棒的编排工具。从 GitHub 代码库上的流量统计和克隆数来看，社区也持有相同的看法。我很高兴看到人们在使用 unik。下一步，我希望进一步扩展 unik，使其不仅仅是一个 Unikernel 工具，而且支持 Kata Containers 、 LinuxKit 、 FreeRTOS 以及其它一些 IoT 嵌入设备软件。

Bryan 的论断完全正确，只有在提供了用于 Unikernels 的监控和调试工具的情况下，Unikernels 才能用于生产环境。当前，尚未具有此类工具。

在构建 unik 时，必须要调试 Unikernels。我们是使用 gdb 调试器实现的。鉴于此，我能证明调试 Unikernels 是完全可以做到的，但也是非常难以做到。

我认为，如果社区认可 Unikernels 的巨大潜力，那么就应该对创建可自动化并简化该过程的新工具上做出一些投资。例如，Squash 已经使用了 gdb 等调试器，因此可以通过扩展 Squash 为调试 Unikernells 提供帮助。

InfoQ： “无服务器”技术正日益流行。Squash 等工具是否同样可用于调试其中部署的应用和函数？

Levine：当然可以！事实上，我们一开始就考虑 Squash 将作为一个调试无服务器应用的工具。但是，目前大多数运行无服务器应用使用的是公开 FaaS 云平台，也确实应该这样做，因为 FaaS 是当前最成熟的产品。这样的平台避免了用户端的复杂性，但是同时也带走了控制性和灵活性。

用户对函数运行的环境并没有控制力和访问力。这的确限制了社区在无服务器领域的创新能力，并迫使社区为解决这些局限性而推出了一些技巧（hack）和“创造性”的解决方案。我对技巧并没有兴趣。进而，在构建 Squash 时，我们优先考虑为我们提供可插入关联的平台。

InfoQ：在您看来，在理解和调试大规模的、快速演进的基于容器应用中，开发人员还将需要哪些工具？

Levine： 作为一个社区，我们应该为分布式应用提供同等于单体应用的可观察性和控制级别。组合使用已有工具，为我们指出了一种正确的方法。其中，日志采集可以使用 OpenTracing 工具完成，度量可以使用 Prometheus 采集，调试由 Squash 完成。所有这些方法，应该以插件的形式加入到服务网格中，实现完全高效。

InfoQ： 从系统的可观测性和可调试性方面看，您认为 QA 和测试人员有哪些职责？

Levine： 就一种可能的行动模式而言，我期望 QA 和测试人员聚焦于日志，并提供上下文。对于基于容器的应用，可以使用 OpenTracing 实现。开发人员可重新生成软件缺陷，并使用 Squash 添加调试器、跳过代码段，并解决问题。

InfoQ：再次感谢您抽出时间与我们座谈。您是否还有更多想要和 InfoQ 作者分享的？

Levine：在 solo.io，我们致力于构建一些更加开源的工具，为微服务的开发和运维提供便利。具体而言，我们聚焦于一些创新性并功能强大的工具，加速微服务在企业中的采纳。我们对 2018 年规划干劲十足。拭目以待吧！

在 solo.io 的官方网站上，提供了更多信息， Squash 微服务调试器开源提供于 GitHub 上。

被访者简介

Idit Levine 是 solo.io 的创始人和 CEO。solo.io 是一家位于波士顿的初创企业，以精简云技术栈为企业宗旨。Idit 已在云管理领域深耕 12 年，她具有大型企业和初创企业的经验。最近，Idit 出任 EMC 云管理部门的 CTO，并是 EMC 全球 CTO Office 的成员。她和她的团队成员成功推出了一个用于跨集群调度的自动化 Unikernels（UniK）开源项目“layer-x”。在 solo.io 方面，Idit 近期发布了用于调试微服务应用的开源平台 Squash。

查看英文原文： Debugging Distributed Systems: Q&A with the “Squash” Microservice Debugger Creator Idit Levine