是时候完全转向无服务器化了吗？

正文

请到「今天看啥」查看全文

让很多开发者不安的是无服务器运行自己代码的理念-换言之，通用无服务器化计算。

我怎么知道自己的代码如何运行？我如何调试并且监视环境？我如何加固服务器？

这些都是本能的反应和疑问——这些重要的非功能观点在我们开始探究一个良好的无服务器架构前都必须得到解决。现在开始讨论我们的选择。

事件驱动类

第一种具备广泛用途的无服务器化计算机是功能即服务业务：AWS Lambda和Azure Functions。这两种服务都为按需执行的代码提供运行环境。你不必开发很多应用，你只要写应用片段和事件规则，这些规则在需要的时候触发你的代码。“当我在/foo 收到一个HTTP request时，运行X ”，“当队列中有消息时开始Y”诸如此类。

功能可能很简单：只是输入一个或者几个方法来完成一个简单工作。

你不知道或者不关心服务器，你的代码只是执行而已。现在你处于功能园中，根据内存和CPU的使用，按照零点几秒的时间进行计费。无论一天中进行了一次’或者一百万次调用，这没关系-这种差别你是看不见的。

所以，现在无服务器化是明确的方向。但是功能集并不能单独占据主导地位。为什么？

• 不是所有的任务都适合于基于事件的单操作触发模型。

• 不是所有的代码都能清晰地解耦，有些依赖需要大量的安装和配置工作。

• FaaS 产品可能不支持你的开发语言的与/或范式。

• 将现有的应用转换到功能即服务模型太过复杂以至于在经济上是不可接受的。

所有这些都是有效的架构层考量。

此外，还要大量的工具问题使得FaaS产品对于一些场景难以使用。我对这些却并不担心——所有这些产品都在以飞快的速度进行改进，如果现在工具问题阻碍了你，这些问题应该很快就会得到解决。问题是“什么时候”？

流程图驱动类

如果你与功能集类无缘，因为你的工作流只是不适合事件驱动模型，这典型地触及了两个问题中的一个：或者是你的流程图需要更为复杂的编排，或者你需要连续不断的运行-或者是在大量时间内连续运行，这两个情况类似。

复杂的编排问题首先可以由诸如 Azure Logic Apps 和AWS Step Functions解决，允许你绘制长运行工作流的流程图。工作流可以调用你自己的功能集代码，允许在直接调度框架内客户功能的注入。

请到「今天看啥」查看全文