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

系统架构

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

作者： Daniel Bryant

正文：

本文要点

• 在开发与生产中，对应用的监控和调试能力非常重要。相对于调试单体应用，调试基于微服务的应用更具挑战性，因为难以将一个原生调试器附着于通过整个网络通信的多个进程上。

• 当前，调试微服务的最好方法依赖于获取对所有事物和依赖的追踪情况，其中需要使用一些工具，例如实现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