无服务器架构的四大主要弊端

无服务器架构是指高度依赖于第三方服务（即后端即服务，简称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组件。这意味着您将无法以原子性方式对一组功能进行统一部署，而由于不存在应用程序版本管理概念，因此原子回滚亦无法实现。如此一来，我们需要关闭一切触发相应功能的事件源、部署整体功能组，而后再重新启动事件源。