淘宝Diamond架构分析

背景知识

早期的应用都是单体的，配置修改后，只要通过预留的管理界面刷新reload即可。后来，应用开始拆分，从单一系统拆分成多个子系统，每个子系统还会对应多个运行实例，就开始面临一些问题：
1. 配置分散在多个业务子系统里，对同一配置的翻译在多个子系统里经常不一致。比如订单和购物车都有货币类型的配置，如果购物车上了一种新的货币类型而订单却没有相应同步增加配置项就会造成程序错误。
2. 将配置收敛成一个公有服务，可以有效改善，但是又会带来其他问题。在复杂应用里，修改一个配置项，无法确切的知道需要刷新哪些相关子系统。最终只能做全量刷新，甚至是停机发布。这对于一些停机敏感的应用例如电商几乎是无法接受的。
3. 配置收敛后，配置中心成了应用中的单点，配置如果挂了，应用也会跟着产生异常甚至挂掉。

Diamond就是为了解决这些问题，它是个高可用的配置中心。

Diamond的配置类型

配置是Diamond的核心域，也是Diamond致力于去解决的问题。Diamond有两个主要配置类型– single和aggr。二者结构如下：

Aggr和single相比，少md5多datumId。DatumId是aggr的逻辑主键，aggr下dataId和datumId是1对多的关系，也就是说多条aggr会聚合成一条single，diamond通过merge任务对aggr合并最终生成一条single。

Md5是对content md5编码生成的字符串，用于判断缓存数据相比数据库数据是

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！