分佈式服務動態上下線感知

時間 2019-11-19

原文原文鏈接

分佈式服務動態上下線感知html

首先，咱們要從解決問題的角度得知分佈式服務的由來，從單機服務到分佈式服務經歷了哪些過程node

起初，服務是比較單一的，在一個工程包之中會包含全部的模塊，但隨着互聯網的快速發展，客戶流量的增多，點擊量數據量的增多，致使對架構方面的衝擊較大，想要在用戶量和數據量較大的狀況下作到即時相應的話，就須要去提高後端架構的性能。早期咱們會去提高服務器硬件設備，可是仍是沒法達到預期的效果，只能經過水平擴展，將應用進行拆分，每個應用均可以獨立存儲、獨立計算。每個服務都會比較小、比較細、更好的去實現功能，微服務也就應運而生。以下圖所示：ajax

當服務較多時，服務與服務直接的調用會變得凌亂，過於複雜化，爲了解決該問題，出現了SOA這一律念redis

關於soa，這裏引用其餘博客中的一個例子，講的很好，原文連接：數據庫

http://www.javashuo.com/article/p-acmynuog-db.html編程

深刻淺出SOA

SOA是什麼？SOA全英文是Service-Oriented Architecture，中文意思是中文面向服務編程，是一種思想，一種方法論，一種分佈式的服務架構（具體能夠百度）。後端

用途：SOA解決多服務凌亂問題，SOA架構解決數據服務的複雜程度，同時SOA又有一個名字，叫作服務治理。服務器

經過一個系統咱們看一下架構的演變過程（由統一到分佈式）：網絡

當咱們的項目比較小時，咱們只有一個系統，而且把他們寫到一塊兒，放在一個服務器上，可是隨着平臺愈來愈大，數據量愈來愈大，咱們不得不經過分庫，把多個模塊的數據庫分別放在對應得服務器上，每一個模塊調用本身的子系統便可。架構

隨着咱們系統的進一步複雜度的提高，咱們不得不進一步對系統的性能進行提高，咱們將多個模塊分紅多個子系統，多個子系統直接互相調用（由於SOA通常用於大型項目，比較複雜，因此通常總系統不會再集成，會拆分多個，分別作成服務，相互調用）。當咱們的電商UI進行一個下訂單的任務時，多個服務直接互相調用，系統經過數據總線，分別調用對於的子系統便可。

企業數據總線：企業數據總線不是對多個子模塊的集成，他在這裏充當數據通道的做用，數據總線不關心業務，數據總線根據給的地址和協議去調服務，上端不關心服務在哪裏是什麼，只找數據總線。

上面幾個圖應該算是比較清楚了，隨着業務的深刻，咱們不得不對系統進行調整，分別是對數據和業務的拆分，最後每一個子系統對面提供服務。

還要提的一點就是下面那個圖，下面的IP庫以及幾個子系統是公共服務，分別向上提供功能，也是SOA方法論的一部分。

2、SOA主要的使用場景，以下圖：

經過上面的圖咱們能夠看出，多個子系統直接相互交互，相互調用很是凌亂，這樣咱們就很不爽，因此咱們就用到了咱們的SOA架構，SOA又叫服務治理，SOA就是幫助咱們把服務之間調用的亂七八糟的關係給治理起來，而後提供一個統一的標準，把咱們的服務治理成下圖所示，之前咱們的服務是互相交互，如今是隻對數據總線進行交互，這樣系統就變得統一塊兒來。

統一標準：各系統的協議、地址、交互方式。

新的交互方式：各個系統分別根據統一標準向數據總線進行註冊，各子系統調用其餘子系統時，咱們並不關心若是找到其餘子系統，咱們只招數據總線，數據總線再根據統一標準找其餘子系統，因此數據總線在這裏充當一個只路人的做用。

SOA的好處：

一、下降用戶成本，用戶不須要關心各服務之間是什麼語言的、不須要知道若是調用他們，只要經過統一標準找數據總線就能夠了。

二、程序之間關係服務簡單

三、識別哪些程序有問題（掛掉）

缺點：提示了系統的複雜程度，性能有相應影響。

3、數據總線是什麼？

其實我在上面寫了，數據總線是起到調度服務的做用，數據總線不是集成服務，數據總線更新一個調度框架，每一個服務須要根據約定向數據總線註冊服務，那麼如何註冊那？其實數據總線就像一個字典結構，

數據總線裏面一個key對於一個value，key指的是服務名，value則是服務的調度方式，還有一點須要說明的是，數據總線只是指路人，服務是不通過數據總線的，如上圖的黃色線的路徑。

數據總線經過域名解析實現:一個域名綁定多臺服務器，ajax也能夠，dns也能夠，解析域名嘛。

其實數據總線還有一些高級應用，好比心跳檢測，實現負載均衡等等，就不細說了，目前應用數據總線的有阿里的dubbo,還有zookeeper。

瞭解完soa以後，仍是回到服務之間的調用問題，每個服務跨進程調用其餘服務會用到一種技術----------------------

　　RPC

　 RPC，全稱爲Remote Procedure Call，即遠程過程調用，它是一個計算機通訊協議。它容許像調用本地服務同樣調用遠程服務。它能夠有不一樣的實現方式。如RMI(遠程方法調用)、Hessian、Http invoker等。另外，RPC是與語言無關的。

如上圖所示，假設Computer1在調用sayHi()方法，對於Computer1而言調用sayHi()方法就像調用本地方法同樣，調用 –>返回。但從後續調用能夠看出Computer1調用的是Computer2中的sayHi()方法，RPC屏蔽了底層的實現細節，讓調用者無需關注網絡通訊，數據傳輸等細節。rpc的實現方式和原理先不談，總之服務之間是經過rpc（遠程過程調用）來相互調用的。

如今多個服務之間進行調用，每個服務去調用或者獲取另外一個服務的時候會有不少的地址信息，若是某一服務作了集羣，會有更多的地址信息。還有，若是，一個服務發送了地址信息，如ip：port請求，可是另外一服務down機了怎麼辦，該怎麼感知服務節點狀態的變化呢？總結一下問題所在是：

1.消費端如何對多個地址進行負載

服務之間互相發送請求時的地址能夠註冊在統一的一個地方，每一個服務只須要知道這個服務中心的地址ip就能夠拿到全部其餘服務的地址簿。這個地址維護服務中心很常見，如zookeeper，eureka，etcd、redis等。以下圖所示

2.如何動態感知服務節點的變化

在這裏，主要介紹一下ZooKeeper的實現原理

1.簡介

ZooKeeper 是一個開源的分佈式協調服務，由雅虎建立，是 Google Chubby 的開源實現。分佈式應用程序能夠基於 ZooKeeper 實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master 選舉、分佈式鎖和分佈式隊列等功能。它是集羣的管理者，監視着集羣中各個節點的狀態根據節點提交的反饋進行下一步合理操做。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

2.Zookeeper文件系統

每一個子目錄項如 NameService 都被稱做爲znode，和文件系統同樣，咱們可以自由的增長、刪除znode，在一個znode下增長、刪除子znode，惟一的不一樣在於znode是能夠存儲數據的。

有四種類型的znode：

<1>、PERSISTENT-持久化目錄節點

客戶端與zookeeper斷開鏈接後，該節點依舊存在

<2>、PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點

客戶端與zookeeper斷開鏈接後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號

<3>、EPHEMERAL-臨時目錄節點

客戶端與zookeeper斷開鏈接後，該節點被刪除

<4>、EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點

客戶端與zookeeper斷開鏈接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

3.Zookeeper通知機制

客戶端註冊監聽它關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增長刪除）時，zookeeper會通知客戶端。

4.Zookeeper的做用

（1）.命名服務

在zookeeper的文件系統裏建立一個目錄，即有惟一的path。

其中較爲常見的就是一些分佈式服務框架（如RPC、RMI）中的服務地址列表。經過在ZooKeepr裏建立順序節點，可以很容易建立一個全局惟一的路徑，這個路徑就能夠做爲一個名字。

ZooKeeper 的命名服務即生成全局惟一的ID。

（2）.配置管理

程序老是須要配置的，若是程序或者服務分散部署在多臺機器上時，要逐個改變配置就變得困難。如今把這些配置所有放在zookeeper上去，保存在zookeeper的某個目錄中去，而後全部的目錄文件都對這個目錄文件進行監聽（watch，和監視同樣，哈哈），一旦配置信息發生變化，每一個應用程序都會收到zookeeper的通知，而後從zookeeper獲取新的配置信息到系統中去就好，以下圖所示。

（3）.Zookeeper集羣管理

所謂集羣管理無在意兩點：是否有機器退出和加入、選舉master

就像幫派同樣，管理幫派無非也是兩點，第一點就是幫派人員的退出和加入，還有就是幫派老大的選舉

對於第一點，全部機器約定在父目錄GroupMembers下建立臨時目錄節點，而後監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的鏈接斷開，其所建立的臨時目錄節點被刪除，全部其餘機器都收到通知：某個兄弟目錄被刪除，因而，全部人都知道：它上船了。

新機器加入也是相似，全部機器收到通知：新兄弟目錄加入，highcount又有了，對於第二點，咱們稍微改變一下，全部機器建立臨時順序編號目錄節點，每次選取編號最小的機器做爲master就好。

（4）.Zookeeper分佈式鎖

有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務能夠分爲兩類，一個是保持獨佔，另外一個是控制時序。

對於第一類，咱們將zookeeper上的一個znode看做是一把鎖，經過createznode的方式來實現。全部客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。用完刪除掉本身建立的distribute_lock 節點就釋放出鎖。

對於第二類， /distribute_lock 已經預先存在，全部客戶端在它下面建立臨時順序編號目錄節點，和選master同樣，編號最小的得到鎖，用完刪除，依次方便。

（5）.Zookeeper隊列管理

兩種類型的隊列：

一、同步隊列，當一個隊列的成員都聚齊時，這個隊列纔可用，不然一直等待全部成員到達。

二、隊列按照 FIFO 方式進行入隊和出隊操做。

第一類，在約定目錄下建立臨時目錄節點，監聽節點數目是不是咱們要求的數目。

第二類，和分佈式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。

（6）.分佈式與數據複製

Zookeeper做爲一個集羣提供一致的數據服務，天然，它要在全部機器間作數據複製。數據複製的好處：

一、容錯：一個節點出錯，不致於讓整個系統中止工做，別的節點能夠接管它的工做；

二、提升系統的擴展能力：把負載分佈到多個節點上，或者增長節點來提升系統的負載能力；

三、提升性能：讓客戶端本地訪問就近的節點，提升用戶訪問速度。

從客戶端讀寫訪問的透明度來看，數據複製集羣系統分下面兩種：

一、寫主(WriteMaster) ：對數據的修改提交給指定的節點。讀無此限制，能夠讀取任何一個節點。這種狀況下客戶端須要對讀與寫進行區別，俗稱讀寫分離；

二、寫任意(Write Any)：對數據的修改可提交給任意的節點，跟讀同樣。這種狀況下，客戶端對集羣節點的角色與變化透明。

對zookeeper來講，它採用的方式是寫任意。經過增長機器，它的讀吞吐能力和響應能力擴展性很是好，而寫，隨着機器的增多吞吐能力確定降低（這也是它創建observer的緣由），而響應能力則取決於具體實現方式，是延遲複製保持最終一致性，仍是當即複製快速響應。

（7）.Zookeeper角色描述

（8）.Zookeeper與客戶端

（9）.Zookeeper設計目的

1.最終一致性：client不論鏈接到哪一個Server，展現給它都是同一個視圖，這是zookeeper最重要的性能。

2.可靠性：具備簡單、健壯、良好的性能，若是消息被到一臺服務器接受，那麼它將被全部的服務器接受。

3.實時性：Zookeeper保證客戶端將在一個時間間隔範圍內得到服務器的更新信息，或者服務器失效的信息。但因爲網絡延時等緣由，Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口。

4.等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每一個client都能有效的等待。

5.原子性：更新只能成功或者失敗，沒有中間狀態。

6.順序性：包括全局有序和偏序兩種：全局有序是指若是在一臺服務器上消息a在消息b前發佈，則在全部Server上消息a都將在消息b前被髮布；偏序是指若是一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。

（10）.Zookeeper工做原理Zookeeper 的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫作Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和Server具備相同的系統狀態。爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。全部的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。