对于分布式应用来说，配置中心或许是不可或缺的一环，那么为什么需要有配置中心呢？直接把数据写到MySQL、Redis、Zookeeper或者是直接写到项目中的配置文件，需要的时候进行读取不很好吗？为什么要构建一个独立的服务呢?

加入我们不使用配置中心，我们可能会这么做:

1.把配置直接写死到配置文件中，可以是xxx.ini，也可以是xxx.properties，或者是xxx.xml或者xxx.yaml。如果配置是以代码的方式或者是配置文件的方式写死的话，那么每次修改配置都会伴随着代码的发布和上线，这对于很多场景来说并不合适。比如说某个功能的开关想临时打开一小时，一小时后就关闭了，如果是采用发布代码的方式这样做显然是不合适的。

2.把配置写到数据库或缓存中，比如MySQL或者Redis。这种使用的时候动态拉取的方式，如果不在本地做cache，那么会频繁访问并且造成性能问题，如果有cache，并且时间较久的话，那么又可能会造成更新不及时。

3.把配置写到配置服务中，比如zookeeper。虽然zookeeper支持客户端监听节点的值的变化，但是它不能支持的内容依然很多，比如配置的回溯，配置的快速构建，比如灰度配置等等。

StarConf的定位:
1.功能足够强大的应用。虽然也有很多开源出来的配置中心，比如Apollo，比如QConf，比如DisConf，比如Diamond，但是都做得略显单薄，笔者并没有不尊重的意思，虽然各有侧重点，但是个人感觉不够通用。
2.易于使用。配置中心的存在是为了简化配置过程，不是为了加大配置的难度，如果说

StarConf作为一个理想中的配置中心，我们会从如下几个方面来介绍它:多环境、高效、安全、容错、分布式。下面是关于它们的具体说明:

1.【多环境】多环境支持，允许定义别名，允许快速克隆，允许环境比对。

对于一个正式的开发组织来说，通常会有很多环境。比如常见的环境定义有如下几个: ①local环境表示开发者的环境。②dev环境表示统一开发环境。③qa环境表示测试环境，也会有人叫test环境。④beta环境表示线下稳定环境。⑤st环境表示灰度环境，也会有人叫protect环境。⑥online环境表示线上环境，也会有人叫prod环境。而且有时候可能对于qa环境还会分为qa1、qa2、qa3等。

StarConf允许定义多个环境，比如dev环境和qa环境，不同环境之间的配置是互相隔离的，但是可以一键同步到其他环境中去。

StarConf还允许定义别名，比如test环境和qa环境可以是一个环境，这对于大型公司来说尤其常见，可能不同部门的人叫法都不太一样。

StarConf还允许快速克隆，比如在线下配置好的环境数据可以一键同步至线上，从而快速完成上线。还可以把线上环境一键克隆到一个新的环境，用来快速定位线上问题，这些都是被认为是很好的特性且被支持。

StarConf还允许环境之间做比对，比如我们可以在上线前看一下线上环境和线下环境的配置都有哪些区别，这样可以让我们的上线流程更加顺心。

2.【高效】多应用支持，应用支持快速克隆和继承。

对于一个较大的组织来说，很可能会面临多应用的问题，但是这些应用之间又有着千丝万缕的联系，配置之间也可以进行共享。

StarConf支持您基于一个应用快速构建另一个应用的配置。应用克隆指的是一个应用可以克隆其他应用的配置，从而快速产生一个应用，这样可以免去很多不必要的啰嗦的配置。

StarConf也支持您更小成本的复用配置项。应用继承指的是某个应用可以继承自其他父应用，一个应用只能有一个父应用。设计良好的应用列表应该是一个树形结构，而不是一个网状结构。比如我们有B端应用(com.mengzhidu.bservice)，服务下面有一些公共配置，B端服务下面有一个大客户应用(com.mengzhidu.bservice.keyaccount)，大客户服务下面又有专门的回访应用(com.mengzhidu.bservice.keyaccount.revisit)，一个应用下面可能有零个配置，也可能有很多配置，但是它的子应用都会继承父应用的配置。

3.【安全】足够健壮，支持应用鉴权、用户认证。

应用鉴权指的是应用之间不可伪造，通常使用签名的方式来验证服务的正确性。它的作用主要是两个:①避免黑客的攻击，当然这得建立在黑客无法拿到密钥构建签名的基础上。②确保应用能够获取到正确的配置，因为不同应用之间使用不同的密钥，A应用调用B应用的配置时会提示签名错误。

用户认证主要是指两个方面，即某个用户想要修改某个应用的配置的时候，首先要确定它是有修改这应用的权限的，从而避免水平越权和垂直越权。

4.【容错】可追溯，支持回滚。

StarConf是一个可靠的配置中心，它会记录一个配置是什么时候由谁修改的这一关键信息，方便问题的定位和排查。

StarConf还为误操作提供了一个很大的弥补措施。如果不小心进行了误操作，那么您可以使用一键回滚来快速回到过去的某个配置上，从而更快的挽救错误。

5.【灰度】可以灰度性的配置。

有些时候配置可能是高危操作，这个时候也可以渐进的方式生效。比如我有十台服务器，我第一次可以只让一台服务器使用新配置，其他九台服务器使用老的配置，第二次可以再新增三台，第三次再新增三台，第四次全量使用新配置。

6.【分布式】分布式，避免单点故障。

所谓的分布式主要是可以分布式部署，从而一台机器宕机了其他机器可以继续运行。对于大规模的应用来说，使用分布式似乎是唯一的选择，因为单机通常很难抗住那么大的请求。