没有这个dll ‘mvtnorm’:是不是没有为此架构安装?_无服务器架构无服务器架构是应用程序的正确选择？考虑利弊...

在适当的情况下，我们喜欢无服务器架构。但这些情况是什么呢?

在前一篇关于web开发中的无服务器架构的文章中，我们讨论了为什么我们相信无服务器将是云原生开发的未来。不可否认的是，重点是无服务器架构的优势。在我们的无服务器系列的这一期中，我们将通过概述无服务器的缺点以及在哪些情况下它可能不是你的下一个应用的最佳方法来增加更多的平衡。

当然，没有任何技术或架构是适用于所有情况的完美解决方案。在无服务器的web开发中，可以感知到的弱点在某种程度上得到弥补，这意味着它们不会拖累技术解决方案或业务案例，以达到优势被削弱的程度?

我们还将把无服务器web开发的优缺点理论应用于示例应用程序。这将说明在何种情况下，serverless的优点和缺点的平衡使得它成为技术堆栈的最佳选择，而在哪些情况下它可能不是最佳选择。

为了平衡我们上一篇文章中略显夸张的pro-serverless的立场，让我们从这次无服务器web开发的缺点开始：

Serverless缺点

那么，采用无服务器开发方法可能存在哪些问题和缺点呢?

厂商锁定

在与我们自己的架构师和客户讨论serverless是否是一个新的开发项目的正确方式时，我们经常会看到对供应商锁定的担忧。有一种看法认为，一旦应用程序的无服务器架构由一家云供应商(通常是GCD、AWS和Azure)建立起来，如果环境发生变化，那么要迁移到另一家云供应商就非常困难(昂贵且耗时)。

在现实中，如果从一个新的应用程序项目开始就提供正确的方法，供应商锁定不一定是无服务器开发的缺点。至少对大多数应用程序来说不是这样。对于真正的大型应用程序来说，供应商之间的迁移不可避免地会非常复杂。

例如，你正在设计一个具有以下功能的web应用程序:

• 安全的用户标识

• 收集及储存一些个人资料

• 应用程序功能的用户界面

让我们比较一下传统web开发和无服务器开发方法所需要的技术栈。

传统的web开发:

• 身份识别:Spring安全框架(Java)

• 数据存储:NoSQL更适合这里，因为不需要事务(MongoDB)

• 通知:带有Websockets的Spring

• 支付方式:第三方服务

• 业务逻辑核心:带有REST端点