不容忽视无服务器架构的四大主要弊端

无服务器架构是指高度依赖于第三方服务（即后端即服务，简称BaaS）或者运行在临时容器（即功能即服务，简称FaaS）内之定制化代码的应用程序，目前最为知名的相关服务为AWSLambda。

尽管名为"无服务器"，但此类架构并非将代码彻底剥离于服务器之外。"无服务器计算"是指企业或个人无需购买、租赁或配置用于支持后端代码运行的物理或者虚拟服务器。

无服务器解决方案通常包含Web服务器、FaaS层、安全令牌服务（简称STS）、用户验证以及数据库等组成要素。

无服务器代码可与面向常规服务器形式的代码--例如微服务--并发运行。举例来说，我们可将一款Web应用中的部分代码以微服务形式编写，而另一部分则可表现为无服务器形式。此外，在编写当中完全不涉及任何服务器配置要素的应用程序亦可实现无服务器化。

FaaS提供的平台允许开发者根据具体事件触发代码执行操作，而无需构建并维护复杂的基础设施。在这一体系当中，由第三方应用或服务对服务器端逻辑及状态进行管理。

无服务器计算的弊端

1.第三方API系统的问题

供应商控制、多租户问题、供应商锁定以及安全缺陷等负面影响皆可能由第三方API所引发。在不具备系统控制能力的前提下使用API有可能导致系统宕机、强迫性API升级、功能缺失、发生意外限制以及成本变更等后果。另外，多租户问题亦常见于各类云计算框架之内。Salesforce（PaaS）即因其多租户云结构而引入了部分监管限制，开发人员亦需要在使用当中尽可能避免相关问题。具体而言，多租户解决方案往往会在安全性、稳定性以及性能层面发生问题。

2.运维工具缺失

开发人员需要依靠供应商为其提供调试与监控类工具。事实上，分布式系统的调试工作相当困难，且通常需要对大量相关指标进行访问方可了解问题的产生根源。

3.架构复杂性

开发人员需要投入大量时间以评估、实施并测试具体功能应当拆分成怎样的粒度。应用程序一次调用操作中所涉及的功能数量需要加以平衡。对大量功能进行管理无疑将提升运营成本，而忽略粒度设置则终将令微服务架构变为"迷你整体"架构。

目前，AWSLambda对用户所能并发执行的总体lambda数量作出了限制。其中的问题在于，该限制将影响您的整体AWS帐户。部分企业会利用同一AWS帐户进行生产及测试。这意味着如果某位工作人员着手进行一项新的负载测试并尝试执行1000项并发Lambda功能，则生产应用将立即遭遇拒绝服务（简称DoS）状况。

4.实施难度过高

对无服务器应用进行集成化测试难度极高。无服务器FaaS（即每项功能）中的各集成单元要远小于其它架构，因此我们需要将大量单元加以集成，方能正常完成测试。另外，大家可能需要在整体逻辑应用之内为每项功能部署一项对应的FaaS组件。这意味着您将无法以原子性方式对一组功能进行统一部署，而由于不存在应用程序版本管理概念，因此原子回滚亦无法实现。如此一来，我们需要关闭一切触发相应功能的事件源、部署整体功能组，而后再重新启动事件源。