服务器返回它们的和

by Nicolas Dao

由Nicolas Dao

无服务器有其陷阱。 这是避免它们的方法。 (Serverless has its pitfalls. Here’s how you can avoid them.)

In this post, I will share the lessons I learned over the past year while using Serverless to build mobile and web apps for a tech consultancy in Sydney. For each drawback, I will also recommend one or multiple solutions.

在这篇文章中，我将分享我在过去一年中使用Serverless为悉尼的一家技术咨询公司构建移动和Web应用程序时吸取的教训。 对于每个缺点，我还将推荐一个或多个解决方案。

1. FaaS-连接池限制 (1. FaaS - Connection Pooling Limitation)

FaaS conversations do not mention this limitation very often. Cloud providers market FaaS as a solution that could infinitely scale. While this may apply to the function itself, most of the resources that your function depends upon won’t be infinitely scalable.

FaaS对话很少提到此限制。 云提供商将FaaS作为可以无限扩展的解决方案进行营销。 尽管这可能适用于函数本身，但是函数所依赖的大多数资源都不会无限扩展。

The number of concurrent connections that your relational database supports is one of those limited resources. The unfriendliness of FaaS towards connection pooling is what makes this problem such a big deal.

关系数据库支持的并发连接数是那些有限的资源之一。 FaaS对连接池的不友好之处使这个问题变得如此重要。

Indeed, as I mentioned before, each instance of your function lives in its isolated stateless environment. That means that when it connects to a relational database (for example PostgreSQL, MySQL, Oracle), it should most probably use a connection pool to avoid reconnecting back and forth with your DB.

确实，正如我之前提到的，函数的每个实例都生活在其隔离的无状态环境中。 这意味着，当它连接到关系数据库(例如PostgreSQL，MySQL，Oracle)时，它很可能应该使用连接池，以避免与数据库来回重新连接。

Your relational database can only manage a certain amount of concurrent connections (usually the default is 20). Spawning more than 20 instances of your function will quickly exhaust your database connections, preventing other systems from accessing it.

您的关系数据库只能管理一定数量的并发连接(通常默认值为20)。 生成20多个函数实例将Swift耗尽数据库连接，从而阻止其他系统访问它。

For that reason, I recommend avoiding any FaaS if your function needs to communicate with a relational DB using a connection pool. If you need to use a connection pool, then a few options are available:

因此，如果您的功能需要使用连接池与关系数据库进行通信，我建议避免使用任何FaaS。 如果需要使用连接池，则可以使用一些选项：

• Use a BaaS instead.请改用BaaS。

• Some relational database like PostgreSQL offers plugins that can solve this problem by multiplexing the number of available concurrent connections.

  诸如PostgreSQL之类的关系数据库提供了可以通过多路可用并发连接数来解决此问题的插件。

2. FaaS-不支持WebSockets (2. FaaS - No Support For WebSockets)

This one is kind of obvious. But for those who think they can have the cake and eat it too, you can’t hope to maintain a WebSocket on a system that is by design ephemeral. If you’re looking for a Serverless WebSocket, then you’d need to use a BaaS like Zeit Now instead.

这是显而易见的。 但是对于那些认为自己也可以吃蛋糕也可以吃蛋糕的人，您不能希望在临时设计的系统上维护WebSocket。 如果您正在寻找无服务器WebSocket，则需要使用类似Zeit Now的BaaS。

Alternatively, if you’re attempting to create a Serverless GraphQL API, then it is possible to use Subscriptions (which relies on WebSockets) by using AWS AppSync. A great article that explains this use case in greater detail is Running a scalable & reliable GraphQL endpoint with Serverless.

另外，如果您尝试创建无服务器GraphQL API，则可以通过AWS AppSync使用Subscriptions(依赖WebSockets)。 一篇很棒的文章更详细地解释了该用例，它是使用Serverless运行可伸缩且可靠的GraphQL端点 。

3. FaaS-冷启动 (3. FaaS — Cold Start)

FaaS solutions like AWS Lambda have demonstrated huge gains when solving Map-Reduce challenges (for example, Leveraging AWS Lambda for Image Compression at Scale). However, if you’re trying to provide a fast response to events like HTTP requests, you’ll need to take into account the time required by the function to warm up.

在解决Map-Reduce挑战(例如， 利用AWS Lambda进行大规模图像压缩 )时， AWS Lambda之类的FaaS解决方案已展示出巨大的收益。 但是，如果您想对诸如HTTP请求之类的事件提供快速响应，则需要考虑函数预热所需的时间。

Your function lives inside a virtual environment that needs to be spawned to scale up based on the traffic it receives (something you naturally do not control). This spawning process takes a few seconds, and after your function idles due to low traffic, it will need to be spawned again.

您的功能位于一个虚拟环境中，需要根据接收到的流量(自然而然您无法控制)来生成该功能以扩大规模。 生成过程需要花费几秒钟的时间，并且由于流量减少而导致功能闲置后，需要再次生成它。

I learned that at my expense when deploying a relatively complex reporting REST API on Google Cloud Functions. That API was part of a microservice refactoring effort to break down our big monolithic web API. I started with a low-traffic endpoint, which meant that function was often in an idle state. The reports that were powered by that microservice became slow the first time they were accessed.

我了解到，在Google Cloud Functions上部署相对复杂的报告REST API时需要付出一定的代价。 该API是微服务重构工作的一部分，旨在分解我们庞大的整体Web API。 我从低流量的端点开始，这意味着该功能通常处于空闲状态。 由该微服务提供支持的报告在首次访问时变慢。

To fix that issue, I moved our microservice from Google Cloud Function (FaaS) to Zeit Now (BaaS). That migration allowed me to keep at least one instance up all the time (more about Zeit Now in my next post: Why We Love Zeit Now & When To Use It Over FaaS).

为了解决该问题，我将微服务从Google Cloud Function(FaaS)移至Zeit Now(BaaS)。 这次迁移使我能够一直保持至少一个实例(在我的下一篇文章中：关于Zeit Now的更多信息：为什么我们现在喜欢Zeit以及何时在FaaS上使用它)。

4. FaaS-长期存在的流程，不要打扰！ (4. FaaS - Long-Lived Processes, Don’t Bother!)

AWS Lambda and Google Cloud Functions can run no longer than 5 and 9 minutes, respectively. If your business logic is a long-running task, you will have to move to a BaaS like Zeit Now instead.

AWS Lambda和Google Cloud Functions分别不能运行5分钟和9分钟。 如果您的业务逻辑是一项长期运行的任务，则必须改为使用Zeit Now之类的BaaS。

For more details on FaaS limitations, please refer to AWS Lambda quotas and Google Cloud Functions quotas.

有关FaaS限制的更多详细信息，请参阅AWS Lambda配额和Google Cloud Functions配额 。

5. BaaS＆FaaS-放松基础架构控制 (5. BaaS & FaaS - Loosing Infrastructure Control)

If your product requirements necessitate some degree of control over your infrastructure, then Serverless will most likely leave you up the creek. Example of such problems could be:

如果您的产品要求需要对基础架构进行一定程度的控制，那么Serverless很有可能会让您不满意。 此类问题的示例可能是：

• Microservices deployment orchestration. Ending up with a myriad of Serverless microservices will quickly become a deployment nightmare, especially if they need to be versioned altogether or by domain.微服务部署流程。 结束无数的无服务器微服务将很快成为部署的噩梦，尤其是如果需要对它们进行完全版本控制或按域进行版本控制时。
• Controlling the lifecycle of each server to save on costs.控制每个服务器的生命周期以节省成本。
• Having long-running tasks on multiple servers.在多台服务器上具有长期运行的任务。
• Controlling the exact version of the underlying server OS, or installing specific libraries required by your app.控制基础服务器操作系统的确切版本，或安装应用程序所需的特定库。

• Controlling exact geo-replication of your app or data to ensure consistent and fast performances globally (there are ways to overcome this in some scenarios. Check out Build a serverless multi-region, active-active backend solution in an hour).

  控制应用程序或数据的精确地理复制以确保全局一致和快速的性能(在某些情况下，有一些方法可以解决此问题。请检阅在一个小时内构建无服务器的多区域，双活后端解决方案 )。

Serverless may fall short in all the above use cases. However, as I’ve discussed before, Serverless is just an extension of PaaS. To keep as much focus as possible on writing code rather than worrying too much about the underlying infrastructure scalability and reliability, leveraging the latest PaaS containerization strategies such as Google Kubernetes Engine can get you very close to what Serverless has to offer.

在以上所有用例中，无服务器都可能不足。 但是，正如我之前讨论的，Serverless只是PaaS的扩展。 为了尽可能专注于编写代码，而不是过多地担心基础架构的可伸缩性和可靠性，利用最新的PaaS容器化策略(例如Google Kubernetes Engine)可以使您非常接近Serverless所提供的功能。

6. BaaS和FaaS-合规性和安全性 (6. BaaS & FaaS - Compliance & Security)

Serverless shares all the usual complaints related to the cloud. You are giving up control of your infrastructure to one or multiple third parties. Depending on the vendor, Serverless may or may not provide the right SLA and security levels for your business case.

无服务器共享与云有关的所有常见投诉。 您正在将基础结构的控制权交给一个或多个第三方。 根据供应商的不同，Serverless可能会也可能不会为您的业务案例提供正确的SLA和安全级别。

Whether Serverless a go or no-go from a compliance and security point of view really depends on your particular case. Many articles discuss this topic in great details (like The state of serverless security).

从合规性和安全性的角度来看，无服务器运行还是不运行实际上取决于您的特定情况。 许多文章都非常详细地讨论了该主题(例如无服务器安全性状态 )。

结论 (Conclusion)

Serverless is not a silver bullet. The gains you can obtain from it depend on your knowledge of it. The good part is that the barrier to entry is so low that you should be proficient in no time.

无服务器不是灵丹妙药。 您可以从中获得的收益取决于您对它的了解。 好的方面是，进入门槛很低，您应该很快就精通。

下一步… (COMING NEXT…)

Of course, Serverless has limitations. All technical solutions have them. The question now is how we overcome them. In my next post, I’ll write about suggestions my team and I developed to deal with those limitations: “Why We Love Zeit Now & When To Use It Over FaaS”.

当然，无服务器具有局限性。 所有技术解决方案都有它们。 现在的问题是我们如何克服它们。 在我的下一篇文章中，我将撰写有关团队的建议，并为克服这些局限性提出建议：“为什么我们现在喜欢Zeit以及何时在FaaS上使用它”。

Follow me on Medium - Nicolas Dao - if you’re interested in what’s coming next:

在Medium- Nicolas Dao上关注我，如果您对接下来发生的事情感兴趣：

Current posts in this serverless series:

此无服务器系列中的当前帖子：

• Do You Really Know What Serverless Is?

  您真的知道什么是无服务器吗？

• The Impact of Serverless On Tech Leadership

  无服务器对技术领导力的影响

• How Serverless Is Automating IT Engineers

  无服务器如何使IT工程师自动化

Future posts in the series:

该系列的未来文章：

• Why We Love Zeit Now & When To Use It Over FaaS

  为什么我们现在爱Zeit以及何时在FaaS上使用它

• Serverless Event-Driven Architecture: The Natural Fit无服务器事件驱动架构：自然而然的选择
• How To Manage Back-Pressure With Serverless?如何使用无服务器管理背压？
• GraphQL on Serverless In Less Than 2 Minutes不到2分钟的无服务器GraphQL

翻译自: https://www.freecodecamp.org/news/the-serverless-series-mistakes-you-should-avoid-9ec1ca6b9dff/

服务器返回它们的和