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獲取它：