假设有这样一个工程，是这样设计的：
1整个软件、服务被切分为 由若干独立的多道程序（多个进程/微服务）；
2 这些多道程序只是“机制mechanism”，而“策略strategy”写在各自用到的配置文件里。
3各策略配置文件由不同人在不同地方写，而机制部分读取，可以是在服务启动前的编译时，也可以是运行中的运行时。
大概有这么几种风格：
1 分布式：配置文件在每个服务的代码路径下，每个服务进程知道配置文件，比如每个文件夹下放给定名字的配置文件。
2 集中式：集中于类似windows“注册表”的地方，集中管理。
3半集中式：类似node工程里各种.XX文件和XX.json文件，集中于1个文件夹内，但各自对应各自的服务，互相独立。
1就是每个独立的软件安装路径下的配置文件。
2 windows注册表的好处是集中管理，查找方便。坏处是，什么注册表蠕变，注册表挂了整个系统瘫痪了，各种问题。
3形如大路货的node工程：
除了几个文件夹之外，和一个readme.md，其他的都是“策略配置文件”。
站在配置文件的消费者：开发人员，每个独立服务编译/运行时角度来说，当然是就近读取，在每个服务根目录下，按给定的名字，这样最好。
站在策略内容的维护者，生产者角度，业务使用者角度来说：当然是集中式好，在一个类似注册表编辑器的界面里，按自己角度划分的树状结构，集中修改数字，增加配置，然后一保存，服务就更新了。
——有点像作战等等对待资源：
弹药、粮食最终是一线各分队，班、排使用掉的，一定要分散、分发下去。不能集中管理在某个大后方仓库，让各班排自己来取。当你真的体恤下情，各班排专注于各自任务，负担已经够重了，要让它们集中聚焦，就不能增加它们的其他负担；
而资源的生产，维护又少不了集中。大田肯定比散落在各处的梯田好管理。集中了才不容易挂一漏万，缺了哪个配置项，应该在某个层级看的很清楚。类似后勤部长。分散下去了，难以生产，难以监测改变. 易于腐烂变质。
因此，如果机制与策略分离，可以参考node，这样设计整个工程：
对于代码和数据的生产者，维护者，相对集中：
代码、机制部分放在node_modules,src这样地方。
配置、策略部分在某个地方比如根目录，半集中地放置在这里。便于编辑，但是和机制部分分离。
而软件在运行时：相对分散：
每个独立进程封装到1个docker容器里，在容器配置文件里，用-v挂入配置文件+用cli参数传入到启动命令，实现策略的注入、链接。
这样，每个进程实际上在运行时还是“就近”获得了配置文件，不用自己关心去哪里取。
利用docker的方式，即实现了个进程运行时的隔离，由实现了配置的分发。
对于那些以函数库形式出现的服务，不表现为独立进程。但参考node工程的方式，还是用独立的配置文件保存在调用者便于取到的地方，比较适合。
当每个函数库独立开发时，test肯要模拟调用者，那么配置文件就要在test文件内。
——总之，处理好集中与分散，让集中和分散各自发挥出威力，才能真正让整个工程在运行时运转自如，而维护又很省力。