解決什么問題

?闡述微服務(wù)以及服務(wù)注冊發(fā)現(xiàn)的部分概念

?闡述Eureka服務(wù)注冊與發(fā)現(xiàn)的部分原理及細(xì)節(jié)

為什么需要服務(wù)中心

過去，每個應(yīng)用都是一個CPU，一個主機(jī)上的單一系統(tǒng)。然而今天，隨著大數(shù)據(jù)和云計算時代的到來，任何獨立的程序都可以運行在多個計算機(jī)上。并且隨著業(yè)務(wù)的發(fā)展，訪問用戶量的增加，開發(fā)人員或小組的增加，系統(tǒng)會被拆分成多個功能模塊。拆分后每個功能模塊可以作為一個獨立的子系統(tǒng)提供其職責(zé)范圍內(nèi)的功能。而多個子系統(tǒng)中，由于職責(zé)不同并且會存在相互調(diào)用，同時可能每個子系統(tǒng)還需要多個實例部署在多臺服務(wù)器或者鏡像中，導(dǎo)致了子系統(tǒng)間的相互調(diào)用形成了一個錯綜復(fù)雜的網(wǎng)狀結(jié)構(gòu)。用幾幅圖說明一下：

單體應(yīng)用：

隨著業(yè)務(wù)的發(fā)展，經(jīng)過了多個系統(tǒng)架構(gòu)的演變，變成了這樣（拿百度的功能舉個栗子）：

圖中，每個網(wǎng)頁搜索子系統(tǒng)和百度地圖子系統(tǒng)的實例都可以視同為一個微服務(wù)。網(wǎng)頁搜索子系統(tǒng)為百度地圖子系統(tǒng)提供了“用戶查詢內(nèi)容、用戶IP地址”等信息提供的服務(wù)接口，為百度地圖子系統(tǒng)定位用戶地理信息情況提供數(shù)據(jù)依據(jù)。

百度地圖子系統(tǒng)提供了“根據(jù)內(nèi)容查詢出地圖信息”的接口提供給其他子系統(tǒng)調(diào)用，而這里網(wǎng)頁搜索子系統(tǒng)調(diào)用了這個接口，獲取地圖相關(guān)信息。

網(wǎng)頁搜索子系統(tǒng)和百度地圖子系統(tǒng)又提供了各自對外用戶調(diào)用的網(wǎng)頁搜索、地圖搜索等各自的對外服務(wù)。這個過程就形成了以上錯綜復(fù)雜的網(wǎng)狀結(jié)構(gòu)。而實際上這樣還遠(yuǎn)遠(yuǎn)不夠，因為每個子系統(tǒng)往往會提供多個對內(nèi)的其他子系統(tǒng)調(diào)用的服務(wù)接口，同時也會調(diào)用多個不同子系統(tǒng)提供的多個服務(wù)接口，還會對外提供多個各自的服務(wù)接口。所以實際中上圖的網(wǎng)狀調(diào)用結(jié)構(gòu)將會成幾何倍的擴(kuò)張。而且隨著用戶量的增加，每個子系統(tǒng)還需要繼續(xù)增加更多的實例來提供服務(wù)，從而導(dǎo)致了凌亂的加劇。

對于微服務(wù)之間錯綜復(fù)雜的調(diào)用關(guān)系，通過eureka來管理，可以讓每個服務(wù)之間不用關(guān)心如何調(diào)用的問題，專注于自己的業(yè)務(wù)功能實現(xiàn)。

從系統(tǒng)架構(gòu)的演變到對于微服務(wù)架構(gòu)的思考

為什么上圖中的系統(tǒng)演變最終會變成如圖所示的樣子？這是一種架構(gòu)思維，這里不擴(kuò)展來說。簡單描述一下微服務(wù)架構(gòu)是為了解決什么問題。隨著系統(tǒng)結(jié)構(gòu)、架構(gòu)的演變，系統(tǒng)功能的增加，用戶量的增加，開發(fā)人員的增加等各種增加情況下，需要有一個比較好擴(kuò)展的系統(tǒng)架構(gòu)來快速、盡量減少代碼改動的前提下以支持系統(tǒng)功能的開發(fā)，用戶量增加導(dǎo)致的硬件資源橫向擴(kuò)容，以及開發(fā)人員增加時的協(xié)同工作效率。在此基礎(chǔ)上需要解決系統(tǒng)的穩(wěn)定性、容錯性、高并發(fā)的支持性等。以及隨著系統(tǒng)功能的增加如何有效的管理系統(tǒng)，排查、定位系統(tǒng)問題。同時當(dāng)參與項目的人（包含測試、運維、業(yè)務(wù)等人員）越來越多時，如何能更高效的彼此之間協(xié)同辦公的效率等等。

所以微服務(wù)架構(gòu)需要考慮的不僅僅是軟件架構(gòu)本身，需要從參與到整個項目實施過程中的各個環(huán)節(jié)，可能的問題以及人員協(xié)同的整體情況去考慮。讓整個項目做到可用（滿足功能以及硬件資源的橫向擴(kuò)容）、可行（滿足整個系統(tǒng)運行中的各個點的監(jiān)控、排錯等）、可持續(xù)（滿足系統(tǒng)功能的可持續(xù)集成、以及系統(tǒng)運行的可持續(xù)性）以及高效（系統(tǒng)運行的高效、人員協(xié)同工作的高效、功能迭代的高效等）。

Eureka應(yīng)用場景中的一些概念

微服務(wù)：

Spring Cloud提供了微服務(wù)解決的一整套方案，而Eureka是其重要組件，所以先要了解什么是“微服務(wù)”。在大型系統(tǒng)架構(gòu)中，會拆分多個子系統(tǒng)。這些系統(tǒng)往往都有這幾個功能：提供接口，調(diào)用接口，以及該子系統(tǒng)自身的業(yè)務(wù)功能。這樣的一個子系統(tǒng)就稱為一個“微服務(wù)”。（可以理解為一個子系統(tǒng)的代碼所實現(xiàn)的功能）

比如百度的搜索子系統(tǒng)，就具備了：根據(jù)用戶的輸入的信息對信息分詞功能、對每個分詞給予權(quán)重功能、然后根據(jù)分詞和權(quán)重等信息計算出網(wǎng)頁相關(guān)度功能、最后把相關(guān)度高的網(wǎng)頁按照一定算法排序后提供結(jié)果功能、記錄用戶錄入信息功能等等業(yè)務(wù)功能。同時它還提供用戶錄入信息提供的接口給其它子系統(tǒng)調(diào)用，如地圖子系統(tǒng)、廣告推薦子系統(tǒng)會調(diào)用該接口后完成各自的業(yè)務(wù)功能。同時搜索子系統(tǒng)也會調(diào)用其它子系統(tǒng)的接口，如調(diào)用地圖子系統(tǒng)的地圖顯示接口等。

實例：

每個服務(wù)都會部署到多個機(jī)器（或鏡像）中，這些多個部署的應(yīng)用就是實例。（可以理解為一套子系統(tǒng)代碼被部署到了多個機(jī)器上）

Eureka的管理：

基于以上概念，使用Eureka管理時會具備幾個特性：

→服務(wù)需要有一個統(tǒng)一的名稱（或服務(wù)ID）并且是唯一標(biāo)識，以便于接口調(diào)用時各個接口的區(qū)分。并且需要將其注冊到Eureka Server中，其他服務(wù)調(diào)用該接口時，也是根據(jù)這個唯一標(biāo)識來獲取。

→服務(wù)下有多個實例，每個實例也有一個自己的唯一實例ID。因為它們各自有自己的基礎(chǔ)信息如：不同的IP。所以它們的信息也需要注冊到Eureka Server中，其他服務(wù)調(diào)用它們的服務(wù)接口時，可以查看到多個該服務(wù)的實例信息，根據(jù)負(fù)載策略提供某個實例的調(diào)用信息后，調(diào)用者根據(jù)信息直接調(diào)用該實例。

eureka如何管理服務(wù)調(diào)用

eureka如何管理服務(wù)調(diào)用的？我們先來看個圖：

→在Eureka Client啟動的時候，將自身的服務(wù)的信息發(fā)送到Eureka Server。然后進(jìn)行2調(diào)用當(dāng)前服務(wù)器節(jié)點中的其他服務(wù)信息，保存到Eureka Client中。當(dāng)服務(wù)間相互調(diào)用其它服務(wù)時，在Eureka Client中獲取服務(wù)信息（如服務(wù)地址，端口等）后，進(jìn)行第3步，根據(jù)信息直接調(diào)用服務(wù)。（注：服務(wù)的調(diào)用通過http(s)調(diào)用）

→當(dāng)某個服務(wù)僅需要調(diào)用其他服務(wù)，自身不提供服務(wù)調(diào)用時。在Eureka Client啟動后會拉取Eureka Server的其他服務(wù)信息，需要調(diào)用時，在Eureka Client的本地緩存中獲取信息，調(diào)用服務(wù)。

→Eureka Client通過向Eureka Serve發(fā)送心跳（默認(rèn)每30秒）來續(xù)約服務(wù)的。 如果客戶端持續(xù)不能續(xù)約，那么，它將在大約90秒內(nèi)從服務(wù)器注冊表中刪除。 注冊信息和續(xù)訂被復(fù)制到集群中的Eureka Serve所有節(jié)點。 以此來確保當(dāng)前服務(wù)還“活著”，可以被調(diào)用。

→來自任何區(qū)域的Eureka Client都可以查找注冊表信息（每30秒發(fā)生一次），以此來確保調(diào)用到的服務(wù)是“活的”。并且當(dāng)某個服務(wù)被更新或者新加進(jìn)來，也可以調(diào)用到新的服務(wù)。

簡單的了解了eureka如何管理服務(wù)調(diào)用的之后，我們看看官網(wǎng)提供的圖片，進(jìn)一步了解更多信息（官網(wǎng)地址：https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance）：

這個圖從上而下，首先看到us-east-1c、us-east-1d、us-east-1e這些代表了一個可用區(qū)。簡單舉個栗子，假設(shè)一個Eureka Server集群下面的分布情況是這樣的：

“北京集群中心”是一個區(qū)域，北京市內(nèi)的機(jī)房A和B為可用區(qū)（對應(yīng)官網(wǎng)圖片中的us-east-1c、us-east-1d、us-east-1e）。區(qū)域（Region）和可用區(qū)（Zone或者Availability Zone）均是AWS的概念。在非AWS環(huán)境下，我們可以簡單地將region理解為Eureka某個地區(qū)的集群中心，zone理解成該區(qū)域的每個機(jī)房。每個區(qū)域是通過外網(wǎng)連接，所以速度、穩(wěn)定性上不能保證。而每個可用區(qū)之間一般是內(nèi)網(wǎng)直連，保證速度。想更多了解AWS概念的可用查看http://blog.csdn.net/awschina/article/details/17639191

回到官網(wǎng)的圖片可以看出在這個體系中，有2個主體：Eureka Server和Eureka Client。

Eureka Server：

提供服務(wù)注冊：各個微服務(wù)啟動時，會通過Eureka Client向Eureka Server進(jìn)行注冊自己的信息（例如服務(wù)信息和網(wǎng)絡(luò)信息），Eureka Server會存儲該服務(wù)的信息。

提供服務(wù)信息提供：服務(wù)消費者在調(diào)用服務(wù)時，本地Eureka Client沒有的情況下，會到Eureka Server拉取信息。

提供服務(wù)管理：通過Eureka Client的Cancel、心跳監(jiān)控、renew等方式來維護(hù)該服務(wù)提供的信息以確保該服務(wù)可用以及服務(wù)的更新。

信息同步：每個Eureka Server同時也是Eureka Client，多個Eureka Server之間通過P2P復(fù)制的方式完成服務(wù)注冊表的同步。同步時，被同步信息不會同步出去。也就是說有3個Eureka Server，Server1有新的服務(wù)信息時，同步到Server2后，Server2和Server3同步時，Server2不會把從Server1那里同步到的信息同步給Server3，只能由Server1自己同步給Server3。

每個可用區(qū)有一個Eureka集群，并且每個可用區(qū)至少有一個eureka服務(wù)器來處理區(qū)內(nèi)故障。為了實現(xiàn)高可用，一般一個可用區(qū)中由三個Eureka Server組成。

Eureka Client

Eureka Client是一個Java客戶端，用于簡化與Eureka Server的交互。并且管理當(dāng)前微服務(wù)，同時為當(dāng)前的微服務(wù)提供服務(wù)提供者信息。

Eureka Client會拉取、更新和緩存Eureka Server中的信息。即使所有的Eureka Server節(jié)點都宕掉，服務(wù)消費者依然可以使用緩存中的信息找到服務(wù)提供者。

Eureka Client在微服務(wù)啟動后，會周期性地向Eureka Server發(fā)送心跳（默認(rèn)周期為30秒）以續(xù)約自己的信息。如果Eureka Server在一定時間內(nèi)沒有接收到某個微服務(wù)節(jié)點的心跳，Eureka Server將會注銷該微服務(wù)節(jié)點（默認(rèn)90秒）。

Eureka Client包含服務(wù)提供者Applicaton Service和服務(wù)消費者Application Client

Applicaton Service：服務(wù)提供者，提供服務(wù)給別個調(diào)用。

Application Client：服務(wù)消費者，調(diào)用別個提供的服務(wù)。

往往大多數(shù)服務(wù)本身既是服務(wù)提供者，也是服務(wù)消費者。

其它動作：

Register：服務(wù)注冊

當(dāng)Eureka客戶端向Eureka Server注冊時，它提供自身的元數(shù)據(jù)，比如IP地址、端口，運行狀況指示符URL，主頁等。

Renew：服務(wù)續(xù)約

Eureka Client會每隔30秒發(fā)送一次心跳來續(xù)約。 通過續(xù)約來告知Eureka Server該Eureka客戶仍然存在，沒有出現(xiàn)問題。 正常情況下，如果Eureka Server在90秒沒有收到Eureka客戶的續(xù)約，它會將實例從其注冊表中刪除。 建議不要更改續(xù)約間隔。

Fetch Registries：獲取注冊列表信息

Eureka客戶端從服務(wù)器獲取注冊表信息，并將其緩存在本地?？蛻舳藭褂迷撔畔⒉檎移渌?wù)，從而進(jìn)行遠(yuǎn)程調(diào)用。該注冊列表信息定期（每30秒鐘）更新一次。每次返回注冊列表信息可能與Eureka客戶端的緩存信息不同， Eureka客戶端自動處理。如果由于某種原因?qū)е伦粤斜硇畔⒉荒芗皶r匹配，Eureka客戶端則會重新獲取整個注冊表信息。 Eureka服務(wù)器緩存注冊列表信息，整個注冊表以及每個應(yīng)用程序的信息進(jìn)行了壓縮，壓縮內(nèi)容和沒有壓縮的內(nèi)容完全相同。Eureka客戶端和Eureka 服務(wù)器可以使用JSON / XML格式進(jìn)行通訊。在默認(rèn)的情況下Eureka客戶端使用壓縮JSON格式來獲取注冊列表的信息。

Cancel：服務(wù)下線

Eureka客戶端在程序關(guān)閉時向Eureka服務(wù)器發(fā)送取消請求。 發(fā)送請求后，該客戶端實例信息將從服務(wù)器的實例注冊表中刪除。該下線請求不會自動完成，它需要調(diào)用以下內(nèi)容：

DiscoveryManager.getInstance().shutdownComponent()；

Eviction 服務(wù)剔除

在默認(rèn)的情況下，當(dāng)Eureka客戶端連續(xù)90秒沒有向Eureka服務(wù)器發(fā)送服務(wù)續(xù)約，即心跳，Eureka服務(wù)器會將該服務(wù)實例從服務(wù)注冊列表刪除，即服務(wù)剔除。

結(jié)語：了解了以上一些基礎(chǔ)的概念和原理，對于Eureka的運行情況以及Eureka配置的理解就相對容易多了。最后附上一個轉(zhuǎn)載來的Eureka參數(shù)配置項詳解：http://m.itdecent.cn/p/98f4e5f6bca7