VBo*_*oss 4 node.js microservices
我目前正在NodeJ中开发微服务架构。我的第一种方法是package.json每次服务。但是,对于所有微服务,在访问公共区域(使用日志记录或数据库实用程序)时可能会非常棘手。例如:
common-area >
logger.js
package.json - install module typeorm
service1 >
app.js - use logger.js
package.json - also install module typeorm
Run Code Online (Sandbox Code Playgroud)
运行node app.js(服务1)时,一旦完成两次不同的安装,最后将加载2个typeorm模块,其中一个安装在公共区域(由logger使用),另一个安装在service1。
我是否应该仅对package.json所有微服务使用一个,导致只创建一个node_modules文件夹?
我是否应该对所有微服务仅使用一个package.json,而仅在一个node_modules文件夹中生成>?
在进行微服务时,您不必担心会有多个node_modules目录,因为微服务的要点之一是能够将它们放置在单独的主机或单独的容器中,并且它们将始终无法共享其依赖项。
每个微服务都应该是一个单独的服务。您应该避免紧密的耦合以及可能因对抗微服务架构并将它们结合在一起而导致的抽象泄漏。
当然,微服务不是唯一可以在实践中使用的架构,但是您想要微服务,那么每个微服务都应该是完全独立的。否则,它不是微服务。
如果可以在服务之间共享任何通用代码,则将其放入所有或某些服务所需的模块中。您可以在npm上保留私有模块,可以托管私有npm注册表,也可以直接从GitHub或GitLab私有存储库安装该模块。添加托管在GitHub上的私有(或公共)模块所需要做的就是运行:
npm install user/repo --save
Run Code Online (Sandbox Code Playgroud)
user您在GitHub上的用户(或组织)名称在哪里,是repo存储库的名称。请记住,如果要在私有存储库中安装此类模块,则该计算机上使用的ssh密钥必须属于对存储库具有读取访问权限的用户。您还可以在GitHub上使用部署密钥,以提高灵活性。
您甚至可以通过创建一个包含所有依赖项并将其一次公开给您的服务的单独模块,来简化在服务中加载外部依赖项的过程。例如,如果您创建一个名为的模块dependencies,则该模块如下所示:
module.exports = {
_: require('lodash'),
P: require('bluebird'),
fs: require('mz/fs'),
// ...
};
Run Code Online (Sandbox Code Playgroud)
然后,您可以像这样在微服务中使用所有这些模块:
const { _, P, fs } = require('dependencies');
Run Code Online (Sandbox Code Playgroud)
当您拥有大量的小型微服务时,尤其是将它们拆分为多个文件时,这可以使事情简化很多。