如何判断2服务器性能好或坏_无服务器革命：好，坏和丑

如何判断2服务器性能好或坏

“这是愚蠢的。比愚蠢还糟：这是一场营销炒作。”
‐ 理查德·斯托曼 （ Richard Stallman）对云计算的评论，2008年9月

而且，十年后，当有人提到这个词时，您开始三思而后行：是到天上掉的东西，还是到2020年预计将占全球企业工作量83％的其他东西？

无论您是否喜欢，另一场革命正在进行中。 AWS处于领先地位，紧随其后的是Microsoft Azure和GCP，它们都怀有一个共同的目标：

解除对基础软件的束缚。

无服务器。

FaaS。

DevOps的死亡。

随便你

无论名称如何（为方便起见，我们将野兽称为“无服务器”），这种新范例已经在重塑软件领域中发挥了作用。我们已经看到像可口可乐这样的巨头在其生产堆栈中采用了无服务器组件，而无服务器等框架则获得了数百万美元的资金。但是，我们应该记住，无服务器并不适合每个人，任何地方，每次都适用-至少到目前为止还不是。

服务器（较少）=状态（较少）

作为常规程序员，我看到的无服务器最大的“障碍”是“无状态”。早先我可以肯定地知道我存储在内存中的复杂计算结果；或我提取到/tmp的相当大的元数据文件；或我刚刚产生的辅助子进程；一旦我的程序恢复控制，它将仍然存在，无服务器几乎打破了所有这些假设。尽管像lambda这样的实现往往会保留状态一段时间，但总的约定是，应用程序应该能够放弃所有希望，并可以从零开始优雅地启动，以防被干净的表盘调用。不再有内存中状态：如果要保存，则保存。你不，你输。

从另一个角度考虑，这可能也被认为是无服务器的（意外的）巨大优势之一。因为瞬态（通过“服务器化”架构仅使存在成为可能）是大多数（即使不是全部）邪恶的根源。现在，通过设计，您减少了犯错误的空间-这可能是一个公平的权衡，尤其是对于像我这样臭名昭著的程序员而言，它们通过内存状态管理寻求（通常为时过早）优化。

但是，我们不应忘记由于内存中状态管理和缓存容量的减少而导致的性能损失；您的状态管理器（数据存储）原先只有数个“电路跃点” ，现在将相距数个网络跃点，从而导致数毫秒（甚至几秒）的延迟，以及更多的故障空间。

次秒计费

如果您在过去的十年中还活着，那么您将会看到它的到来：一切逐渐变成按需付费的模式。现在，它的长度已到了以0.1秒的执行间隔对λ进行充电的程度，并且量化将继续进行。对于持久负载而言，这可能并不意味着很多优势，有时甚至可能意味着劣势，但由于负载变化率高的应用程序始终不需要预配置并支付预期的峰值负载，因此可以获得巨大的优势。更不用说具有稀疏负载配置文件的事件驱动和批处理系统，这些系统可能节省一个数量级，特别是当它们是小型的且在地理位置上受限时。

此外，新的按资源使用付费模式（考虑到时间或执行时间，也是一种非常有价值的资源），鼓励了面向性能的编程，这确实是一个好兆头。 FaaS提供商通常使用复合计费指标，将执行时间与内存分配等相结合，进一步加强了均衡优化的动力，最终产生了更好的资源利用率，更少的浪费以及由此带来的财务和环境效益。

看不见的红外线

代替物理硬件，虚拟化（以后）或容器化（以后）操作系统环境，现在您只能看到一个过程：实际上是一个功能或工作单元。乍一看听起来不错（不再进行基础设施/硬件/操作系统/支持实用程序的监视或维护，希望无服务器提供商会为我们提供帮助！），但这在灵活性方面也意味着巨大的挫折：即使在在容器的日子里，我们至少可以灵活地选择自己喜欢的基本操作系统（尽管仍绑定到底层内核），而现在我们所拥有的只是编程语言的选择（有时是其版本）。但是，那些经历过开发人员头痛的人肯定会同意，后者是一个非常合理的权衡。

加强隔离

由于您不再具有访问现实世界的权限（通常来说，这是一个短暂的容器化过程），因此出错的空间更少（不可避免的，因为实际上您可以做的事情更少！）。即使您受到损害，您的短暂寿命和有限的特权也可以防止进一步的污染，除非该漏洞利用足够强大，足以影响基本的业务流程框架。随之而来的是，不幸的是，如果发现了这样的漏洞，由于基于lambda的恶意软件主机将比以往具有更大的可伸缩性，因此可以被大量利用。

大多数提供商故意限制lambda尝试进行恶意活动，例如发送垃圾邮件，合法用户对此会不以为然，但遭到了垃圾邮件的困扰（想象每月有数百万lambda运行时数量激增，AWS已经提供了100万次免费调用， 320万秒的执行时间 -向一组用户发送垃圾邮件；十二个免费的AWS订阅将使攻击者获得巨大的优势！）

供应商锁定：有副作用吗？

这是每个云平台（或者，如果您仔细考虑的话）任何平台，实用程序或服务的固有问题。一旦您决定利用平台的“酷”或“高级”功能，便可以有效地与之耦合。对于无服务器平台而言，这比以往任何时候都更加真实：除了语言构造之外，几乎所有其他一切都是特定于提供程序的，并且试图编写“通用”功能最终会陷入难以理解的复杂的黑客和重塑车轮中，或者很可能什么都没有。

从某种意义上说，这是必不可少且不可避免的回报。如果必须要特别，就必须要具体！诸如Serverless之类的框架正在积极尝试解决这一问题，但是，按照一般的观点，通用解决方案仍然遥不可及。