NodeJS 后端开发09 多环境Profiling优雅根据不同环境自适应
学委好久没有更新NodeJS专栏，还以为NodeJS冷门，没想到最近看到几个读者留言问怎么优雅的管理多环境的配置。
太忙了，写篇短文简单展示一下原理。正好基于前篇 【NodeJS 后端开发 07 MySQL数据库连接池开发生产应用 】简单尝试了mysql库来连接数据库。
本篇尝试一个更加优雅的方式，通过环境变量来控制程序动态加载不同的配置。
这个搞Java的同学最清楚，比如我们开发springboot应用的时候会放置多个application.yml。
然后部署的时候通过环境变量来选择配置。
这个用NodeJS来做就更加简单了
NODE_ENV=process.env.NODE_ENV console.log('NODE_ENV:', NODE_ENV) 配置一个环境变量，重试代码
export NODE_ENV=雷学委 继续根据环境自适应的profiling。
上面展示了设置不同变量代码中能够获取到该环境变量的值。
安照这个机制，我们可以把配置文件按照下面进行命名，让程序加载不同的文件名，比如下面：
- config.dev.json
- config.testing.json
- config.prod.json
然后只需要写一份应用代码：
复制下面代码保存为app.js
//雷学委Demo代码 const NODE_ENV=process.env.NODE_ENV || 'dev' console.log('NODE_ENV:', NODE_ENV) //定位当前目录下的config.<环境类型>.json const configPath = __dirname + '/config.' + NODE_ENV + '.json' console.log('configPath:', configPath) //加载并打印数据库的配置细节 const dbConfig = require(configPath) console.log('dbConfig:', dbConfig) 我们直接来看效果；
运行代码在这：
#开发环境启动应用 node app.js #测试环境启动应用 export NODE_ENV=testing && node app.js #生产环境启动应用 export NODE_ENV=prod && node app.js 好了到这里读者应该能够懂得profling如何做了。（可以三连了）
下面看看为什么。
为啥搞这么多外部配置，直接写在代码里面根据主机名字加载不好么？
学委想对小白说的： 比如说一个游戏的新功能，往往会经过开发机器调试，然后大量测试，把大量的潜在的重要的bug解决了，提拔到预发布，最后到生产环境。这个过程通过一些列的自动化测试，回归测试，可以大大保证系统的质量。还有一种高端玩法就是灰度发布，加上这个制度，这就是我们常说产品平滑上线的流程了。
这好像扯远了，产品发布这一套能再写亿篇！
我们回到主题，通常就是只开发一份代码，发布到不同环境之后，程序动态的连接到正确的数据库，加载对应的数据，数据虽不同但是程序在任意环境的行为要绝对一致。
这里配置外部化考量是：配置外部化可以减少代码跟环境的耦合
而不是发布一个类型的环境，就得修改代码。
特别是互联网/金融项目都会有严苛的质量把关，哪怕是修改一个标点符号，整个产品提升的过程都得从开发环境重新来过。
因此，配置外部化很有必要。
那么，应用能否跟外部环境毫无关联？
比较有经验的朋友，可能会想匿名函数，或者亚马逊的lamda，或者serverless app（无服务器应用）
如果业务没有任何环境区分，那就可以做到程序跟环境没有耦合，这就充分的说明了serverless的一个优点！（没有耦合，意味着随便拿一个云服务器部署，即可轻松实现弹性伸缩了，但这并非此文出发点，有机会再说）
更多代码可以查看/Star： LearnNodeJS代码下载
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/233046.html原文链接：https://javaforall.net
