无服务器（Serverless）架构代表着云计算下一个合乎逻辑的发展阶段，能够有效强化可扩展性、提供更多安全选项，并有能力实现大量实时功能。

无服务器模式已经被广泛视为容器技术的继任者，虽然拥有诸多优势，但也同样不可能完全适合每一种案例。了解无服务器模式中的陷阱与弊端，将帮助大家更轻松准确地判断其是否适合实际需求。在今天的文章中，我们将通过多个技术层面对当前无服务器模式的成熟度进行分析。

首先需要注意的是如何使用“无服务器”这一词汇。

无服务器实际上是将“功能即服务（简称FaaS）”与“平台即服务（简称PaaS）”加以结合的产物。顾名思义，对于这两种云服务类型，用户并不清楚服务器究竟是如何组建及运作的。

举例来说，RDS与Beanstalk皆属于“服务器由AWS负责管理”的类型，在这里大家可以将服务器视为背景因素。DynamoDB与S3则在一定程度上归属于NoSQL以及配备有API的存储解决方案，这里大家同样无法直接接触任何服务器。不直接接触服务器意味着我们不需要对其进行配置、强化或者维护，这也就是“无”服务器的真实含义。无服务器平台与“事件”相协作。所谓事件，可以是隐藏在网站按钮后的操作、移动应用中的后端处理流程或者将图片上传至云端的瞬间所触发的存储服务功能。

无服务器架构中的全部服务皆可扩展至几乎无限的水平，这意味着当某一事件触发某项功能，例如每秒触发1000次，则所有执行在下一秒中即可完成。在容器技术方面，大家需要配置并调整大量容器应用以处理这么多即时请求。

如此看来，无服务器似乎铁定要在性能层面中胜出了，对吧？但实际上，有时候包含您功能的无服务器容器并未运行，而需要另行启动。这意味着“冷”功能的另行启动会导致整体执行资源消耗量略有提升，希望让用户（或者组件）获得100%高速响应的朋友肯定不希望忍受这种妥协。

为了获得可预测的响应效果，大家需要配置一套容器平台。很明显，除了运行相关容器外，大家还必须承担由此带来的时间、复杂性与风险等成本，不禁让人犹豫这种作法是否值得。

在使用容器平台或服务器时，需要按运行小时数，甚至特殊情况下需要按分钟或秒进行计费。即使您面对的是一组非常稳定且可预测的工作负载，且利用率始终在70%左右，这仍然会带来巨大的资源浪费。

另外，由于流量可能突然激增，因此大家总是需要对资源进行过度配置。一种解决选项在于尽可能提升利用率，这能有效降低成本，但却也给性能表现带来更高风险。

相反，在无服务器模式下，大家以约100毫秒为时间单位支付代码执行成本，这样的效果无疑更为细化且可带来接近100%的资源利用率。毫无疑问，如果您面对的是不可预测且时常出现峰值的流量负载，那么无服务器模式将凭借着按实际使用量付费的强大能力成为最佳选项。

大家可能认为云服务能够实现100%安全，可惜实际情况并非如此。大多数云服务的“攻击面”确实受到严格限制因而能够实现全面保护。然而在无服务器模式当中，这一攻击面则“又细又长”——像EC2或者DynamoDB这类服务因为运行在共享服务器之上，因此安全保护水平相对较低。

出于这一原因，无服务器模式往往不允许包含某些敏感信息，例如信用卡相关数据。这并不是说无服务器模式不安全，只是它无法通过严格及必要的合规审计。考虑到无服务器技术所受到的热烈欢迎，相信其安全性将在未来得到改善，因此我们将持续关注它在安全层面的最新发展动态。

具体来讲，大家可以先从敏感性较低的数据着手，例如利用其后端系统处理游戏进度、购物列表、分析等任务。另外，大家也可以利用其处理购物订单，但将付款流程外包给专业服务商。像信用卡号码这类信息显然属于敏感数据，一旦其从内存中泄露至同一底层服务器的其他用户处，则该号码将有可能被利用。不过在另一方面，身份ID则比较安全，毕竟“3h7L8r购买了西红柿”这种信息实在没什么利用价值。

另一项需要考量的重要指标在于服务的可用性。一项相对“缓慢”但却始终可用的服务，显然要远远好过速度较快但却时常无响应的服务。

一般来说，在灾备设置当中，所有内部服务器都会被复制到云端，而这会显著提升复杂性。大多数情况下，大家最好彻底关闭自己的内部设施并全面接纳云环境。如果大家还没有为此做好准备，也可以使用无服务器模式作为故障转移平台，从而保证特定功能拥有高可用性水平。

当然，请注意这里指的是特定功能，即那些关键性业务功能，且其需要能够在恢复之后方便地实现临时存储与批量处理。这种作法成本更低且相当可靠。

就在不久之前，对实时功能进行启动与更新还相当麻烦。而如今Serverless.com以及SAM等，越来越多的框架选项都在努力解决这一难题。将其与自动化CICD（即持续集成/持续交付）相结合，大家将能够轻松在安全环境中部署并测试自己的无服务器平台。

这一做法能够确保生产性部署始终成功且不会遭遇停机时间。利用CloudFormation或者Terraform，大家可以“开发”云原生服务并配置功能。利用Node.js、Python、Java或者C#，大家则能够开发出功能本身。过去几个月来，日志记录与监控机制也开始快速发展成熟。

总而言之，这些资源让我们真正实现了“云明确性”，即清晰地了解无服务器应用内部的运作原理：其如何实现配置、构建、部署、测试、监控以及运行。

')}