我們原來使用單題架構的時候, 沒有注冊中心, 注冊中心是如何悄悄的就出現在了我們的日常生活中的呢?
其實, 他肯定是有自己的一個演變過程的, 一定是因為需要, 所以才出現.
下面我們就來分析注冊中心是如何演變而來的.
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記錄的過程
以上就是注冊中心的由來, 和根本的原理.