关于Serverless服务的几点建议

94次阅读

共计 2825 个字符，预计需要花费 8 分钟才能阅读完成。

导读	通过迅速灵活以及容量巨大的弹性伸缩，无服务器架构能很好地解决关键功能的性能瓶颈，但它并不是完美的：不仅需要修改设计去适应它，对熟悉的编程模型进行调整，还要解决诸如规划预算、安全等等问题。但总的来说，它为云上的应用提供了另一种选择——并且具有难以抵挡的诱惑：极大地简化应用从开发到部署和维护的整个过程。信息技术在不同领域的发展不尽相同。诚然，事实一直如此，因为人们为当下的问题所找到的可行的解决方案，通常先于这些问题本身就已经存在了。

通过迅速灵活以及容量巨大的弹性伸缩，无服务器架构能很好地解决关键功能的性能瓶颈，但它并不是完美的：不仅需要修改设计去适应它，对熟悉的编程模型进行调整，还要解决诸如规划预算、安全等等问题。但总的来说，它为云上的应用提供了另一种选择——并且具有难以抵挡的诱惑：极大地简化应用从开发到部署和维护的整个过程。

将编写代码和部署应用的整个过程简化是每个开发人员的梦想，而无服务器架构（Serverless）正是这样的解决方案，在采用这种架构的时候需要考虑它的局限，费用问题以及安全问题。

信息技术在不同领域的发展不尽相同。诚然，事实一直如此，因为人们为当下的问题所找到的可行的解决方案，通常先于这些问题本身就已经存在了。与虚拟化、云计算等技术的缓慢进步相比，编程语言几乎是原地踏步了十年。直到新一轮的编程语言和方法诸如 Python，Ruby，Node，Swift 的出现才打破这一局面。这两个领域看似毫无关联，然而我们即将看到二者共同演变并结合在一起开花结果。

这个新的结合领域就是无服务器计算（Serverless）。易于部署的容器实例集合、无处不在的基于 REST API 的外部服务、易于实现 REST API 的新编程语言使得以 REST API 提供接口成为一种简单而可行的选择。这些技术相互结合，创造了一种全新的计算形式。我们已经很熟悉这种新的编程形式的诸多方面（例如如何设计和实现 REST API，如何设计实现微服务），但是仍有一些方面并不为人熟知。

关于 Serverless 服务的几点建议

从 Node.js 中学到的

我第一个 Node.js 程序与大多数人的并没有太大不同——设置好监听端口和路径，写好代码处理相应的执行和退出逻辑，然后使用浏览器访问对应的 URI。在实现基本功能之后，我很自然地进一步利用 Node 的并发执行和其他新优点来改善这个应用。

但这个应用提供的并不是 REST API，它只是简单地根据不同的请求内容响应包含不同内容的 HTML 页面。结合 REST 之后，Node 应用便成为一个计算结点。不变的是，当收到请求时，它便执行逻辑，然后退出。同时，作为基础设施的部分，它会保持对特定端口的监听。

基础设施

然而，为了实现一个简单但完整、可运行的 Node 应用（或者 Python / Djang / Java / Spring / RoR 等），还需要进行网络配置，防火墙配置，操作系统配置和调整，存储配置，并且如果你使用了网络应用防火墙（WAF: Web Application Firewall），还需要配置 WAF。尽管，DevOps 能使所有这一切更容易一些，但请试想一下，如果你根本不需要做这些额外的配置，那将会怎样？

无服务器架构

针对这个问题，越来越多的公司不断地提出解决之道。他们思考的是能否可以做到由开发人员编写代码，部署应用，并在需要时就能轻易获取这些应用，而在不需要它们时也不需要做任何额外的工作，而且还能按需扩展？甚至能否做到像 WAF 这样的配置也被自动化，并且应用的访问权限被限定在指定的人 / 机器的正确子集？如果部署应用真的如同上传 zip 文件一样简单，或者就像在编辑器中编写代码并点击“部署”一样简单，那将会怎样？最后，如果预先配置了数据库和存储的访问权限，那么又该如何将这些配置包含进来呢？

这对开发者无疑有着巨大的吸引力。编写代码后，无需进行那些看似必须的配置（无论是物理环境，虚拟环境的还是云端环境）就能部署，是众多开发者的梦想。这也不禁让人想起一些现实世界中的例子。首当其冲的就是应对高峰期的性能瓶颈。假设你有一个完美运行的在线订单系统，在销售高峰期（比如黑色星期五），由于验证收货地址的时间过长，系统经常陷入崩溃。

如果你有一个无服务器函数（serverless function），它仅返回输入的地址是否有效，你就可以将地址验证交给它来处理，那该多好？甚至，该功能还允许快速扩展到几乎无限容量（当然，网络带宽还是要考虑的）！现在，这个瓶颈不再是问题，你只需要为这个函数实际使用的计算资源（CPU 时间）付费。这意味着调用得越多，支付的费用就越高，但是在大部分的时间里，费用都很少。你只需要为真实使用的计算资源付费。

如果所有这一切以可接受的价格让你在你的站点上或者云端完成，那该有多好！已经诞生了这样的产品（Microsoft Functions，AWS Lambda 和 nanoscale.io 等）都提供了上述所有功能。

并非雨后彩虹

无服务器计算也并不是完美的。在选择供应商时，需要注意的事项包括：

工具支持 。它必须支持你的开发工具，特别是对 CI / CD / ARA 的支持至关重要。如果无法将无服务器计算集成到你现有的开发环境和以及整个流程中，那么说明它还不够好。
计费和收费方式 。永远不要忘记这些服务提供商与你的商业一样，目标也是赚钱。请确保你明白他们赚到的钱是从你的预算中支出的。所有按需使用的资源都有一些附加因素，因为它依赖于不可预测的客户群和他们变幻莫测的使用情况。但要了解你将被收取哪些费用，以及供应商保留了哪些更换计费方式的权利。
安全功能 。将大量代码从你的核心应用中分离出来，并将其放在云端，这可能需要在安全上大量投资并需要撰写一些额外的代码。确保你的供应商能够提供上述协助，抑或是允许你将你的代码保留在防火墙和 WAF 之后。
你的整体架构 。虽然我们上面的例子很好地演示了“低垂的果实”（唾手可得的部分），但稍微复杂一些的案例就可能会遇到诸如数据访问，数据安全，成本问题乃至高可用性等问题。确保你的团队已经深入研究了怎样实现无服务器计算架构，并能很好地掌握这种编程模型。

构建正确的应用

将来，一些应用程序将完全采用无服务器架构，特别是对于相比使用云端实例更具成本优势的应用。即便没有这样的应用，尽可能少地在基础设施上配置资源也会变得更加划算。同时，将无服务器计算作为解决各种相对独立的功能引起的性能瓶颈的解决方案，或者用于测试在不需要增加基础设施预算的情况下，是否可以增加应用的容量。总的来说，在信息技术领域，对于如何正确地选择架构来实现业务目标，无服务器架构无疑是其中一种解决之道。