nacos進階一 - 註冊中心的演變歷程及原理

咱們原來使用單題架構的時候, 沒有註冊中心, 註冊中心是如何悄悄的就出如今了咱們的平常生活中的呢?

其實, 他確定是有本身的一個演變過程的, 必定是由於須要, 因此纔出現.

下面咱們就來分析註冊中心是如何演變而來的. 

1. 最初的單體應用時代, 若是我一個服務是產品服務,一個試訂單服務. 產品服務想要去訪問訂單服務, 咱們都是怎麼作的呢?

 

 也就是說: 商品服務調用訂單服務, 經過的是http遠程調用的方式實現的, 這樣的問題是什麼呢?

• 若是訂單服務宕機了, 商品服務還能調通麼?
• 若是訂單服務的ip地址更改了, 商品服務的遠程調用地址是否是也要一塊兒發生變化?
• 若是訂單服務一臺服務器不夠用了,  須要增長一臺服務器, 商品服務就要本身維護一個訂單服務的ip列表. 並按照必定規則訪問

這就是單體服務的問題, 由於ip是寫死在商品服務裏面的, 因此, 一旦發生變化, 不能自動感知, 必須手動修改. 

2. 訂單服務流量增多, 變成了多個訂單服務

 

 這個時候, 咱們怎麼作的呢? 咱們要知足實際業務的需求, 訂單量太大了, 單臺服務器常常支撐不了了, 因而就想到, 部署多臺服務來分擔壓力.

就出現了上面的模型, 但是, 這個模型存在什麼樣的問題呢?

• 程序員本身維護的ip列表, 若是訂單服務某一臺掛了怎麼辦, 那就請求不通了
• 若是訂單服服務依然不能知足需求, 還要繼續擴容, 程序員又要從新維護一份訂單服務的ip列表. 

手動維護ip列表確定很差, 一方面一旦有任何變更, 就須要進行維護; 另外一方面, 從效率上來說, 也不高. 還容易出錯. 因而慢慢有就有了nginx

3. 使用nginx來維護訂單服務的ip列表

 

 商品服務的全部請求過來了, 不要直接去請求訂單服務. 經過nginx去請求訂單服務. 在nginx中維護了訂單服務的ip列表. 而且能夠指定負載均衡策略.

嗯, 這個選擇好像還不錯, 不用程序員常常改商品服務代碼了, 也不用程序員本身寫如何分配請求的流量了. 那麼他就知足咱們全部的需求麼?固然也不是

• 雖然程序員不用在代碼中維護ip列表了, 可是在nginx中依然要維護. 若是訂單服務有不少不少, 怎麼辦? 咱們知道在nginx上是經過upstream來維護ip的, 若是有成百上千的服務, 那麼咱們要維護成百上千個ip麼?
• 若是訂單服務擴縮容了, 是否是同樣要修改nginx的配置文件呢?

因而咱們就想,有沒有一種辦法, 可以讓微服務自動的就被註冊上呢?這個需求迫在眉睫

4. 因而, 就有了註冊中心的概念. 最初, 咱們的想法也很簡單

 

首先有一個數據庫表來維護全部的服務, 並標記這些服務的啓動狀態

而後, 每當有一個服務啓動, 那麼都調用註冊接口, 其實註冊接口就是一個insert服務器信息到數據庫的過程

第三, 每次商品服務要調用訂單服務了, 先去數據庫裏面查詢可用的訂單服務列表. 而後根據策略選擇服務ip, 

第四, 根據ip發送請求. 

 

這裏面也會有一些問題

• 服務宕機了怎麼辦? 還來不及發出通知
• 每次商品服務調用訂單服務, 都要去數據庫查詢可用的服務列表, 這樣當流量大了, 就會給數據庫形成很大的壓力, 並且, 每次都查數據庫, 效率也不高. 
• 註冊中心宕機 了怎麼辦?

因而, 想到將咱們的註冊中心進行改造. 改造的更加完美一些

5. 改造後的註冊中心

 這個就是在上面的基礎上改造過來的

1. 增長了一個last_heartTime, 記錄心跳時間.

2. 當商品服務和訂單服務啓動的時候, 須要調用註冊接口, 告訴註冊中心, 我上線了, 實質上這是一個insert記錄的過程

3. 商品服務和訂單服務有一個定時任務timetask1, 按期發送心跳. 而後註冊中心就會修改這個心跳時間. 一般是30秒發送一次. 

4. 商品服務有一個定時任務timerTask2, 按期去任務中心拉取服務列表, 並將其保存在客戶端緩存中, 當請求過來的時候, 經過ribbon拉取客戶端緩存的ip, 按照負載均衡策略, 選擇指定的訂單服務發送遠程調用, 

5. 在註冊中心有一個定時任務timerTask3,  若是註冊中心在規定的時間內, 沒有收到微服務的心跳, 那麼就認爲服務掛了, 將其狀態設置爲down, 下次拉取的時候, 這臺服務器不會被拉取過去. 其實,這是一個狀態修改的過程

6. 當服務中止的時候, 會調用服務註銷接口, 通知註冊中心,服務中止, 註冊中心就是將其從註冊表中刪除. 其實這就是一個delete記錄的過程

 

以上就是註冊中心的由來, 和根本的原理.