分布式系統的服務注冊與發現解決的場景沒有什么新奇的，我們一直都在用，可以用通俗點的例子解釋下。
中介市場
以找工作為例子，在沒有互聯網的時候，吃瓜群眾想找買房子去哪呢？很明顯是各種中介。因為人海茫茫，誰知道哪個房東要賣房呢？明顯需要一個雙方都知道的中間場所。 找房子的過來，賣房子的也過來，能對接上。
服務注冊
在跨進程通信時，這叫服務注冊，一個進程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」
轉載請注明。
如果覺得文章有趣，可以長按圖片識別二維碼關注我。
文章列表
留言列表
