node aws 内存溢出

by William Woodhead

威廉伍德黑德(William Woodhead)

AWS上的Node.js API — Express与无服务器的优缺点 (Node.js APIs on AWS — the pros and cons of Express versus Serverless)

Recently I have been playing around with Serverless + AWS lambda and I have to say, I have been awestruck.

最近，我一直在玩Serverless + AWS lambda，我不得不说，我一直很吃惊。

Over the past few years I have almost exclusively used Express and AWS EC2 (and more recently Docker) to build JavaScript REST APIs.

在过去的几年中，我几乎专门使用Express和AWS EC2 (以及最近的Docker )来构建JavaScript REST API。

This piece outlines the pros and cons of Express and Serverless and explains why it made sense for our team at Pilcro to switchover. This piece is aimed at tech teams looking to deploy and manage Node.js APIs on AWS (or similar).

本文概述了Express和Serverless的优缺点，并解释了为什么Pilcro团队进行切换很有意义 。 本文面向希望在AWS(或类似产品)上部署和管理Node.js API的技术团队。

TL; DR (TL;DR)

Switching from Express to Serverless has completely transformed our delivery over the past 6 months.

在过去6个月中，从Express切换到Serverless的方式已完全改变了我们的交付方式。

Pros: reduced cost | out-of-the-box deployment scalability and monitoring | lightning-fast development.

优点：降低成本| 开箱即用的部署可扩展性和监视| 快速发展。

Cons: loss of control | the enigmatic Lambda runtime | young ecosystem | no out-of-the-box zero-downtime deployment

缺点 ：失去控制| 神秘的Lambda运行时| 年轻的生态系统| 没有现成的零停机时间部署

什么是快递| 什么是无服务器？ (What is Express | What is Serverless?)

Express is a Node.js package which, at its core, is a well-designed abstraction over the native Node.js http(s) module.

Express是一个Node.js程序包，其核心是对本机Node.js http(s)模块的精心设计的抽象。

Serverless, on the other hand, is a toolkit that interacts with cloud platforms, such as AWS or GCP, to deploy and manage APIs.

另一方面，无服务器是一个工具包，可与AWS或GCP之类的云平台进行交互以部署和管理API。

From these descriptions, we can see that Express and Serverless are really very different — maybe too different to be compared. However the reason I am comparing them is that both Express and Serverless can be used for writing Node.js APIs. So let’s jump into some comparisons:

从这些描述中，我们可以看到Express和Serverless确实有很大的不同-也许相差太大，无法进行比较。 不过我比较他们的原因是，无论Express和无服务器可用于书写的Node.js的API。 因此，让我们进入一些比较：

索引文件 (The index file)

In general, I prefer writing code to writing config. It means you can run, test, and debug your work.

通常，我更喜欢编写代码而不是编写配置。 这意味着您可以运行，测试和调试工作。

With Express, your index file is JavaScript code. It is a really expressive declarative file. With Serverless, it’s yml config, I’m afraid.

使用Express，索引文件是JavaScript代码。 这是一个真正具有表达力的说明性文件。 恐怕使用无服务器时，它是yml配置。

Here’s the Express Hello World index.js file:

这是Express Hello World index.js文件：

const express = require('express');const handler = require('./handler');

const app = express();app.get('/hello-world', handler.helloWorld);app.listen(3000, () => console.log('Listening on port 3000'));

Here’s the Serverless Hello World index.yml file:

这是无服务器Hello World index.yml文件：

service: hello-worldprovider:    name: aws    runtime: nodejs6.10functions:  helloWorld:    handler: handler.helloWorld    events:      - http:        path: hello-world        method: get

Pretty similar really, but I personally love the Express middleware-based approach. For me, it’s more readable and easier to test and debug.

确实非常相似，但是我个人喜欢基于Express中间件的方法。 对我来说，它更具可读性，并且更易于测试和调试。

学习曲线 (Learning Curve)

This is a tricky topic because it depends on what you are trying to achieve:

这是一个棘手的主题，因为它取决于您要实现的目标：

• If you are a Node.js hobbyist and you want to learn how to setup a localhost server on your own computer, Express is for you. Its a great package to experiment with, the “get started” documentation on the website is excellent, and you can easily start to play around with the intricacies of the Node.js event-based architecture.
  如果您是Node.js爱好者，并且想学习如何在自己的计算机上设置localhost服务器，那么Express适合您。 网站上的“入门”文档非常有用，它非常有用，您可以轻松地体验基于事件的Node.js架构的复杂性。
• If you are trying to deploy and manage robust, scalable Node.js APIs, the learning curve is definately easier with Serverless. This is because Serverless deals with many of your complex cloud-based issues out-of-the-box. These include Deployment, Monitoring, and Infrastructure Provisioning to name just a few.
  如果您尝试部署和管理健壮的，可扩展的Node.js API，则使用Serverless无疑会更加轻松。 这是因为无服务器现成地处理了许多复杂的基于云的问题。 其中包括部署，监视和基础结构设置等。

操作-部署，扩展，记录，监视... (Operations — deploying, scaling, logging, monitoring…)

This is where Serverless really comes into its own. Express is not designed to deal with all the complexities of cloud-based architectures by itself. If you use Express, you will need help from other packages:

这是Serverless真正发挥作用的地方。 Express并非旨在单独解决基于云的体系结构的所有复杂性。 如果使用Express，则需要其他软件包的帮助：

For Deployment and Scaling you might use Docker, Kubernetes, Elastic Beanstalk or some other AWS services.

对于部署和扩展，您可以使用Docker ， Kubernetes ， Elastic Beanstalk或其他一些AWS服务。

For Logging, Monitoring, and Error Handling, you might use New Relic, Datadog, Pingdom, and so on.

对于日志记录，监视和错误处理，您可以使用New Relic ， Datadog ， Pingdom等。

You get the idea. Express is a great low-level tool for building APIs, but you need to learn a bunch of other packages for your API to thrive in the modern cloud-based world. This is great if you want to configure your own architectures and have complete control.

你明白了。 Express是用于构建API的出色的低级工具，但是您需要学习大量其他软件包，以使API在现代的基于云的世界中蓬勃发展。 如果您想配置自己的体系结构并拥有完全的控制权，那就太好了。

With Serverless, you get so much out-of-the-box. Not from the Serverless package itself, but because Serverless can automatically interact with all the services in your Cloud Platform. For instance, just with the Hello World index.yml example we saw above, you would get by default:

借助无服务器，您将获得很多现成的东西。 不是来自Serverless包本身，而是因为Serverless可以自动与Cloud Platform中的所有服务进行交互。 例如，仅通过上面看到的Hello World index.yml示例，您将默认获得：

• Monitoring from AWS Lambda
  从AWS Lambda进行监控

• Logging from AWS Cloudwatch

  从AWS Cloudwatch记录

• Autoscaling from AWS Lambda
  从AWS Lambda自动缩放

• Deployment from Serverless & AWS Cloudformation

  从无服务器和AWS Cloudformation进行部署

This is absolutely incredible for fast moving tech teams who want to focus on writing application code, not on managing infrastructure.

对于想专注于编写应用程序代码而不是管理基础结构的快速发展的技术团队来说，这绝对是不可思议的。

Please note: Currently with Serverless, we do not achieve zero-downtime deployment. I think it is possible to achieve with AWS CodeDeploy, but we currently just allow the API to go down for a second or so.

请注意：当前使用无服务器，我们无法实现零停机时间部署。 我认为使用AWS CodeDeploy可以实现，但是我们目前只允许该API关闭一秒钟左右。

成本 (Cost)

For anyone building robust, highly-available APIs on the cloud, cost is a massive consideration. Serverless has reduced our costs by an unbelieveable amount:

对于在云上构建健壮，高度可用的API的任何人来说，成本都是一个很大的考虑因素。 Serverless降低了我们难以置信的成本：

One T2-Medium EC2 Linux Machine on AWS costs you about $33 per month to run. We were using 3 of these machines before switching over to Serverless.

一台在AWS上的T2-Medium EC2 Linux机器每月的运行费用约为33美元。 在切换到无服务器之前，我们使用了其中3台计算机。

With Serverless + AWS Lambda, you get 1 million requests for free each month.

借助无服务器+ AWS Lambda，您将获得 每月有100万个免费请求。

At Pilcro, we haven’t hit this benchmark yet so we have already saved ourselves over one hundred dollars a month. With Serverless and Lambda, we can now run our APIs for free.

在Pilcro，我们还没有达到这个基准，因此我们每个月已经为自己节省了一百多美元。 借助Serverless和Lambda， 我们现在可以免费运行API 。

AWS Lambda运行时 (The AWS Lambda runtime)

One of the downsides of using Serverless is that your API functions are run in the AWS Lambda runtime. This means you are never quite sure what is going on.

使用Serverless的缺点之一是您的API函数在AWS Lambda运行时中运行。 这意味着您永远不确定发生了什么。

You also have to deal with certain oddities of the AWS Lambda function, like the funky event and context objects that are injected into your handlers:

您还必须处理AWS Lambda函数的某些奇怪问题，例如注入到处理程序中的时髦事件和上下文对象：

function awsLambdaHandler(event, context, callback) {  ...}

function expressHandler(req, res, next) {  ...}

I much prefer the req, res, next middleware pattern of Express. It seems more logical and understandable to me.

我非常喜欢Express的req，res，下一个中间件模式。 对我来说，这似乎更合乎逻辑且可以理解。

Another quirk is that for AWS Lambda to run your handlers, they need to be loaded into an execution context. This can take some time. Functions are cached in the execution context for a while, so often the first request to a Lambda will take more time than subsequent requests. This can be irritating if your API is used infrequently.

另一个怪癖是，要让AWS Lambda运行处理程序，需要将它们加载到执行上下文中。 这可能需要一些时间。 函数在执行上下文中缓存了一段时间，因此通常对Lambda的第一个请求将比后续请求花费更多时间。 如果不经常使用您的API，可能会很烦人。

Side note: One of the great things about the AWS Node.js Lambda runtime is that they have the ImageMagick binary installed. So you can do image manipulation in your Lambda functions out of the box!

旁注 ：关于AWS Node.js Lambda运行时的重要功能之一是它们安装了ImageMagick二进制文件。 因此，您可以直接在Lambda函数中进行图像处理！

结论 (Conclusion)

This isn’t really a comparison between Express and Serverless. It’s an acknowledgement that — in the pursuit of robust, scalable cloud APIs — packages like Serverless are offering so much out-of-the-box, that continuing to use Express (alongside other tools) feels like a lot of hard work and learning.

这实际上不是Express和Serverless之间的比较。 可以肯定的是，在追求健壮，可扩展的云API的过程中，像Serverless这样的软件包提供了很多现成的功能，继续使用Express(以及其他工具)感觉就像很多艰苦的工作和学习。

At Pilcro, our APIs are pretty simple and standard. They are comprised of simple REST requests and a few complex image manipulation functions.

在Pilcro ，我们的API非常简单和标准。 它们由简单的REST请求和一些复杂的图像处理功能组成。

Because our APIs are so straightfoward, the decision to use Serverless and Lambda was simple — our main drivers were cost, scalability, and development speed.

因为我们的API非常简单明了，所以使用Serverless和Lambda的决定很简单-我们的主要驱动力是成本 ， 可伸缩性和开发速度。

Cost because … cost.

成本，因为……成本。

Scalability because we are built on top of G-Suite, so we needed to be able to scale extremely quickly and effectively.

可扩展性，因为我们是建立在G-Suite之上的，所以我们需要能够非常快速有效地进行扩展。

Development speed because we needed to deliver Pilcro in 6 months with a small tech team.

开发速度之快是因为我们需要一个小的技术团队在6个月内交付Pilcro。

Serverless has given us these three benefits, which has completely transformed our delivery over the past 6 months. The ecosystem of Serverless is still young, so there will likely be a lot of development in this space over the next 12 months.

Serverless为我们带来了这三个好处，在过去6个月中，这完全改变了我们的交付方式。 Serverless的生态系统仍处于起步阶段，因此在未来12个月中，该领域可能会有很多发展。

帮助您决定是否使用无服务器的步骤 (Steps to help you decide whether to use Serverless)

1. How complex are your APIs? Do you need the low-level configuration and closeness that you get from using Express?
   您的API有多复杂？ 您是否需要使用Express获得的低级配置和紧密性？
2. How do you currently manage Deployment, Scaling, and Monitoring? Are you happy with your solution? How quickly could a newly hired developer learn all the different parts of your architecture?
   您目前如何管理部署，扩展和监视？ 您对您的解决方案满意吗？ 新聘的开发人员能多快学会架构的所有不同部分？
3. Could you save any money by switching to Serverless?
   通过切换到无服务器，您能省钱吗？

If you liked this story, please ? and please share with others. Also please check out my company pilcro.com. Pilcro is brand software for G-Suite — for marketers and brand agencies.

如果您喜欢这个故事，请？ 并请与他人分享。 还请查看我的公司p ilcro.com。 Pilcro是G-Suite的品牌软件-适用于营销商和品牌代理。

翻译自: https://www.freecodecamp.org/news/node-js-apis-on-aws-the-pros-and-cons-of-express-versus-serverless-a370ab7eadd7/

node aws 内存溢出