共计 1793 个字符，预计需要花费 5 分钟才能阅读完成。
信息架构的增长促使许多组织采纳云服务，并随着工夫的推移而增长。微服务在这方面始终处于领先地位，并且在设计各种应用程序以使其成为可独立部署的服务方面，其受欢迎水平呈指数级增长。第三方工具能够通过中断或暂停服务来帮忙 DevOps 团队设置不会影响调试过程执行的断点。
调试微服务对于工作人员来说仿佛令人生畏，而采纳正确的工具和策略能够使他们更轻松地发展工作。
信息架构的增长促使许多组织采纳云服务，并随着工夫的推移而增长。微服务在这方面始终处于领先地位，并且在设计各种应用程序以使其成为可独立部署的服务方面，其受欢迎水平呈指数级增长。
在 O ’Reilly 公司的一项考察中，50% 以上的受访者示意，他们组织中 50% 以上的新开发我的项目应用微服务。
在单片机零碎中，整个应用程序可能会因为模块中的单个谬误而失败。应用独立的模块为开发人员提供了更宽泛的灵活性，能够编辑和部署可定制的代码，而不用放心影响独立的模块。
然而，当意外引发谬误时，这种办法会带来独特的挑战。因为信息架构的复杂性以及从开发阶段到生产阶段的过渡，在云计算中调试微服务可能是一项艰巨的工作。
以下探讨一下面临的一些挑战以及如何无缝地应答这些挑战。
调试微服务的挑战
(1)追踪和可察看性有余
微服务需要的增长带来了基础设施的复杂性。每一个云组件、模块和无服务器调用通常都暗藏了基础设施的复杂性，这使得 DevOps 和经营团队很难依据输入跟踪和察看微服务的外部状态。独立运行的微服务难以跟踪异步模块中存在的任何用户申请，这可能会导致谬误的链式复制。这也意味着检测互相交互的服务可能会受到这些谬误的影响。这些因素使得查明任何谬误或谬误的根本原因对于开发人员来说是一项艰巨的工作。
(2)在简单环境中监督状态
因为许多微服务汇集在一起来构建零碎，因而监督其状态变得很简单。随着更多的微服务组件增加到零碎中，简单的服务网格逐步倒退，而每个模块都独立运行。这也带来了任何一个模块随时可能产生故障，但不会影响其余模块运行的可能性。
开发人员可能发现调试某些特定微服务中的谬误十分艰难。其中的每一个都能够用不同的编程语言进行编码，具备独特的日志记录性能，并且大多独立于其余组件。
(3)从开发到生产可能是不可预测的
在将代码从开发阶段挪动到生产阶段时，性能和状态谬误也是不可预测的。即便在集成和单元测试之后，人们也无奈预测代码在分布式服务器上解决成千上万个申请时的性能。如果代码扩大不充沛或者数据库无奈解决申请，那么开发人员简直无奈检测到零碎中的潜在谬误。
在云中调试微服务的办法
以下是一些特定于微服务的调试办法，这些办法能够帮忙组织解决以下提到的挑战：
(1)非侵入式调试选项
与传统的调试办法不同，第三方工具能够通过中断或暂停服务来帮忙 DevOps 团队设置不会影响调试过程执行的断点。这些办法是非侵入性的，容许开发人员查看全局变量和堆栈跟踪，这有助于他们更无效地监督和检测谬误。它还容许开发人员在不进行代码运行或重新部署其代码库的状况下测试可能呈现的无关问题。
(2)可察看性加强工具
任何具备大量 微服务 的零碎都很难跟踪申请。只管人们可能认为构建可察看性的自定义平台是解决这个问题的答案，但它在开发过程中会耗费大量的工夫和资源。
侥幸的是，许多古代的第三方工具旨在跟踪申请。并为微服务提供宽泛的可察看性。这些工具提供了很多性能，例如分布式和无服务器计算性能。
例如，Thundra 之类的工具能够帮忙组织监督生产过程中遍历其基础设施的用户申请，帮忙开发人员全面理解编码环境，查明谬误源头，并疾速调试。
(3)自治异样跟踪
对于零碎而言，首先要意识到发现错误是一项艰巨的工作。零碎必须主动跟踪产生的任何异样，从而帮忙零碎辨认反复模式或破坏性行为，例如平年谬误、浏览器中特定版本的谬误、奇数堆栈溢出等等。
然而，发现这些谬误只是胜利的一半。零碎还须要跟踪变量和日志，以查明谬误产生的工夫和条件。这有助于开发人员找到最无效的解决方案以打消谬误。全面的监督能够显著简化生产中的调试过程。
在云中调试不肯定很艰难
在古代微服务中，调试对任何人来说都是一个非常复杂的过程。跟踪用户申请和预测代码可扩展性的能力非常复杂。然而，古代工具能够使开发人员更容易地监督、检测和解决谬误。
采纳疾速部署的微服务架构设计，并且应用正确的工具集，对于开发人员来说，能够使其调试变得更加简略。
（文章来自企业网 D1Net，鸣谢）
