种失败的风格，可能会发生在无服务器函数中，你运行一个函数一次就会失败，然后你可以立即运行它第二次，它就会成功，因为它可能会完全失败。不同的服务器。或者无论问题是什么，当第二个请求时该运行可能不存在。整个主机宕机的问题是一回事，但也许……您的机器存在个别问题。你有一个特定的服务器，它的内存已经坏了，并且抛出了大量错误，当你第一次访问它时，它就会失败。第二次，这个问题可能已经找到根源了。 克里斯：倾向于提供这种技术的公司，你必须信任他们，但他们也恰好是这样的公司……这是他们的骄傲。这就是人们使用它们的原因，因为它们是可靠的。我相信人们可能会指出过去的一些 AWS 中断，但它们往往有点罕见，而且不是很常见。
如果您托管自己的垃圾我敢打赌
他们会在 SLA 百分比级别上击败您。你知道？所以这不像“不要以弹性方式构建”，但通常提供这些东西的公司类型是非常可靠的。因为搞砸了该功能而导致失败的可能性比因为 日本电话号码清单 他们的架构失败而失败的可能性要高得多。德鲁：我想，我的意思是，就像您使用 API 或可能失败的任何东西一样，只是确保您构建代码以应对该故障模式，并知道接下来会发生什么，而不是仅仅抛出一个错误对用户来说是错误的，或者只是死了，或者你有什么。它意识到这一点并要求用户或者你自己再试一次，或者什么的。 克里斯：是的，我喜欢多次尝试的想法，而不是只是说“哦不。失败。放弃吧。” “我不知道，你为什么不在那里再试一次呢，伙计？” 德鲁：所重试。
以我的意思是当涉及到无服
务器功能（例如云功能）的测试和开发时，可以在本地完成吗？是否必须在云端完成？有办法管理吗？ 克里斯：我认为有一些方法。不知道故事是否也这么精彩。这仍然是一个相对较 BTC 数据库欧盟 新的概念，所以我认为它会变得越来越好。但据我所知，一方面，您正在编写一个相当正常的 Node 函数。假设您使用 JavaScript 来执行此操作，并且我知道特别是在 Lambda 上，它们支持各种内容。你可以写一个该死的 PHP 云函数。您可以编写 Ruby 云函数。所以，我知道我是在专门谈论 JavaScript，因为我有一种感觉，这些东西大部分都是 JavaScript。我的意思是，无论它是什么语言，您都可以在本地转到命令行并执行该操作。