我的天，你们公司的“微服务”简直就是反人类…

从上面的参照看，Sentinel 的功能相对要多一些，但是多并不意味着所有，合适的才是最好的，对于你用不到的功能，简单才是美丽。

④统一配置中心

统一配置中心概念的提出也是伴随着微服务架构出现才出现，单体应用的时候所有的配置都可以集成在服务之中，多应用的时候如果每个应用都持有一份配置可能会有相同配置冗余的情况。

如果一共有 2000 台机器，其中一个配置发生更改，是否要登录每一台机器重新更改配置呢。

另外，更多的配置必然会带来管理上的混乱，如果没有集中管理的地方必然会越来越乱。

分布式配置管理的本质基本上就是一种推送-订阅模式的运用。配置的应用方是订阅者，配置管理服务则是推送方。

其中，客户端包括管理人员 Publish 数据到配置管理服务，可以理解为添加/更新数据;配置管理服务 Notify 数据到订阅者，可以理解为推送。

配置管理服务往往会封装一个客户端库，应用方则是基于该库与配置管理服务进行交互。

在实际实现时，客户端库可能是主动拉取(pull)数据，但对于应用方而言，一般是一种事件通知方式。

选型一个合格的配置中心，至少需要满足如下四个核心需求：

非开发环境下应用配置的保密性，避免将关键配置写入源代码。

不同部署环境下应用配置的隔离性，比如非生产环境的配置不能用于生产环境。

同一部署环境下的服务器应用配置的一致性，即所有服务器使用同一份配置。

分布式环境下应用配置的可管理性，即提供远程管理配置的能力。

Diamond：最开始我接触过的配置中心是淘宝的 Diamond，Diamond 中的数据是简单的 Key-Value 结构。应用方订阅数据则是基于 Key 来订阅，未订阅的数据当然不会被推送。

Diamond 是无单点架构，在做更新配置的时候只做三件事：

写数据库

写本地

通知其他机器到数据库拉更新

本地的设计就是为了缓存，减少对数据库的压力。作为一个配置中心，高可用是最主要的需求。

如何保持高可用，Diamond 持有多层的数据存储，数据被存储在：数据库，服务端磁盘，客户端缓存目录，以及可以手工干预的容灾目录。

客户端通过 API 获取配置数据，按照固定的顺序去不同的数据源获取数据：容灾目录，服务端磁盘，客户端缓存。

Diamond 除了在容灾上做了很多方案，在数据读取方面也有很多特点。客户端采用推拉结合的策略在长连接和短连接之间取得一个平衡，让服务端不用太关注连接的管理，又可以获得长连接的及时性。

使用 Diamond 的流程如下：

发布配置 

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!