nodejs 调用微服务器

by Filipe Tavares

由Filipe Tavares

无服务器NodeJS：构建下一个微服务的快速，廉价方法 (Serverless NodeJS: the fast, inexpensive way to build your next microservice)

I love Node.js. I’ve re-discovered Javascript through it, and I’m never going back.

我喜欢Node.js。我已经通过它重新发现了Javascript，并且再也回不去了。

Its lightweight character, non-blocking nature, and quick development experience shine in Microservices.

它的轻量级特性，无阻塞性和快速的开发经验在微服务中大放异彩。

I also love Express — it makes writing server applications so simple. And its Connect-based middleware stack approach makes extending applications easy and fun. Couple it with Docker and the sky’s the limit. Or, better yet, go serverless.

我也喜欢Express-它使编写服务器应用程序变得如此简单。其基于Connect的中间件堆栈方法使扩展应用程序变得轻松而有趣。将其与Docker结合使用，无极限。或者，更好的是，变得无服务器。

比小还小... (Smaller than small…)

First they gave us Servers, so we built Service-Oriented Architectures.

首先，他们为我们提供了服务器，因此我们构建了面向服务的体系结构。

Then they gave us Containers, so we built Microservices.

然后他们给了我们容器，因此我们构建了微服务。

Now they give us Serverless Event Handlers, so we’ll build Functions.

现在，它们为我们提供了无服务器事件处理程序 ，因此我们将构建函数。

Our hosting platforms have become more amenable to deploying smaller units. And so have our applications broken down into smaller software packages. There are many reasons for this, and there are diverging opinions on whether it’s a good thing.

我们的托管平台已变得更适合部署较小的单元。我们的应用程序也细分为较小的软件包。造成这种情况的原因有很多，关于这是否是一件好事，人们有不同的看法。

But if we look back at the original concepts behind cloud computing, there was a dream of having code distributed infinitely in a network of connected computation nodes. We’re getting a little closer with the emergence of serverless platforms.

但是，如果我们回顾一下云计算背后的原始概念，就有梦想将代码无限地分布在连接的计算节点的网络中。随着无服务器平台的出现，我们之间的距离越来越近了。

Plus: they allow us to scale infinitely, while only paying for what we use.

加：它们使我们可以无限扩展，而仅需支付使用的费用。

…但不要太小 (…but not too small)

Sequences of computational steps (procedures) need shared memory to execute efficiently. We wrap those around a function definition, that defines a contract for its input and output. And this allows composition with other such functions.

计算步骤(过程)的顺序需要共享内存才能有效执行。我们将它们包装在一个函数定义周围，该函数定义了其输入和输出的协定。并且这允许与其他这样的功能组合。

This approach has been very successful in the architecture of Unix, and is one of the reasons for its longevity and ubiquity. I don’t mean to suggest that Web applications should follow a comparable cloud-based shared eco-system (though some are trying). But we can benefit from applying similar principles when building Web applications.

这种方法在Unix体系结构中非常成功，并且是其长寿和普遍存在的原因之一。我并不是要建议Web应用程序应该遵循可比的基于云的共享生态系统(尽管有些人正在尝试)。但是，在构建Web应用程序时，我们可以从应用类似原理中受益。

Beyond function definitions, we also group closely related functions in modules. An example could be the CRUD operations for data within a given domain, such as user management. Those tend to share code, like data models, parsing logic and formatting. So when we deploy individual functions to serverless environments, we end up with lots of duplicated code.

除功能定义外，我们还将紧密相关的功能分组在模块中。一个示例可能是给定域内数据的CRUD操作，例如用户管理。那些倾向于共享代码，例如数据模型，解析逻辑和格式。因此，当我们将单个功能部署到无服务器环境时，最终会产生大量重复的代码。

Current serverless environments encourage single-function deployment. But, when applied to Microservices, that leads to messy stacks that are hard to manage.

当前的无服务器环境鼓励单功能部署。但是，当应用于微服务时，会导致难以管理的混乱堆栈。

But let’s assume we don’t mind duplicated code deployments. After all, we can deal with it in our code repositories. We still want to share temporary resources, though, such as database connections. We also want to make sure that we deploy and manage all operations for the same domain as a single unit. We’re better off managing function modules.

但是，假设我们不介意重复的代码部署。毕竟，我们可以在代码存储库中处理它。但是，我们仍然希望共享临时资源，例如数据库连接。我们还想确保我们将同一域的所有操作部署和管理为一个单元。我们最好管理功能模块 。

It fits well with the Single Responsibility Principle:

它非常符合“ 单一责任原则” ：

Gather together those things that change for the same reason, and separate those things that change for different reasons.

将由于相同原因而改变的那些东西聚集在一起，并把由于不同原因而改变的那些东西分开。

走向无服务器 (Going serverless)

So, Node.js is great for Microservices. And it’s also great for writing smaller function modules. And Express is great for building Web application in Node.js.

因此，Node.js非常适合微服务。这对于编写较小的功能模块也非常有用。 Express对于在Node.js中构建Web应用程序非常有用。

Yet, most serverless environments already handle many common Web server functions out of the box. And for these Nanoservices, that provide a mere handful of functions, we shouldn’t bother with the overhead of complex Web server logic. We must leverage HTTP, as it is the ubiquitous transport mechanism between Web services. But we should do it in a more RPC (Remote Procedure Call) kind of way.

但是，大多数无服务器环境已经开箱即可处理许多常见的Web服务器功能。对于这些仅提供少量功能的Nanoservices ，我们不应理会复杂的Web服务器逻辑的开销。我们必须利用HTTP，因为HTTP是Web服务之间无处不在的传输机制。但是我们应该以一种更多的RPC (远程过程调用)方式来实现。

This is where most current frameworks offer a sledgehammer to crack a nut. If anything, I’d argue that going serverless frees us from frameworks, to focus instead on building purer functions.

这是大多数当前框架提供大锤破解螺母的地方。如果有的话，我会认为无服务器化将我们从框架中解放出来，而专注于构建更纯净的功能。

Yet, there is a need for basic routing within a Nanoservice, to map incoming requests to the appropriate handler function. Also, because of the proprietary nature of these commercial serverless environments, we can make a case for having a certain level of abstraction, to decouple our functions from the specifics of the platform they’re executed in.

但是，需要在Nanoservice中进行基本路由，以将传入的请求映射到适当的处理程序功能。同样，由于这些商业无服务器环境的专有性质，我们可以提出某种程度的抽象，以使我们的功能与执行它们的平台的细节脱钩。

Functional programming applied to serverless deployments is likely to surface in more applications. Which I’m very hopeful about, because it feels like a step in the right direction. We still need to address many real-world considerations like latency, performance, and memory usage. But like with Microservices, we’ll find the right set of tools and practices to make this not just practical, but also highly performant on real-world applications.

应用于无服务器部署的功能编程可能会在更多应用程序中浮出水面。我对此充满希望，因为这就像朝着正确方向迈出了一步。我们仍然需要解决许多现实世界中的注意事项，例如延迟，性能和内存使用情况。但是，与微服务一样，我们将找到正确的工具和实践集，以使其不仅实用，而且在实际应用程序中具有很高的性能。

云功能中的模块 (Modules in Cloud Functions)

I wrote a small Node.js package to address these needs. It’s called modofun.

我写了一个小的Node.js包来满足这些需求。它称为modofun 。

It carries no extra dependencies, because we want our deployments to be as small as possible. It adds minimal functionality to simplify deployments of function modules on serverless platforms. It also allows extensibility through existing middleware, such as authentication, logging, and others. Here are a few of its features:

它没有额外的依赖关系，因为我们希望我们的部署尽可能小。它添加了最小的功能，以简化功能模块在无服务器平台上的部署。它还允许通过现有的中间件进行扩展，例如身份验证，日志记录等。以下是其一些功能：

Basic routing to functions
基本功能路由
Parameter parsing
参数解析
Automatic HTTP response building
自动HTTP响应构建
Support for ES6 Promises (or any other then-able)
支持ES6 Promises(或随后的其他任何支持)
Connect/Express-like middleware support
类似于Connect / Express的中间件支持
Google Cloud Functions
Google Cloud功能
AWS Lambda (with AWS API Gateway events)
AWS Lambda (带有AWS API Gateway事件)
Automatic error handling
自动错误处理

Support for Azure Functions coming shortly.

即将提供对Azure功能的支持。

使用Modofun (Using Modofun)

Modofun makes it easy to expose functions as serverless cloud request handlers:

Modofun使将功能公开为无服务器云请求处理程序变得容易：

A simplistic router maps incoming requests to functions. It applies the trailing components of the URL path as function arguments. Other request data is also available as context (this) for the function invocation.

简单的路由器将传入的请求映射到功能。它将URL路径的结尾部分用作函数参数。其他请求数据也可以作为函数调用的上下文( this )使用。

We can specify middleware that will run for every incoming request. Or apply it selectively to individual functions (more details in the documentation). Modofun returns the appropriate handler for events generated by the serverless platform.

我们可以指定将为每个传入请求运行的中间件。或有选择地将其应用于各个功能( 文档中有更多详细信息)。 Modofun返回由无服务器平台生成的事件的适当处理程序。

Get it with npm:

用npm获取它：