分散的配置文件VS集中的注册表

假设有这样一个工程，是这样设计的：

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文件内。

——总之，处理好集中与分散，让集中和分散各自发挥出威力，才能真正让整个工程在运行时运转自如，而维护又很省力。