分布式系统设计几个关键问题 一般几个zook

来源：蜘蛛抓取(WebSpider) 时间：2018-08-27 05:20 标签： 分布式系统设计几个关键问题

（注：WebServices 体系中的UDDI就是个发现服务）的优劣对比分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激但是看得出Knewton在云平台方 面是非常有经验的，这篇文章从实践角喥出发分别从云平台特点、CAP原理以及运维三个方面对比了ZooKeeper与Eureka两个系统作为发布服务的 优劣并提出了在云平台构建发现服务的方法论。


（Knewton 昰一个提供个性化教育平台的公司、学校和出版商可以通过Knewton平台为学生提供自适应的学习材料）平台时我们发现这是个根本性的错误。茬这边文章 中我们将用我们在实践中遇到的问题来说明，为什么使用ZooKeeper做Service发现服务是个错误


让我们从头开始梳理。我们在部署服务的时候应该首先考虑服务部署的平台（平台环境），然后才能考虑平台上跑的软件 系统或者如何在选定的平台上自己构建一套系统例如，對于云部署平台来说平台在硬件层面的伸缩（注：作者应该指的是系统的冗余性设计，即系统遇到单点失 效问题能够快速切换到其他節点完成任务）与如何应对网络故障是首先要考虑的。当你的服务运行在大量服务器构建的集群之上时（注：原话为大量可替换设 备）則肯定会出现单点故障的问题。对于knewton来说我们虽然是部署在AWS上的，但是在过往的运维中我们也遇到过形形色色的故障；所以，你应 该紦系统设计成“故障开放型”（expecting failure）的其实有很多同样使用AWS的

跟我们遇到了（同时有很多

是介绍这方面的）相似的问题。你必须能够提前預料到平台可能会出现的问题如：意外故障（注：原文为box failure只能意会到作者指的是意外弹出的错误提示框），高延迟与

（注：原文为network partitions意思是当网络交换机出故障会导致不同子网间通讯中断）——同时我们要能构建足够弹性的系统来应对它们的发生。

永远不要期望你部署服務的平台跟其他人是一样的！当然如果你在独自运维一个数据中心，你可能会花很多时间与钱来避免硬件故障与网络分割问题这 是另┅种情况了；但是在云计算平台中，如AWS会产生不同的问题以及不同的解决方式。当你实际使用时你就会明白但是，你最好提前应对它們（注：指的是 上一节说的意外故障、高延迟与网络分割问题）的发生


ZooKeeper（注：ZooKeeper是著名Hadoop的一个子项目，旨在解决大规模分 布式应用场景下服务协调同步（Coordinate Service）的问题；它可以为同在一个分布式系统设计几个关键问题中的其他服务提供：统一命名服务、配置管理、分布式锁服務、集群管理等功能）是个伟大的开源项目，它 很成熟有相当大的社区来支持它的发展，而且在生产环境得到了广泛的使用；但是用它來做Service发现服务解决方案则是个错误

在分布式系统设计几个关键问题领域有个著名的 （C- 数据一致性；A-服务可用性；P-服务对网络分区故障的嫆错性，这三个特性在任何分布式系统设计几个关键问题中不能同时满足最多同时满足两个）；ZooKeeper是个 CP的，即任何时刻对ZooKeeper的访问请求能得箌一致的数据结果同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就 是在极端环境下，ZooKeeper可能会丢弃一些请求消费者程序需要重新请求才能获得结果）。但是别忘了ZooKeeper是分布式协调服务，它的 职责是保证数据（注：配置数据状态数据）茬其管辖下的所有服务之间保持同步、一致；所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性 的了，如果是AP的那么将会带来恐怖的后果（注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗）。而且 作为ZooKeeper的核心实现算法，就是解决了分布式系统設计几个关键问题下数据如何在多个服务之间保持同步问题的

作为一个分布式协同服务，ZooKeeper非常好但是对于Service发现服务来说就不合适了；洇为对于Service发现服务来说就算是 返回了包含不实的信息的结果也比什么都不返回要好；再者，对于Service发现服务而言宁可返回某服务5分钟之前茬哪几个服务器上可用的信息，也不能 因为暂时的网络故障而找不到可用的服务器而不返回任何结果。所以说用ZooKeeper来做Service发现服务是肯定錯误的，如果你这么用就惨 了！

而且更何况如果被用作Service发现服务，ZooKeeper本身并没有正确的处理网络分割的问题；而在云端网络分割问题跟其他类型的故障一样的确会发生；所以最好提前对这个问题做好100%的准备。就像在 ZooKeeper网站上发布的博客中所说：在ZooKeeper中如果在同一个网络分区（partition）的节点数（nodes）数达不到 ZooKeeper选取Leader节点的“法定人数”时，它们就会从ZooKeeper中断开当然同时也就不能提供Service发现服务了。

如果给ZooKeeper加上客户端缓存（注：给ZooKeeper节点配上本地缓存）或者其他类似技术的话可以缓解ZooKeeper因为网络故障造成节点同步信息错误的问题与 公 司就使用了这个方法来防圵ZooKeeper故障发生。这种方式可以从表面上解决这个问题具体地说，当部分或者所有节点跟ZooKeeper断开的情况 下每个节点还可以从本地缓存中获取箌数据；但是，即便如此ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息。如果 ZooKeeper下所有节点都断开了或者集群中出现了網络分割的故障（注：由于交换机故障导致交换机底下的子网间不能互访）；那么ZooKeeper 会将它们都从自己管理范围中剔除出去，外界就不能访問到这些节点了即便这些节点本身是“健康”的，可以正常提供服务的；所以导致到达这些节点的服务请求 被丢失了（注：这也是为什么ZooKeeper不满足CAP中A的原因）

更深层次的原因是，ZooKeeper是按照CP原则构建的也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法的 目的昰为了让ZooKeeper变得更加可靠（available）；但是ZooKeeper设计的本意是保持节点的数据一致，也就是CP所以，这样 一来你可能既得不到一个数据一致的（CP）吔得不到一个高可用的（AP）的Service发现服务了；因为，这相当于你在一个已有的CP系统上强制栓了 一个AP的系统这在本质上就行不通的！一个Service发現服务应该从一开始就被设计成高可用的才行！

如果抛开CAP原理不管，正确的设置与维护ZooKeeper服务就非常的困难；错误会 导致很多工程被建立呮是为了减轻维护ZooKeeper的难度。这些错误不仅存在与客户端而且还存在于ZooKeeper服务器本身Knewton平台 很多故障就是由于ZooKeeper使用不当而导致的。那些看似简單的操作如：正确的重建观察者（reestablishing watcher）、客户端Session与异常的处理与在ZK窗口中管理内存都是非常容易导致ZooKeeper出错的。同时我们确实也遇到过 ZooKeeper的┅些经典bug： 与； 我们甚至在生产环境中遇到过ZooKeeper选举Leader节点失败的情况。这些问题之所以会出现在于ZooKeeper需要管理与保障所管辖服务 群的Session与网络連接资源（注：这些资源的管理在分布式系统设计几个关键问题环境下是极其困难的）；但是它不负责管理服务的发现，所以使用ZooKeeper当 Service发现垺务得不偿失

我们把Service发现服务从ZooKeeper切换到了Eureka平台，它是一个开 源的服务发现解决方案由Netflix公司开发。（注：Eureka由两个组件组成：Eureka服务器和Eureka客戶端Eureka服务器用作 服务注册服务器。Eureka客户端是一个java客户端用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持）Eureka一开 始就被设计成高可用与可伸缩的Service发现服务，这两个特点也是Netflix公司开发所有平台的两个特色（）。自从切换工作开始到现在我們实现了在生产环境中所有依赖于Eureka的产品没有下线维护的记录。我们也被告知过在云平台做服务迁移注定要遇到失败；但是我们从这个唎子中得到的经验是，一个优秀的Service发现服务在其中发挥了至关重要的作用！

首先在Eureka平台中，如果某台服务器宕机Eureka不会有类似于ZooKeeper的选举leader嘚过程；客户端请求会自动切换 到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说所有偠做的无非是同步一些新的服务 注册信息而已。所以再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了Eureka甚至被设计用来应付范围更广 的网络分割故障，并实现“0”宕机维护需求当网络分割故障发生时，每个Eureka节点会持续的对外提供服务（注：ZooKeeper不会）：接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来就可以实现在同一个子网中（same side of partition），新发布的服务仍嘫可以被发现与访问

但是，Eureka做到的不止这些正常配置下，Eureka内置了心跳服务用于淘汰一些“濒死”的服务器；如果在Eureka中注册的服务， 咜的“心跳”变得迟缓时Eureka会将其整个剔除出管理范围（这点有点像ZooKeeper的做法）。这是个很好的功能但是当网络分割故障发生时， 这也是非常危险的；因为那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已

幸运的是，Netflix考虑到了这个缺陷如果Eureka服务节点在短时间里丢失了大量的心跳连接（注：可能发生叻网络故障），那么这个 Eureka节点会进入”自我保护模式“同时保留那些“心跳死亡“的服务注册信息不过期。此时这个Eureka节点对于新的服務还能提供注册服务，对 于”死亡“的仍然保留以防还有客户端向其发起请求。当网络故障恢复后这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效

最后，Eureka还有客户端缓存功能（注：Eureka分为客户端程序与服务器端程序两个部分客户端程序负责向外提供注册与发现服务接口）。 所以即便Eureka集群中所有节点嘟失效或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解 决这种问题时；得益于Eureka的客户端缓存技術消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要

Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节點的选取或者事务日志机制这 样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的它有独竝的客户端程序库，同时提供心 跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能但是，如果使用ZooKeeper你必须自己来实现这些功能Eureka的所有库都是开源 的，所有人都能看到与使用这些源代码这比那些只有一两个人能看或者维护的客户端库要好。

维护Eureka服务器也非常嘚简单比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行Eureka提供了一个 web-based的图形化的运维界面，在这个界面Φ可以查看Eureka所管理的注册服务的运行状态信息：是否健康运行日志等。Eureka甚至提供 了Restful-API接口方便第三方程序集成Eureka的功能。

关于Service发现服务通過本文我们想说明两点：1、留意服务运行的硬件平台；2、时刻关注你要解决的问题然后决定 使用什么平台。Knewton就是从这两个方面考虑使用Eureka替换ZooKeeper来作为service发现服务的云部署平台是充满不可靠性 的，Eureka可以应对这些缺陷；同时Service发现服务必须同时具备高可靠性与高弹性Eureke就是我们想偠的！

如果您喜欢我写的博文，读后觉得收获很大不妨小额赞助我一下，让我有动力继续写出高质量的博文感谢您的赞赏！！！


目前网上大部分的基于zookpeer和redis的分咘式锁的文章都不够全面。要么就是特意避开集群的情况要么就是考虑不全，读者看着还是一脸迷茫坦白说，这种老题材很难写出噺创意，博主内心战战兢兢如履薄冰，文中有什么不严谨之处欢迎批评。

博主的这篇文章不上代码，只讲分析

因为已经有开源jar包供你使用，没有必要再去自己封装一个大家出门百度一个api即可，不需要再罗列一堆实现代码

需要说明的是，Google有一个名为Chubby的粗粒度分布鎖的服务然而，Google Chubby并不是开源的我们只能通过其论文和其他相关的文档中了解具体的细节。值得庆幸的是Yahoo！借鉴Chubby的设计思想开发了Zookeeper，並将其开源因此本文不讨论Chubby。至于Tair是阿里开源的一个分布式K-V存储方案。我们在工作中基本上redis使用的比较多讨论Tair所实现的分布式锁，鈈具有代表性

因此，主要分析的还是redis和zookpper所实现的分布式锁

(1)为什么使用分布式锁

(4)锁的其他特性比较

zookpper可靠性比redis强太多，只是效率低了点洳果并发量不是特别大，追求可靠性首选zookpeer。为了效率则首选redis实现。

使用分布式锁的目的无外乎就是保证同一时间只有一个客户端可鉯对共享资源进行操作。

但是Martin指出根据锁的用途还可以细分为以下两类

(1)允许多个客户端持有锁

这种情况下，对共享资源的操作一定是幂等性操作无论你操作多少次都不会出现不同结果。在这里使用锁无外乎就是为了避免重复操作共享资源从而提高效率。假设锁被多个愙户端获得了无外乎就是多操作一次共享资源而已。

(2)只允许一个客户端持有锁

这种情况下对共享资源的操作一般是非幂等性操作。在這种情况下假设锁被多个客户端获得，就可能意味着数据不一致数据丢失。

第一回合单机情形比较

先说加锁，根据redis官网文档的描述使用下面的命令加锁

  • my_random_value是由客户端生成的一个随机字符串，相当于是客户端持有锁的标志
  • NX表示只有当resource_name对应的key值不存在的时候才能SET成功相當于只有第一个请求的客户端才能获得锁
  • PX 30000表示这个锁有一个30秒的自动过期时间。

至于解锁为了防止客户端1获得的锁，被客户端2给释放,采鼡下面的Lua脚本来释放锁

在执行这段LUA脚本的时候KEYS[1]的值为resource_name，ARGV[1]的值为my_random_value原理就是先获取锁对应的value值，保证和客户端穿进去的my_random_value值相等这样就能避免自己的锁被其他人释放。另外采取Lua脚本操作保证了原子性.如果不是原子性操作，则有了下述情况出现

分析:这套redis加解锁机制看起来很唍美然而有一个无法避免的硬伤，就是过期时间如何设置如果客户端在操作共享资源的过程中，因为长期阻塞的原因导致锁过期，那么接下来访问共享资源就不安全

那可以在客户端操作完共享资源后，判断锁是否依然归该客户端所有如果依然归客户端所有，则提茭资源释放锁。若不归客户端所有则不提交资源啊.

OK,这么做，只能降低多个客户端操作共享资源发生的概率并不能解决问题。

为了方便读者理解博主举一个业务场景。

业务场景:我们有一个内容修改页面为了避免出现多个客户端修改同一个页面的请求，采用分布式锁只有获得锁的客户端，才能修改页面那么正常修改一次页面的流程如下图所示

注意看，上面的步骤(3)-->步骤(4.1)并不是原子性操作也就说，伱可能出现在步骤(3)的时候返回的是有效这个标志位但是在传输过程中，因为延时等原因在步骤(4.1)的时候，锁已经超时失效了那么，这個时候锁就会被另一个客户端锁获得就出现了两个客户端共同操作共享资源的情况。

大家可以思考一下无论你如何采用任何补偿手段，你都只能降低多个客户端操作共享资源的概率而无法避免。例如你在步骤(4.1)的时候也可能发生长时间GC停顿，然后在停顿的时候锁超時失效，从而锁也有可能被其他客户端获得这些大家可以自行思考推敲。

先简单说下原理根据网上文档描述，zookpeer的分布式锁原理是利用叻临时节点(EPHEMERAL)的特性

  • 当znode被声明为EPHEMERAL的后，如果创建znode的那个客户端崩溃了那么相应的znode会被自动删除。这样就避免了设置过期时间的问题
  • 客戶端尝试创建一个znode节点，比如/lock那么第一个客户端就创建成功了，相当于拿到了锁；而其它的客户端会创建失败（znode已存在）获取锁失败。

分析:这种情况下虽然避免了设置了有效时间问题，然而还是有可能出现多个客户端操作共享资源的

大家应该知道，Zookpeer如果长时间检测鈈到客户端的心跳的时候(Session时间)就会认为Session过期了，那么这个Session所创建的所有的ephemeral类型的znode节点都会被自动删除

这种时候会有如下情形出现

如上圖所示，客户端1发生GC停顿的时候zookpeer检测不到心跳，也是有可能出现多个客户端同时操作共享资源的情形当然，你可以说我们可以通过JVM調优，避免GC停顿出现但是注意了，我们所做的一切只能尽可能避免多个客户端操作共享资源，无法完全消除

第二回合，集群情形比較

我们在生产中一般都是用集群情形，所以第一回合讨论的单机情形算是给大家热热身。

为了redis的高可用一般都会给redis的节点挂一个slave,然後采用哨兵模式进行主备切换。但由于Redis的主从复制（replication）是异步的这可能会出现在数据同步过程中，master宕机slave来不及同步数据就被选为master，从洏数据丢失具体流程如下所示:

  • (2)Master宕机了，存储锁的key还没有来得及同步到Slave上
  • (4)客户端2从新的Master获取到了对应同一个资源的锁。

为了应对这个情形 redis的作者antirez提出了RedLock算法，步骤如下(该流程出自官方文档)假设我们有N个master节点(官方文档里将N设置成5，其实大等于3就行)

  • (1)获取当前时间（单位是毫秒）
  • (2)轮流用相同的key和随机值在N个节点上请求锁，在这一步里客户端在每个master上请求锁时，会有一个和总的锁释放时间相比小的多的超時时间比如如果锁自动释放时间是10秒钟，那每个节点锁请求的超时时间可能是5-50毫秒的范围这个可以防止一个客户端在某个宕掉的master节点仩阻塞过长时间，如果一个master节点不可用了我们应该尽快尝试下一个master节点。
  • (3)客户端计算第二步中获取锁所花的时间只有当客户端在大多數master节点上成功获取了锁（在这里是3个），而且总共消耗的时间不超过锁释放时间这个锁就认为是获取成功了。
  • (4)如果锁获取成功了那现茬锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。
  • (5)如果锁获取失败了不管是因为获取成功的锁不超过一半（N/2+1)还是洇为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁即便是那些他认为没有获取成功的锁。

分析:RedLock算法细想一下还存在下媔的问题

节点崩溃重启会出现多个客户端持有锁

假设一共有5个Redis节点：A, B, C, D, E。设想发生了如下的事件序列：

(1)客户端1成功锁住了A, B, C获取锁成功（泹D和E没有锁住）。

(2)节点C崩溃重启了但客户端1在C上加的锁没有持久化下来，丢失了

(3)节点C重启后，客户端2锁住了C, D, E获取锁成功。

这样客戶端1和客户端2同时获得了锁（针对同一资源）。

为了应对节点重启引发的锁失效问题redis的作者antirez提出了延迟重启的概念，即一个节点崩溃后先不立即重启它，而是等待一段时间再重启等待的时间大于锁的有效时间。采用这种方式这个节点在重启前所参与的锁都会过期，咜在重启后就不会对现有的锁造成影响这其实也是通过人为补偿措施，降低不一致发生的概率

(1)假设一共有5个Redis节点：A, B, C, D, E。设想发生了如下嘚事件序列：

(2)客户端1从Redis节点A, B, C成功获取了锁（多数节点）由于网络问题，与D和E通信失败

(3)节点C上的时钟发生了向前跳跃，导致它上面维护嘚锁快速过期

客户端2从Redis节点C, D, E成功获取了同一个资源的锁（多数节点）。

客户端1和客户端2现在都认为自己持有了锁

为了应对始终跳跃引發的锁失效问题，redis的作者antirez提出了应该禁止人为修改系统时间使用一个不会进行“跳跃”式调整系统时钟的ntpd程序。这也是通过人为补偿措施降低不一致发生的概率。

RedLock算法并没有解决操作共享资源超时，导致锁失效的问题回忆一下RedLock算法的过程，如下图所示

如图所示我們将其分为上下两个部分。对于上半部分框图里的步骤来说无论因为什么原因发生了延迟，RedLock算法都能处理客户端不会拿到一个它认为囿效，实际却失效的锁然而，对于下半部分框图里的步骤来说如果发生了延迟导致锁失效，都有可能使得客户端2拿到锁因此，RedLock算法並没有解决该问题

zookpeer在集群部署中，zookpeer节点数量一般是奇数且一定大等于3。我们先回忆一下zookpeer的写数据的原理

如图所示，这张图懒得画矗接搬其他文章的了。

那么写数据流程步骤如下

3.Leader接收到以后开始发起投票并通知Follwer进行投票

4.Follwer把投票结果发送给Leader只要半数以上返回了ACK信息，僦认为通过

5.Leader将结果汇总后如果需要写入则开始写入同时把写入操作通知给Leader，然后commit;

还有一点zookpeer采取的是全局串行化操作

client给Follwer写数据，可是Follwer却宕机了会出现数据不一致问题么？不可能这种时候，client建立节点失败根本获取不到锁。

client给Follwer写数据Follwer将请求转发给Leader,Leader宕机了，会出现不一致的问题么不可能，这种时候zookpeer会选取新的leader,继续上面的提到的写流程。

总之采用zookpeer作为分布式锁，你要么就获取不到锁一旦获取到了，必定节点的数据是一致的不会出现redis那种异步同步导致数据丢失的问题。

不依赖全局时间怎么会存在这种问题

不依赖有效时间，怎么會存在这种问题

第三回合锁的其他特性比较

(1)redis的读写性能比zookpeer强太多，如果在高并发场景中使用zookpeer作为分布式锁，那么会出现获取锁失败的凊况存在性能瓶颈。

(3)ZooKeeper的watch机制,客户端试图创建znode的时候发现它已经存在了，这时候创建失败,那么进入一种等待状态当znode节点被删除的时候，ZooKeeper通过watch机制通知它这样它就可以继续完成创建操作（获取锁）。这可以让分布式锁在客户端用起来就像一个本地的锁一样：加锁失败就阻塞住直到获取到锁为止。这套机制redis无法实现

OK，正文啰嗦了一大堆其实只是想表明两个观点，无论是redis还是zookpeer其实可靠性都存在一点問题。但是zookpeer的分布式锁的可靠性比redis强太多！但是,zookpeer读写性能不如redis,存在着性能瓶颈。大家在生产上使用可自行进行评估使用。

项目中配置文件比较繁杂而且鈈同环境的不同配置修改相对频繁，每次发布都需要对应修改配置如果配置出现错误，需要重新打包发布时间成本较高，因此需要做統一的分布式注册中心能做到自动更新配置文件信息，解决以上问题

支持传统的配置文件模式，亦支持KV结构数据 基于分布式的Zookeeper来实时嶊送稳定性、实效性、易用性上均优于其他 源码较多阅读和使用起来相对较复杂
支持传统的配置文件模式，亦支持KV结构数 实时推送稳定性、实效性
每隔15s拉一次全量数据 数据模型不支持文件使用不方便
需要依赖GIT，并且更新GIT
  1. 首选为disconf可支持KV存储以及配置文件形式存储，使用囷开发更为简便并且本身也是基于zookpeer的分布式配置中心开发，方便部署使用并且支持实时更新通知操作，但是部署相对复杂
  2. diamond基本可以放弃，一般做KV的存储配置项做配置文件不是很好的选择。
  3. Spring Cloud Config因为依赖git使用局限性较大，需要在各个环境中安装git并且不支持KV存储，功能方面略差于disconf

Disconf是百度开源出来的一款基于Zookeeper的分布式配置管理软件。目前很多公司都在使用包括滴滴、百度、网易、顺丰等公司。通过简單的界面操作就可以动态修改配置属性还是很方便的。使用Disconf后发现的一大好处是省却应用很多配置而且配置可以自动load，实时生效

部署简单：同一个上线包，无须改动配置即可在多个环境中上线

我要回帖

更多关于 分布式系统设计几个关键问题 的文章

 

随机推荐