我对过去几年的技术发展的一个抱怨是，赋予它们的名字不太好。微服务似乎表明它们与大小有关（剧透：它们没有关系），而无服务器架构表明它们不需要服务器（剧透：它们需要）。但糟糕的命名不应该影响你对其实 在无服务器 用性的认识。如果没有别的，它们会提醒我们永远不要停止独立思考。
话虽如此想谈论无服务器架构的名称
我甚至不想谈论任何与无服务器架构相关的内容。无服务器标签仅仅是我想要谈论的内容的桥梁：最好描述为“无服务器计算”的可移植性，通常称为函数。
虽然我可能把事情过于简单化，但我喜欢将无服 外汇数据 务器计算视为一个运行时，您可以简单地将在无服务器 一些代码放入其中，并且当满足某些条件（例如传入的 HTTP 请求）时将执行该代码。为了验证这种解释，我想我应该对它进行测试并编写一些“无服务器”代码，看看将它从一个云迁移到另一个云需要多少工作。就我而言，我想编写一个 .Net Core (2.1) Azure 函数并将其转移到 AWS .Net Core 2.1 Lambda 函数……这有多难？
我开始创建自己的函数
因此，在弄清楚了在 Microsoft Visual Studio 中让一切正常运行所需的条件之后，我最终从每个平台获得了两个“原始”函数。
原什么。对于熟悉 .Net Core 的人来说，你会发现两者都使 成功的销售指南：从勘探到成交 用了一些特定于各自平台的库。 Lambda 使用了一些Amazon.Lambda.*包，而 Azure Functions 需要一些Microsoft.Azure.*包。
这些包代表的是各个运行时与代码交互方式的差异。这些定义通常称为触发器，描述了如何将传入事件转换为 .Net Core 对象以供使用。在这两种情况下，传入的触发器都是 HTTP 事件。在 Azure 上，这会产生一个名为req的HttpRequest对象，而在 AWS 上，您会得到一个名为apigProxyEvent的APIGatewayProxyRequest对象。虽然这些对象不同， 但它们在很 新加坡电话列表 多方面相似，但不足以使代码在它们之间轻松移植。