https://gitee.com/sleepywang1024/easyconfig/blob/master/design-principle.md
easyconfig的设计理念
用户是一个产品的前提，用户是谁决定产品的发展方向。配置管理的用户是谁呢？研发人员(包括产品)、运维人员、还是业务用户。
定位为研发人员。不得不说，在存在配置中心这个工具之前，系统的配参一直都归属于研发团队管理，没人对这个问题存在歧义。他们采用的手段也比较初级，如环境变量、启动参数、属性文件等。
定位为运维人员。建设了配置中心后，确实有不少公司是这么管理的，研发人员要调整一个应用系统参数，就发一个申请邮件(或工单)，经过审批后，由一个神秘的运维后台人员完成修改和发布。
定位为业务用户。系统参数他们搞不懂，业务参数属于业务的规则管理，应该为他们提供更友好的管理界面。
虽然运维人员和业务用户对特定某些配参有管理需求，但无论如何都要明确定位首要用户，easyconfig定位的用户就是研发人员(包括产品)。
运维人员有特定的配参需求，RAM、vCPU、HD、网络带宽、访问安全、日志采集、启动变量、JVM及配置、等等，这类工作反而需要一个真正的配置中心来管理，而不是配置管理组件。 遗憾的是现有的配置中心产品也解决不了这些问题，运维人员有自己的办法。
有了定位的用户，就可以研究用户的痛点和需求，什么样形态的产品，能更好地满足用户使用。
通常认为，对配置管理主要需求是如下：
统一管理。一个系统内所有配置要统一管理，而非任意系统之间的配置。一个系统在不同环境下的配置要得到管理，避免环境之间配置混乱。
确保安全。版本管理、变更恢复、审查审计等。
联机更新。立即生效不用重启。
客观上讲，这份需求还不尽如意，前两项都在强调“管理”，而不是“配置”。首先应该是把配置(配参)这个工作的内容、质量、效率做好，更容易和更灵活地进行配参，然后才是对配参工作的活动、任务、流程进行管理。Easyconfig同时关注这两类事情，但希望在配置上做更多更好，例如：
复杂数据类型
类型检查校验
敏感数据加密
变更灰度发布
多profiles配置，如针对每一应用实例节点配置
支持前端开发
同时希望在管理方面做的更好，例如：
配参自动加载及格式推导
多种完善的恢复机制
两阶段变更，如申请-审批
导入导出支持
配参分组管理
使用详情探查
市面上有些产品管理的内容是“配置文件/配置文件的内容”，配置文件实际是配置参数的管理工具，并不是配参要管理的根本目标。easyconfig强调针对一项项具有具体系统含义的参数，以及它们的不同特点，提供针对的友好的管理支持。每一项参数具有不同的数据类型以及更细致的有效性规则(参数类型管理)，以及若干项相关参数需配合要共同支持一个业务功能(属性组管理)。
配参管理的用户是研发团队，设计的方案首先要方便研发人员使用。
方案一：运维负责的配置中心。研发团队一定不希望自己的决策需要另一个不懂自己工作的部门审批和执行，冗长、低效、扯皮、受制于人。
方案二：研发中心负责的配置中心。研发中心共建一个配置中心，通过权限进行分割，不同研发团队自己做主管理自己的配参。这种方式是OK的，只是有些麻烦。不同研发团队之间的工作并没有交集，但因为共享一个工具，需要跨小组进行账号分配与管理。
方案三：每个研发小组(产品)拥有独立配置中心。没有方案二的问题，但问题是要自己建设（或部署）及维护配置中心。由于配置中心对系统运行非常关键，其可靠性不能低于业务系统，配置中心需要集群部署，尽快其负载非常小。这一系列动作下来导致投入回报不成比例，所以这不是一个好方案。
基于前面的讨论分析，于是产生了
方案四：每个系统拥有独立的配置管理模块。
不是一个独立的配置服务中心，而是依附于业务系统的一个模块。这是easyconfig的选择，是基于以下认知的理性选择。
配置管理的用户是研发团队。不同系统/研发团队之间的配置管理工作没有关联，可独立存在。反而是捆绑到一起的集中管理需要付出不小的管理成本。
配置管理的可靠性不低于业务服务，保持一致可以满足需要。
配置管理不是业务系统的核心，需要设法减少在其上的投入，无论是设备、研发与维护、理解与学习。而把配置管理作为应用系统的一部分，而不需要是另一个系统，能大幅减少设备和维护的成本。
把配参存储近宿主系统的主数据库，并且是关系型数据库，这样设计出于一系列考量，包括
关键数据。系统配参是系统的关键数据，需要得到妥善的保管和管理。
环境亲和。系统主存储直接与环境关联，开发、测试、生产环境是分离的，存储于此的配参自然也是分离的。
架构简化。研发领域，复杂性是万恶之源。
维护方便。配参维护、备份恢复等，有大量工具可用。
简单直白。采用文本的形式存储，便于人工识别、跨系统兼容。甚至手工就能进行维护，这为宿主系统提供极大的灵活性和自主性，无需担心引入组件给自己后期工作带来麻烦。
easyconfig在各种特性优先级选择上，优先次序如下：
可靠性
易用性
功能性
安全性
easyconfig所看重的，除了反复强调的可靠性外，易用性是第二优先级，最低优先级是功能性，但并非不重要。
可靠性是不给研发和系统制造麻烦。这是绝对要保障的。
易用性是不给研发制造工作量。这是优先要保障的。
功能是是给研发提供价值和帮助。这是努力要提供的。
安全重要，但满足需要就好。
在软件研发领域，复杂性是万恶之源。easyconfig设计实现追求易用性，不给应用系统软件带来复杂性。对easyconfig自身来讲也是如此，其自身也要优先选择在满足需求的基础上，采用简单的方案。
easyconfig选择的package名字 jm.easyconfig。jm就是jianming的缩写，可以理解为“简明”：简明扼要；也可以理解为“见明”：看见就明白；真实想法是想表达“看见明德”：洞察事物本来面目，不被复杂困扰，不被表象迷惑、不被人欲遮蔽。
