我们将使用一个无服务器应用程序的真实示例，并展示如何通过使用分布式跟踪来提高其可见性。
在60年代初，约瑟夫·卡尔·罗伯内特·利克利德（Joseph Carl Robnett Licklider）提出了通过Arpanet（互联网的前身）随时随地连接人和数据的想法。然后在90年代的旧时代，由于电信公司的广泛使用，网络和虚拟化开始普及。当公司可以通过共享资源削减成本时，这是革命性的。
从裸机到云的过渡和演进对于小型和大型企业组织都是令人兴奋的。在新千年的顶峰时期，亚马逊，谷歌，微软，IBM等供应商开始引入其托管云服务。IT经理开始考虑他们可以从本地迁移到云的速度有多快，甚至没有质疑云是否应该向他们迁移。
云计算带来了从基础架构和软件到功能即服务的一切现象。分别发生了IaaS，PaaS，SaaS，然后是CaaS，FaaS等，使用户可以管理更少的操作，并更加专注于他们的业务逻辑。雪球滚滚而来，并在2010年十年间成为对Containers的大肆宣传，然后引领了无服务器计算的道路。
无服务器时代
Serverless可以让您快速开发微服务，移动应用程序和API，同时具有成本效益且无需考虑服务器。这种新的云计算执行模型将利与弊的便利性提升到了一个新的水平。云应用程序的最大问题（例如可伸缩性和成本劣势）已变成许多情况下无服务器方法的优势。简化的后端任务提高了许多开发人员的工作效率。但是，当然存在挑战，例如资源和执行限制，监视和调试以及安全性和隐私性。
无服务器是高度分布式的，并且与异步事件一起使用，这使得它们很难通过默认提供的一堆日志进行跟踪。云供应商的环境通常不是开源的。因此，在大多数情况下，对无状态功能的性能分析可能会很复杂。可观察性是至关重要的，因为如果您不关注无服务器应用程序，它们可能会失败并导致诸如不可用或高昂成本之类的若干问题。传统的APM增加了调用的开销，并且无法在无状态环境中运行。
下面，我们将使用一个无服务器应用程序的真实示例，并展示如何通过使用分布式跟踪来提高其可见性。
什么是Thundra？
Thundra最初是Opsgenie（一家提醒功能和通话管理解决方案商）内部的一个内部项目，旨在使工程团队能够优化资源并解决问题，同时迁移到AWS中的无服务器。然后在2018年，Thundra从Opsgenie分离出来，后者被Atlassian收购。Thundra应用程序可观察性和安全性平台为无服务器中心，容器和虚拟机工作负载提供了端到端可见性，异常检测，调试，故障排除，警报和自动操作。Thundra可以以精确定位问题的方式共同提供应用程序管理，安全性和合规性。
Thundra有助于提高性能，优化成本并将MTTR降低多达80％。客户可以在几分钟内了解应用程序的行为并进行故障排除。Thundra的安全护栏和合规性有助于通过白名单/黑名单策略防止安全漏洞并自动检测异常，因此发现瓶颈和检测开发和生产中的问题的速度提高了90％！Thundra还使客户能够在线和离线逐行调试以无服务器为中心的应用程序。
Thundra帮助软件团队解决异步，分布式无服务器环境中的复杂问题。凭借灵活的查询和警报功能，以及汇总指标，日志和跟踪的丰富可视化，软件团队可以快速响应事件并解决其无服务器和容器化环境中的性能问题。所有这些操作都通过简单的设置即可完成，并且没有额外的开销。Thundra使其用户能够在AWS中调试，监视，排除故障并保护其无服务器和容器化环境，并通过包装AWS Lambda函数来生成代码或来自Amazon Cloudwatch服务的链接来检测代码，然后收集数据。Thundra还帮助开发人员在产品开发阶段进行本地调试，并在生产阶段进行实时监控。
对于那些担心开销（这意味着增加AWS Lambda函数的执行时间）的人，Thundra提供了另一种称为“异步监视”的集成方法。Thundra通过CloudWatch发布监视数据，这被AWS视为最佳实践，如其“ 使用AWS Lambda的无服务器架构 ”白皮书中所述。通过使用异步监视，客户无需担心由于Thundra而导致的功能故障，因为Thundra的Lambda会独立发送数据运行。使用异步监视的最重要优点是将日志写入Cloudwatch仅会给Lambda增加可忽略的开销。
一则实例
让我们用一个真实的例子来演示Thundra的好处。我们将使用博客应用程序来演示Thundra如何通过分布式跟踪来提高客户的无服务器应用程序的可见性。该应用程序具有两种不同的角色：博客作者和编辑者。使用博客应用程序，博客作者可以提交其草稿，获得反馈以及编辑/删除其博客文章。该应用程序还允许编辑者查看草稿，提交反馈并在准备就绪时发布博客。
博客应用程序设计为无服务器范式，并分解为许多小的Lambda函数，它们的责任很小，特权最少。当第一个请求进入系统时，异步调用链从Lambda函数之间流动的事件开始。这称为“业务流”，它表示有意义的调用链，这些调用可以为软件用户实现真正的工作。例如，当作者提交博客帖子时，便开始了使该博客帖子准备好进行审阅的业务流程。
让我们仔细看看下图。
可以在上面的屏幕快照中看到业务流程，该屏幕快照来自Thundra控制台，并且是自动绘制的。
让我们一一介绍这些操作：博客应用程序应立即显示一条消息，说明该帖子已保存，并将由编辑者进行审核。新的博客帖子被提取到SQS队列中。Lambda接管了SQS的作用，并向SNS发布消息以通知编辑。相同的Lambda会保存博客文章，以便编辑可以使用它进行审查。从DynamoDB记录中，另一个Lambda被触发，并将内容写入具有必要索引的Elasticsearch表中，以便可以在数百万博客帖子中进行搜索。
从开发人员的角度来看所有这些问题时，很难在本地复制生产中发生的问题以了解“后台”应用程序的行为。所有这些问题都可以用一个短语来概括：了解应用程序行为和维持应用程序健康。我们相信了解应用程序运行状况的三大支柱：可观察性，调试/测试和安全性/合规性。
微服务的可观察性
我们进入了自动观测的新时代。当企业迁移到以无服务器为中心的工作负载时，基于事件的体系结构被用来应对复杂的业务逻辑和异步编程模型。
Thundra定义了可观察性的三个支柱：指标、痕迹、日志。
开发人员可以减少跨多种工具的上下文切换。开发人员可以使用真正的端到端管理平台来跨无服务器架构的分布式应用程序，而不必使用多种工具来应用Observability Engineering的特性。默认情况下，Thundra包括17个指标（某些特定于运行时的规范，例如Java或Go），可以提供以下内容：调用计数、调用持续时间、内存使用、CPU百分比、磁盘IO字节、处理内存使用情况、线程数、GC计数。
通过与Open Tracing兼容，Thundra提供了完整的跟踪功能，包括本地和分布式跟踪，您可以在其中检查Lambda与其他资源的交互。
在同一个仪表板中，开发人员可以快速进入日志，轻松进行调用和跟踪连接。
借助从不同角度（例如持续时间，错误，成本，资源消耗）进行查看的能力，Thundra帮助用户查明AWS Lambda函数和其他资源中错误的根本原因。错误，冷启动和超时因此可以大大减少。Thundra使您能够了解无状态环境中错误背后的问题，并毫不费力地跟踪第三方API和资源的运行状况。
无服务器应用程序的实时调试
由于开发人员无法访问基础架构，因此他们现在调试无服务器应用程序所需的唯一资源就是调用后打印的日志。但是，编写新的日志行，部署功能并再次检查日志需要花费大量时间。分步调试，设置断点和检查变量可以提高开发人员效率。在某种程度上，AWS Toolkit和SAM使您可以轻松地在本地环境上执行逐步调试。但是，由于权限，触发器和VPC配置的原因，很难在本地重新创建相同的AWS环境。有时，在不进行实时调试的情况下对问题进行故障排除可能既复杂又耗时。但是，能够在IDE上传统调试的舒适度下使用逐步调试实时功能，是完成该任务的便捷方法。
为了提供与开发人员在AWS环境中的Lambdas本地环境相同的调试体验，Thundra发布了其Online Debugger。该工具使开发人员能够在其本机环境中调试Lambda函数并使用其IDE，从而使他们能够执行传统的调试任务，例如设置断点以及查看和更改变量。客户只需更改一些配置即可完成此操作，而无需修改其代码。在线调试器还支持Java，Nodejs和Python运行时。为了使调试更加容易，Thundra发布了Nodejs，Python的VSCode插件和Java的Intellij插件。对于其他环境，它发布了Python客户端。
执行后调试
应用程序团队需要一种不同的监视方法来跟踪功能之间传递的所有异步消息，因为老式的指标和日志监视对这种分布式系统没有帮助。开发人员需要更多按时间顺序排列的高基数数据，以显示异步体系结构的行为。分布式跟踪得以解救，解决了理解现代应用程序行为和维护应用程序健康的痛苦点。
分布式跟踪在大多数情况下时间可能会很短，因为所有业务逻辑仍然在函数内部而不是在函数之间发生。当大型Lambda函数出现任何问题时，开发人员将只留下日志；在这种情况下，应在应用程序中仔细放置一种结构化的日志记录机制，以有效地使用日志。但是，这需要大量的手动工作，并且仍然会污染代码。在这种注定的情况下，开发人员很乐意使用类似IDE的经验来调试这些应用程序。这样，开发人员可以遍历业务逻辑以查看执行代码后是否发生了意外情况。为了满足此需求，Thundra的脱机调试功能使开发人员可以在完成执行后调试无服务器功能。
安全护栏
安全是一个至关重要的主题，即使在无服务器等托管环境中也应谨慎处理。无服务器计算自其诞生以来就已经发展起来，它使每个组织都可以快速行动，而无需考虑幕后情况。这导致了适合无服务器生态系统的新服务爆炸。与非无服务器环境相比，无服务器环境的脆弱性较小。但是，这并不意味着不会发生安全漏洞。在大多数情况下，保护无服务器应用程序就是确保您紧密关闭了潜在的安全漏洞，例如区分敏感数据和非敏感数据。与无服务器相关技术的许多安全漏洞来自错误配置，该错误配置公开暴露了非公共信息。
在构建无服务器应用程序时，要克服的一个共同问题是限制在AWS Lambda函数内部进行的内部API调用。从外部，您可以使用AWS IAM权限来限制这些权限，但这只会对AWS资源访问产生影响。
如果您想阻止所有API URL（安全团队批准的URL除外）该怎么办？这将需要在AWS Lambda之上使用一些额外的工具来检查在AWS Lambda函数中正在发出哪些请求，然后根据您定义的内容采取措施。
在上图中，我们可以看到我们对AWS Lambda函数具有一些现有的AWS IAM权限。我们还可以看到，我们添加了一个列入黑名单的资源，该资源将阻止对SQS的所有读取请求。
如您所见，我们有两个选择：一是提醒并通知我，二是阻止并通知我。
如果选择“警报”，则AWS Lambda执行将继续运行；否则，将继续运行。但是，正如名称和描述所暗示的那样，将向您的团队发送一条消息，让他们知道发生了什么。
另一个“阻止”选项会停止操作。这意味着您的AWS Lambda执行将停止。如果您在需要高级别安全性的高度关键的应用程序上工作，并且整个公司和开发团队都采用了严格的安全策略，那么此选项可能是值得的。
结论
在受益于最新云技术的同时构建微服务的复杂性通常被证明是开发人员的负担。工程团队和DevOps团队在开发或生产阶段都可能面临可观察性的挑战，这可能会对成本和效率产生不利影响。Thundra的无服务器可观察性平台用于测试，调试，监视，故障排除和保护无服务器应用程序，可提供汇总指标，日志和跟踪的丰富可视化。我们很高兴将Thundra可以减轻工具负担的工具。