分布式服务动态上下线感知
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?分布式服務動態上下線感知
?
?
? ? ? 首先，我們要從解決問題的角度得知分布式服務的由來，從單機服務到分布式服務經歷了哪些過程
? ? ? 起初，服務是比較單一的，在一個工程包之中會包含所有的模塊，但隨著互聯網的快速發展，客戶流量的增多，點擊量數據量的增多，導致對架構方面的沖擊較大，想要在用戶量和數據量較大的情況下做到即時相應的話，就需要去提升后端架構的性能。早期我們會去提升服務器硬件設備，但是還是無法達到預期的效果，只能通過水平擴展，將應用進行拆分，每一個應用都可以獨立存儲、獨立計算。每一個服務都會比較小、比較細、更好的去實現功能，微服務也就應運而生。如下圖所示：
?
? ? ? ? ? ? ? ? ?
?
當服務較多時，服務與服務直接的調用會變得凌亂，過于復雜化，為了解決該問題，出現了SOA這一概念
?
關于soa，這里引用其他博客中的一個例子，講的很好，原文鏈接：
https://www.cnblogs.com/renzhitian/p/6853289.html
深入淺出SOA
?SOA是什么？SOA全英文是Service-Oriented Architecture，中文意思是中文面向服務編程，是一種思想，一種方法論，一種分布式的服務架構（具體可以百度）。
? ? ?用途：SOA解決多服務凌亂問題，SOA架構解決數據服務的復雜程度，同時SOA又有一個名字，叫做服務治理。
? ? ?通過一個系統我們看一下架構的演變過程（由統一到分布式）：
? ?
? ? ? ? 當我們的項目比較小時，我們只有一個系統，并且把他們寫到一起，放在一個服務器上，但是隨著平臺越來越大，數據量越來越大，我們不得不通過分庫，把多個模塊的數據庫分別放在對應得服務器上，每個模塊調用自己的子系統即可。
? ? ?
? ? ?隨著我們系統的進一步復雜度的提升，我們不得不進一步對系統的性能進行提升，我們將多個模塊分成多個子系統，多個子系統直接互相調用（因為SOA一般用于大型項目，比較復雜，所以一般總系統不會再集成，會拆分多個，分別做成服務，相互調用）。當我們的電商UI進行一個下訂單的任務時，多個服務直接互相調用，系統通過數據總線，分別調用對于的子系統即可。
? ? ?企業數據總線：企業數據總線不是對多個子模塊的集成，他在這里充當數據通道的作用，數據總線不關心業務，數據總線根據給的地址和協議去調服務，上端不關心服務在哪里是什么，只找數據總線。
? ? ?上面幾個圖應該算是比較清楚了，隨著業務的深入，我們不得不對系統進行調整，分別是對數據和業務的拆分，最后每個子系統對面提供服務。
? ? ?還要提的一點就是下面那個圖，下面的IP庫以及幾個子系統是公共服務，分別向上提供功能，也是SOA方法論的一部分。
二、SOA主要的使用場景，如下圖：
? ?
通過上面的圖我們可以看出，多個子系統直接相互交互，相互調用非常凌亂，這樣我們就很不爽，所以我們就用到了我們的SOA架構，SOA又叫服務治理，SOA就是幫助我們把服務之間調用的亂七八糟的關系給治理起來，然后提供一個統一的標準，把我們的服務治理成下圖所示，以前我們的服務是互相交互，現在是只對數據總線進行交互，這樣系統就變得統一起來。
統一標準：各系統的協議、地址、交互方式。
新的交互方式：各個系統分別根據統一標準向數據總線進行注冊，各子系統調用其他子系統時，我們并不關心如果找到其他子系統，我們只招數據總線，數據總線再根據統一標準找其他子系統，所以數據總線在這里充當一個只路人的作用。
SOA的好處：
? 1、降低用戶成本，用戶不需要關心各服務之間是什么語言的、不需要知道如果調用他們，只要通過統一標準找數據總線就可以了。
?2、程序之間關系服務簡單
?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隊列管理
兩種類型的隊列：
1、同步隊列，當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。?
2、隊列按照 FIFO 方式進行入隊和出隊操作。?
第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。?
第二類，和分布式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。
（6）.分布式與數據復制?
Zookeeper作為一個集群提供一致的數據服務，自然，它要在所有機器間做數據復制。數據復制的好處：?
1、容錯：一個節點出錯，不致于讓整個系統停止工作，別的節點可以接管它的工作；?
2、提高系統的擴展能力 ：把負載分布到多個節點上，或者增加節點來提高系統的負載能力；?
3、提高性能：讓客戶端本地訪問就近的節點，提高用戶訪問速度。?
從客戶端讀寫訪問的透明度來看，數據復制集群系統分下面兩種：?
1、寫主(WriteMaster) ：對數據的修改提交給指定的節點。讀無此限制，可以讀取任何一個節點。這種情況下客戶端需要對讀與寫進行區別，俗稱讀寫分離；?
2、寫任意(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位用于遞增計數。
?
?
?
?
轉載于:https://www.cnblogs.com/GodHeng/p/8797100.html
總結
以上是生活随笔為你收集整理的分布式服务动态上下线感知的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： flask 操作mysql的两种方式-s
- 下一篇： html4