前言
99%以上的后台应用服务都离不开 服务配置信息 这个基础功能，例如：程序要监听哪个端口，要连接的数据库配置信息等等。
好的配置模块设计应该足够健全，包括 配置内容合法性校验 、 与代码解耦 、 能够完美切合服务部署方式 等。
在这里主要讲我认为最重要的一点：能够完美切合服务部署方式
这个是在设计配置模块时重要考虑的地方。服务部署的时候可选方案是很多的，并且我认为没有最完美的解决方案，只是针对具体场景有最适合的部署方案。
首先从成本上来说：只有一台服务器，怎么上集群？集群都不用想了，那主流可选方案有 pm2 、 docker-compose 两种。
接下来要考虑服务是否多开问题，众所周知，服务器核心数一般都会很多，而且nodejs是单主线程的模型，通常我们都会多开。但是这并不是绝对！如果遇到I/O和运算都不重，甚至很轻的应用，并且有特色功能的应用来说，多开反而还增大开销！举个例子： 股票数据采集服务。 这个服务给公司的股票研究员来用，那么I/O可以预见，极低; 同时并不需要很重的运算，因为大部分都是从数据库中取出来信息，之后展示出来！这个应用的核心在于定时爬去网上公开数据，假设设置为每天下午3:10开始爬取，那么多开就会上分布式锁或其他方式（例如pm2 fork模式的主进程）来保证多个服务不会重复爬取，因此这类服务单实例部署就非常合适了（PS：高可用需求并没有考虑，因为用户固定，没有这个需求）
一台服务器上部署很容易，单实例更是容易加容易，如果无运行中更改配置并持久化的需求，那么通过 配置文件 就可以轻松搞定配置模块，在系统启动的时候读取固定位置的配置文件中的内容，作为系统配置即可。 pm2多开 在很大程度上也可以采用配置文件方式，但是 docker-compose 的多开不建议使用配置文件，当然，强行使用 volume 挂载配置文件也是可以的。最好的方式是使用官方推荐的 environment 参数，在 docker-compose.yml 文件中可以任意指定配置，同时也为后期的集群部署方式打下基础。
如果有多台服务器组建集群，那么肯定是 分布式部署 了，数据最起码采用 副本集 ，按需上 分片集 和 异地容灾 、 双机热备 等功能。
实现
最好是能够建立通用的配置设置，既可以通过配置文件，又可以兼容容器的 environment 配置。
对于配置文件方式， nestjs 官方已经提供了这个功能，官方文档，熟读文档就能发现可以通过 .env 文件或者 yaml 格式文件来写入配置，我们选取 .env 文件作为配置文件，因为 yaml 格式文件需要增加额外的包。
对于配置文件校验功能，官方文档是通过 @hai/joi 这个包来实现的，但是 npm 上这个包已经搜索不到了，推荐使用使用joi这个包。具体使用会在示例项目中介绍。
接下来是兼容容器的 environment 配置，根据文档，这个里面写的配置会挂到 process.env 中，而 @nestjs/config 包将配置文件的内容也是挂载到 process.env 中，下面就是搞懂配置优先级了，经过查询探究，发现配置优先级如下：(从左到右，优先级逐渐降低)
