软件配置设计、访问与管理

软件配置设计、访问与管理

前言

最近在进行项目维护与新的feature开发过程中，涉及到为新的部署环境增加配置问题。
服务本身涉及到使用不同的计算与存储环境，所以配置需要在最简化的代码逻辑下兼容不同的环境。
同时不同的计算任务托管在服务上，服务需要协助管理任务的运行环境，即配合管理并准备任务使用的环境变量及专门的配置。

复杂的配置项信息增加部署服务的复杂度。

由此，产生了对软件配置的设计与管理的一些想法。

结构化软件配置中可扩展性设计

软件的设计模式不仅应用在软件代码设计上，在软件的配置上也同样可以应用。软件的配置项，是将实体信息从抽象的软件层抽离出来，独立进行管理的数据信息。所以其设计逻辑本身也颖遵循一定的设计模式，以便进行配置的修改增加与保持兼容。

很多结构化的配置设计，仅仅简单的进行分层设计，这在大部分的软件应用问题并不大，但是对于使用同一个配置访问同一性质的不同服务，如slave节点、不同的消息队列、不同的计算集群、不同的存储服务，在分布式软件中，将会愈来愈频繁的接触到。

这就要求，在对此类配置进行分层的时候，要充分考虑到可扩展性。
例如，对于多个slave节点的连接配置，在分层的时候，是直接在顶层填入IP项，或是以子网划分，或是以slave节点划分，都要根据服务（业务）发展方向来设计；又例如，使用不同的云厂商服务，先按计算、存储、消息队列等服务划分，再划分不同云厂商的服务，或是先基于云厂商划分，再分别配置各自使用的服务，都需要参考服务扩展方向而定。

诚然，按哪一种方式划分，其不过是一份配置文件，如果软件设计的好，对于读配置的逻辑并不会有太多的影响，对于使用配置的逻辑层则几乎没有影响。但是对于部署的同学来说，上线前生成一份正确的配置，快速便捷的理解配置的内容，是非常必要的。就如同，不写文档，代码混乱不可怕，不为黑魔法写清楚注释，则软件维护将非常辛苦。软件工程，不是一个人做完即完的。

配置解析抽象化

软件配置无论如何设计，都是为了软件可以准确的读取，以便作为提供服务的标准数据。

结构化与扩展性是为了新增配置的时候运维同学可以便捷理解与顺利部署。同时，也是为了解析配置的逻辑维护性和扩展性更高。

所以完成配置设计之后，配置解析模块就需要做充分的抽象化设计。

许多软件都会对软件配置解析模块进行独立的维护，并将解析的配置以全局变量的形式暴露出来供逻辑层访问。最朴素的做法则是将配置加载到内存后，由逻辑层自由访问，即由软件逻辑根据实际使用情况去解析出配置数据。

这种设计的缺点在于，一旦配置结构发生变更，软件维护将变得非常困难，需要有非常充分的测试（我们知道，很多时候测试工作都是不完整的，要做到完整的测试则将耗费非常多的人力物力）。如果对于配置先行抽象化的处理，并实体化每一个配置形成一个独立的实体对象，则对于逻辑层，仅需要选择与加载不同的配置实体，组成自己的逻辑实体，将从配置解析层面完成对软件与配置的解耦。对于配置扩展与变更，将不会对软件的逻辑层面造成过多的变更操作。这将大大增加软件的可维护性。

环境变量 or 配置文件

关于配置信息的管理，一般有三种模式，第一是配置文件的形式，第二是环境变量的形式，第三是从其他服务（如配置中心）中读取的形式来进行。第三种模式的管理方法，更多的是考虑到配置访问安全的情况与配置统一管理等相关，在本篇不详述。

对于从环境变量或者配置文件读取，不同人使用的感受不一。

环境变量访问的好处在于，在启动脚本中预置了环境信息，部署灵活，尤其是对于需要访问多个配置文件的应用，为每一个配置文件分配环境变量是每一个独立访问配置的应用的默认设置（一般而言，配置文件的路径放置在home目录下，但是也可能将配置文件放置在特定目录并以环境变量暴露给应用，应用也将优先从该路径加载配置），使用环境变量可以避免增加多一个配置多一层维护逻辑，同时也是应用访问配置的常规方法。

对于配置信息较为简单的应用，使用环境变量可以避免在实体留下持久化的信息（尽管环境变量的信息也可以被读出来），而简单的环境变量维护起来也更加简单。

看起来，使用环境变量是有利于减少维护成本的。但是我们不能忽略，使用环境变量的前提是，第一软件有约定好的使用环境变量的设计，第二配置信息比较简单。也就是说，使用环境变量的约束本身就很大。

所以，对于第一种情况，由部署方决定，是否为多个服务的不同配置信息创建统一的配置与访问入口，并在启动相应的应用之前暴露到环境变量中；或是由多个应用的统一管理服务来确定。对于第二种情况，则在设计过程中，要着重处理好访问优先级，避免环境变量的篡改导致应用出错。

总之，使用环境变量是一件低成本高风险的操作方法，需要谨慎。