建站
咨詢
售后
建站咨詢
新聞中心
引入服務注冊與發(fā)現(xiàn)組件的原因
先來看一個問題，假如現(xiàn)在我們要做一個商城項目，作為架構師的你應該怎樣設計系統(tǒng)的架構?你心里肯定在想：這還不容易直接照搬淘寶的架構不就行了。但在現(xiàn)實的創(chuàng)業(yè)環(huán)境中一個項目可能是九死一生，如果一開始投入巨大的人力和財力，一旦項目失敗損失就很大。
我們擁有十余年網(wǎng)頁設計和網(wǎng)站建設經(jīng)驗，從網(wǎng)站策劃到網(wǎng)站制作，我們的網(wǎng)頁設計師為您提供的解決方案。為企業(yè)提供成都網(wǎng)站建設、網(wǎng)站建設、微信開發(fā)、微信小程序定制開發(fā)、移動網(wǎng)站建設、HTML5建站、等業(yè)務。無論您有什么樣的網(wǎng)站設計或者設計方案要求，我們都將富于創(chuàng)造性的提供專業(yè)設計服務并滿足您的需求。
作為一位有經(jīng)驗的架構師需要結(jié)合公司財力、人力投入預算等現(xiàn)狀選擇最適合眼下的架構才是王道。大型網(wǎng)站都是從小型網(wǎng)站發(fā)展而來，架構也是一樣。
任何一個大型網(wǎng)站的架構都不是從一開始就一層不變的，而是隨著用戶量和數(shù)據(jù)量的不斷增加不斷迭代演進的結(jié)果。
在架構不斷迭代演進的過程中我們會遇到很多問題，技術發(fā)展的本質(zhì)就是不斷發(fā)現(xiàn)問題再解決問題，解決問題又發(fā)現(xiàn)問題。
單體架構
在系統(tǒng)建立之初可能不會有特別多的用戶，將所有的業(yè)務打成一個應用包放在tomcat容器中運行，與數(shù)據(jù)庫共用一臺服務器，這種架構一般稱之為單體架構。
在初期這種架構的效率非常高，根據(jù)用戶的反饋可以快速迭代上線。但是隨著用戶量增加，一臺服務的內(nèi)存和CPU吃緊，很容易造成瓶頸，新的問題來了怎么解決呢?
應用與數(shù)據(jù)分離
隨著用戶請求量增加，一臺服務器的內(nèi)存和CPU持續(xù)飆升，用戶請求響應時間變慢。這時候可以考慮將應用與數(shù)據(jù)庫拆開，各自使用一臺服務器，你看問題又解決了吧。
突然有一天掃地阿姨不小心碰了電線，其中一臺服務器掉電了，用戶所有的請求都報錯，隨之而來的是一系列投訴電話。
集群部署
單實例很容易造成單點問題，比如遇到服務器故障或者服務能力瓶頸，那怎么辦?聰明的你肯定想到了，用集群呀。
集群部署是指將應用部署在多個服務器或者虛機上，用戶通過服務均衡隨機訪問其中的一個實例，從而使多個實例的流量均衡，如果一個實例出現(xiàn)故障可以將其下線，其他實例不受影響仍然可以對外提供服務。
隨著用戶數(shù)量快速增加，老板決定增加投入擴大團隊規(guī)模。開發(fā)團隊壯大后效率并沒有得到顯著的提高，以前小團隊可以一周迭代上線一次，現(xiàn)在至少需要兩到三周時間。
業(yè)務邏輯越來越復雜，代碼間耦合很嚴重，修改一行代碼可能引入幾個線上問題。架構師意識到需要進行架構重構。
微服務架構
當單體架構演進到一定階段后開發(fā)測試的復雜性都會成本增加，團隊規(guī)模的擴大也會使得各自工作耦合性更嚴重，牽一發(fā)而動全身就是這種場景。
單體架構遇到瓶頸了，微服務架構就橫空出世了。微服務就是將之前的單體服務按照業(yè)務維度進行拆分，拆分粒度可大可小，拆分時機可以分節(jié)奏進行。最佳實踐是先將一些獨立的功能從單體中剝離出來抽成一個或多個微服務，這樣可以保障業(yè)務的連續(xù)性和穩(wěn)定性。
如上圖將一個商用應用拆分為六個獨立微服務。六個微服務可以使用Docker容器化進行多實例部署。
架構演化到這里遇到了一個難題，如果要查詢用戶所有的訂單，用戶服務可能會依賴訂單服務，用戶服務如何與訂單服務交互呢?訂單服務有多個實例該訪問哪一個?
通常有幾種解決辦法：
(1)服務地址硬編碼
服務的地址寫死在數(shù)據(jù)庫或者配置文件，通過訪問DNS域名進行尋址路由。
服務B的地址硬編碼在數(shù)據(jù)庫或者配置文件中，服務A首先需要拿到服務B的地址，然后通過DNS服務器解析獲取其中一實例的真實地址，最后可以向服務B發(fā)起請求。
如果遇到大促活動需要對服務實例擴容，大促完需要對服務實例進行下線，運維人員要做大量的手工操作，非常容易誤操作。
(2)服務動態(tài)注冊與發(fā)現(xiàn)
服務地址硬編碼還有一個非常致命的問題，如果一臺實例掛了，運維人員可能不能及時感知到，導致一部分用戶的請求會異常。
引入服務注冊與發(fā)現(xiàn)組件可以很好解決上面遇到的問題，避免過多的人工操作。
架構演進總結(jié)
在單體架構中一個應用程序就是一個服務包，包內(nèi)的模塊通過函數(shù)方法相互調(diào)用，模型足夠簡單，根本沒有服務注冊和發(fā)現(xiàn)一說。
在微服務架構中會將一個應用程序拆分為多個微服務，微服務會部署在不同的服務器、不同的容器、甚至多數(shù)據(jù)中心，微服務間要相互調(diào)用，服務注冊和發(fā)現(xiàn)成為了一個不可或缺的組件。
服務注冊與發(fā)現(xiàn)基本原理
服務注冊與發(fā)現(xiàn)是分為注冊和發(fā)現(xiàn)兩個關鍵的步驟。
服務注冊：服務進程在注冊中心注冊自己的元數(shù)據(jù)信息。通常包括主機和端口號，有時還有身份驗證信息，協(xié)議，版本號，以及運行環(huán)境的信息。
服務發(fā)現(xiàn)：客戶端服務進程向注冊中心發(fā)起查詢，來獲取服務的信息。服務發(fā)現(xiàn)的一個重要作用就是提供給客戶端一個可用的服務列表。
服務注冊
服務注冊有兩種形式：客戶端注冊和代理注冊。
客戶端注冊
客戶端注冊是服務自己要負責注冊與注銷的工作。當服務啟動后注冊線程向注冊中心注冊，當服務下線時注銷自己。
這種方式的缺點是注冊注銷邏輯與服務的業(yè)務邏輯耦合在一起，如果服務使用不同語言開發(fā)，那需要適配多套服務注冊邏輯。
代理注冊
代理注冊由一個單獨的代理服務負責注冊與注銷。當服務提供者啟動后以某種方式通知代理服務，然后代理服務負責向注冊中心發(fā)起注冊工作。
這種方式的缺點是多引用了一個代理服務，并且代理服務要保持高可用狀態(tài)。
服務發(fā)現(xiàn)
服務發(fā)現(xiàn)也分為客戶端發(fā)現(xiàn)和代理發(fā)現(xiàn)。
客戶端發(fā)現(xiàn)
客戶端發(fā)現(xiàn)是指客戶端負責向注冊中心查詢可用服務地址，獲取到所有的可用實例地址列表后客戶端根據(jù)負載均衡算法選擇一個實例發(fā)起請求調(diào)用。
這種方式非常直接，客戶端可以控制負載均衡算法。但是缺點也很明顯，獲取實例地址、負載均衡等邏輯與服務的業(yè)務邏輯耦合在一起，如果服務發(fā)現(xiàn)或者負載平衡有變化，那么所有的服務都要修改重新上線。
代理發(fā)現(xiàn)
代理發(fā)現(xiàn)是指新增一個路由服務負責服務發(fā)現(xiàn)獲取可用的實例列表，服務消費者如果需要調(diào)用服務A的一個實例可以直接將請求發(fā)往路由服務，路由服務根據(jù)配置好的負載均衡算法從可用的實例列表中選擇一個實例將請求轉(zhuǎn)發(fā)過去即可，如果發(fā)現(xiàn)實例不可用，路由服務還可以自行重試，服務消費者完全不用感知。
心跳機制
如果服務有多個實例，其中一個實例出現(xiàn)宕機，注冊中心是可以實時感知到，并且將該實例信息從列表中移出，也稱為摘機。
如何實現(xiàn)摘機?業(yè)界比較常用的方式是通過心跳檢測的方式實現(xiàn)，心跳檢測有主動和被動兩種方式。
被動檢測是指服務主動向注冊中心發(fā)送心跳消息，時間間隔可自定義，比如配置5秒發(fā)送一次，注冊中心如果在三個周期內(nèi)比如說15秒內(nèi)沒有收到實例的心跳消息，就會將該實例從列表中移除。
上圖中服務A的實例2已經(jīng)宕機不能主動給注冊中心發(fā)送心跳消息，15秒之后注冊就會將實例2移除掉。
主動檢測是注冊中心主動發(fā)起，每隔幾秒中會給所有列表中的服務實例發(fā)送心跳檢測消息，如果多個周期內(nèi)未發(fā)送成功或未收到回復就會主動移除該實例。
網(wǎng)頁名稱：十張圖搞懂服務注冊發(fā)現(xiàn)機制
網(wǎng)頁鏈接：http://m.5511xx.com/article/cohpsjo.html
