服務註冊/發現與二手房中介

分佈式系統的服務註冊與發現解決的場景沒有什麼新奇的，咱們一直都在用，能夠用通俗點的例子解釋下。

中介市場

以找工做爲例子，在沒有互聯網的時候，吃瓜羣衆想找買房子去哪呢？很明顯是各類中介。由於人海茫茫，誰知道哪一個房東要賣房呢？明顯須要一個雙方都知道的中間場所。 找房子的過來，賣房子的也過來，能對接上。

服務註冊

在跨進程通訊時，這叫服務註冊，一個進程A想要調用B集羣的服務，B集羣的機器在哪裏，找服務註冊中心，註冊中心告訴你這個B服務的調用IP是啥。在麻瓜的世界，這個叫中介。這就像一我的，要買西湖區綠城誠園（服務）的房子，而那個中介提供了全部有這個房源的房東（IP地址）。

服務路由與負載均衡

有了房子還不夠，合格的中介應該能幫買家篩選一下這個小區的房源，哪些比較合適，殘次品就算了。 因此服務中間件又有必定的負載均衡能力和路由能力，好比我要找同一個機房的服務，不要跨機房調用，給我這個機房內這個服務註冊的的IP地址。

健康檢查

中介一般還有附加的功能，例如維護招聘信息的時效性，當中介知道招聘信息已經無效了，會把這個信息去掉，這個過程在服務的世界裏叫健康檢查。 招聘信息的去掉也分兩種方式：1.用人方主動告知中介；2.求職方找中介後聯繫用人單位發現信息過期了，告知中介。

第一種方式，叫服務優雅下線，一個應用知道本身要shutdown了，主動通知註冊中心，我要下線了，把個人IP從服務列表裏摘掉吧。

第二種方式，調用方在調用一個無效服務後一直超時，此時服務框架有義務將這個IP地址的服務暫時屏蔽掉，將調用請求路由到集羣的其餘機器。

分佈式

當一箇中介在當地打出知名度後，可能上門來的需求愈來愈來多，一個分店知足不了了，很明顯要開始擴張了。因爲投資人給咱們投了錢，如今荷包比較充裕，讓咱們一口氣擴到三家店吧。

店多了，但咱們的房源名單是共享的，全部分店都有一份，很明顯咱們要保持各家分店的名單是最新的，當一個店裏有了新的房源，不但要更新自家店鋪的數據庫，還要更新另外三家的。這就是註冊在多個數據中心或機房的服務遇到的問題，要保持一致性。

面對這個局面，咱們先要分析下咱們對各個門店房源名單的不一致性能容忍到什麼程度。 在一家店A更新的了本身的房源爲已售後， 另外一家店B更新慢了，此時有客戶上門來看這個房源，在上門看房後被告知房源已售後可否簡單的對客戶說句sorry， 而不被扔西紅柿呢？

最終一致性

若是能接受這個延遲（銷售經理臉皮厚），那麼恭喜了，咱們可使用最終一致性模型來更新這條數據，即一家店更新後，其餘店可能不能立刻保證能獲得這條數據，但必定有保證通過一段時間後確定能獲得這條數據，代價是銷售經理被罵和損失門店信譽。

強一致性

若是銷售經理實在接受不了每天被罵，強烈要求別的店更新了房源數據必定要告訴他，那麼咱們就必須使用強一致性模型了。 在這個模型下，每家門店的數據更新，要麼不更新，要麼所有更新。怎麼作呢？ 咱們須要一個協調點， 在三個門店某家有更新需求時告訴這個協調代理，這個協調代理告知全部參與者須要進行提交，各門店嚴陣以待，開始準備提交併告知協調代理已經準備好了；協調代理在接收到全部三家店的ready信號後，告知三家代理能夠更新了，三家代理的祕書把名單更新好後告知協調代理已經完成了，這時全部的數據更新操做結束了。反之，若是某家門店的祕書在更新名單時發現鋼筆沒水了，此次操做失敗了，那麼另兩家此次操做也要取消掉。

以上是將一份數據分佈化後會遇到的一系列挑戰。

Google IO 2009年有一則關於此方面的分享<數據中心間的事務>

http://snarfed.org/transactio...
https://www.youtube.com/watch...

---

文章來自微信平臺「麥芽麪包」
微信公衆號「darkjune_think」
轉載請註明。
若是以爲文章有趣，能夠長按圖片識別二維碼關注我。