服务注册/发现与二手房中介
分布式系统的服务注册与发现解决的场景没有什么新奇的，我们一直都在用，可以用通俗点的例子解释下。
中介市场
以找工作为例子，在没有互联网的时候，吃瓜群众想找买房子去哪呢？很明显是各种中介。因为人海茫茫，谁知道哪个房东要卖房呢？明显需要一个双方都知道的中间场所。 找房子的过来，卖房子的也过来，能对接上。
服务注册
在跨进程通信时，这叫服务注册，一个进程A想要调用B集群的服务，B集群的机器在哪里，找服务注册中心，注册中心告诉你这个B服务的调用IP是啥。在麻瓜的世界，这个叫中介。这就像一个人，要买西湖区绿城诚园（服务）的房子，而那个中介提供了所有有这个房源的房东（IP地址）。
服务路由与负载均衡
有了房子还不够，合格的中介应该能帮买家筛选一下这个小区的房源，哪些比较合适，残次品就算了。 所以服务中间件又有一定的负载均衡能力和路由能力，比如我要找同一个机房的服务，不要跨机房调用，给我这个机房内这个服务注册的的IP地址。
健康检查
中介通常还有附加的功能，例如维护招聘信息的时效性，当中介知道招聘信息已经无效了，会把这个信息去掉，这个过程在服务的世界里叫健康检查。 招聘信息的去掉也分两种方式：1.用人方主动告知中介；2.求职方找中介后联系用人单位发现信息过时了，告知中介。
第一种方式，叫服务优雅下线，一个应用知道自己要shutdown了，主动通知注册中心，我要下线了，把我的IP从服务列表里摘掉吧。
第二种方式，调用方在调用一个无效服务后一直超时，此时服务框架有义务将这个IP地址的服务暂时屏蔽掉，将调用请求路由到集群的其他机器。
分布式
当一个中介在当地打出知名度后，可能上门来的需求越来越来多，一个分店满足不了了，很明显要开始扩张了。由于投资人给我们投了钱，现在荷包比较充裕，让我们一口气扩到三家店吧。
店多了，但我们的房源名单是共享的，所有分店都有一份，很明显我们要保持各家分店的名单是最新的，当一个店里有了新的房源，不但要更新自家店铺的数据库，还要更新另外三家的。这就是注册在多个数据中心或机房的服务遇到的问题，要保持一致性。
面对这个局面，我们先要分析下我们对各个门店房源名单的不一致性能容忍到什么程度。 在一家店A更新的了自己的房源为已售后， 另一家店B更新慢了，此时有客户上门来看这个房源，在上门看房后被告知房源已售后能否简单的对客户说句sorry， 而不被扔西红柿呢？
最终一致性
如果能接受这个延迟（销售经理脸皮厚），那么恭喜了，我们可以使用最终一致性模型来更新这条数据，即一家店更新后，其他店可能不能马上保证能得到这条数据，但一定有保证经过一段时间后肯定能得到这条数据，代价是销售经理被骂和损失门店信誉。
强一致性
如果销售经理实在接受不了天天被骂，强烈要求别的店更新了房源数据一定要告诉他，那么我们就必须使用强一致性模型了。 在这个模型下，每家门店的数据更新，要么不更新，要么全部更新。怎么做呢？ 我们需要一个协调点， 在三个门店某家有更新需求时告诉这个协调代理，这个协调代理告知所有参与者需要进行提交，各门店严阵以待，开始准备提交并告知协调代理已经准备好了；协调代理在接收到所有三家店的ready信号后，告知三家代理可以更新了，三家代理的秘书把名单更新好后告知协调代理已经完成了，这时所有的数据更新操作结束了。反之，如果某家门店的秘书在更新名单时发现钢笔没水了，这次操作失败了，那么另两家这次操作也要取消掉。
以上是将一份数据分布化后会遇到的一系列挑战。
Google IO 2009年有一则关于此方面的分享<数据中心间的事务>
http://snarfed.org/transactions_across_datacenters_io.html
https://www.youtube.com/watch?v=srOgpXECblk
文章来自微信平台「麦芽面包」
微信公众号「darkjune_think」
转载请注明。
如果觉得文章有趣，可以长按图片识别二维码关注我。
