原文地址：https://www.jianshu.com/p/2fa691d4a00a
Spring Cloud之Eureka服務註冊與發現（概念原理篇）
解決什麼問題
➟闡述微服務以及服務註冊發現的部分概念
➟闡述Eureka服務註冊與發現的部分原理及細節
爲什麼需要服務中心
過去，每個應用都是一個CPU，一個主機上的單一系統。然而今天，隨着大數據和雲計算時代的到來，任何獨立的程序都可以運行在多個計算機上。並且隨着業務的發展，訪問用戶量的增加，開發人員或小組的增加，系統會被拆分成多個功能模塊。拆分後每個功能模塊可以作爲一個獨立的子系統提供其職責範圍內的功能。而多個子系統中，由於職責不同並且會存在相互調用，同時可能每個子系統還需要多個實例部署在多臺服務器或者鏡像中，導致了子系統間的相互調用形成了一個錯綜複雜的網狀結構。用幾幅圖說明一下：
單體應用：
隨着業務的發展，經過了多個系統架構的演變，變成了這樣（拿百度的功能舉個栗子）：
圖中，每個網頁搜索子系統和百度地圖子系統的實例都可以視同爲一個微服務。網頁搜索子系統爲百度地圖子系統提供了“用戶查詢內容、用戶IP地址”等信息提供的服務接口，爲百度地圖子系統定位用戶地理信息情況提供數據依據。
百度地圖子系統提供了“根據內容查詢出地圖信息”的接口提供給其他子系統調用，而這裏網頁搜索子系統調用了這個接口，獲取地圖相關信息。
網頁搜索子系統和百度地圖子系統又提供了各自對外用戶調用的網頁搜索、地圖搜索等各自的對外服務。這個過程就形成了以上錯綜複雜的網狀結構。而實際上這樣還遠遠不夠，因爲每個子系統往往會提供多個對內的其他子系統調用的服務接口，同時也會調用多個不同子系統提供的多個服務接口，還會對外提供多個各自的服務接口。所以實際中上圖的網狀調用結構將會成幾何倍的擴張。而且隨着用戶量的增加，每個子系統還需要繼續增加更多的實例來提供服務，從而導致了凌亂的加劇。
對於微服務之間錯綜複雜的調用關係，通過eureka來管理，可以讓每個服務之間不用關心如何調用的問題，專注於自己的業務功能實現。
從系統架構的演變到對於微服務架構的思考
爲什麼上圖中的系統演變最終會變成如圖所示的樣子？這是一種架構思維，這裏不擴展來說。簡單描述一下微服務架構是爲了解決什麼問題。隨着系統結構、架構的演變，系統功能的增加，用戶量的增加，開發人員的增加等各種增加情況下，需要有一個比較好擴展的系統架構來快速、儘量減少代碼改動的前提下以支持系統功能的開發，用戶量增加導致的硬件資源橫向擴容，以及開發人員增加時的協同工作效率。在此基礎上需要解決系統的穩定性、容錯性、高併發的支持性等。以及隨着系統功能的增加如何有效的管理系統，排查、定位系統問題。同時當參與項目的人（包含測試、運維、業務等人員）越來越多時，如何能更高效的彼此之間協同辦公的效率等等。
所以微服務架構需要考慮的不僅僅是軟件架構本身，需要從參與到整個項目實施過程中的各個環節，可能的問題以及人員協同的整體情況去考慮。讓整個項目做到可用（滿足功能以及硬件資源的橫向擴容）、可行（滿足整個系統運行中的各個點的監控、排錯等）、可持續（滿足系統功能的可持續集成、以及系統運行的可持續性）以及高效（系統運行的高效、人員協同工作的高效、功能迭代的高效等）。
Eureka應用場景中的一些概念
微服務：
Spring Cloud提供了微服務解決的一整套方案，而Eureka是其重要組件，所以先要了解什麼是“微服務”。在大型系統架構中，會拆分多個子系統。這些系統往往都有這幾個功能：提供接口，調用接口，以及該子系統自身的業務功能。這樣的一個子系統就稱爲一個“微服務”。（可以理解爲一個子系統的代碼所實現的功能）
比如百度的搜索子系統，就具備了：根據用戶的輸入的信息對信息分詞功能、對每個分詞給予權重功能、然後根據分詞和權重等信息計算出網頁相關度功能、最後把相關度高的網頁按照一定算法排序後提供結果功能、記錄用戶錄入信息功能等等業務功能。同時它還提供用戶錄入信息提供的接口給其它子系統調用，如地圖子系統、廣告推薦子系統會調用該接口後完成各自的業務功能。同時搜索子系統也會調用其它子系統的接口，如調用地圖子系統的地圖顯示接口等。
實例：
每個服務都會部署到多個機器（或鏡像）中，這些多個部署的應用就是實例。（可以理解爲一套子系統代碼被部署到了多個機器上）
Eureka的管理：
基於以上概念，使用Eureka管理時會具備幾個特性：
→服務需要有一個統一的名稱（或服務ID）並且是唯一標識，以便於接口調用時各個接口的區分。並且需要將其註冊到Eureka Server中，其他服務調用該接口時，也是根據這個唯一標識來獲取。
→服務下有多個實例，每個實例也有一個自己的唯一實例ID。因爲它們各自有自己的基礎信息如：不同的IP。所以它們的信息也需要註冊到Eureka Server中，其他服務調用它們的服務接口時，可以查看到多個該服務的實例信息，根據負載策略提供某個實例的調用信息後，調用者根據信息直接調用該實例。
eureka如何管理服務調用
eureka如何管理服務調用的？我們先來看個圖：
→在Eureka Client啓動的時候，將自身的服務的信息發送到Eureka Server。然後進行2調用當前服務器節點中的其他服務信息，保存到Eureka Client中。當服務間相互調用其它服務時，在Eureka Client中獲取服務信息（如服務地址，端口等）後，進行第3步，根據信息直接調用服務。（注：服務的調用通過http(s)調用）
→當某個服務僅需要調用其他服務，自身不提供服務調用時。在Eureka Client啓動後會拉取Eureka Server的其他服務信息，需要調用時，在Eureka Client的本地緩存中獲取信息，調用服務。
→Eureka Client通過向Eureka Serve發送心跳（默認每30秒）來續約服務的。 如果客戶端持續不能續約，那麼，它將在大約90秒內從服務器註冊表中刪除。 註冊信息和續訂被複制到集羣中的Eureka Serve所有節點。 以此來確保當前服務還“活着”，可以被調用。
→來自任何區域的Eureka Client都可以查找註冊表信息（每30秒發生一次），以此來確保調用到的服務是“活的”。並且當某個服務被更新或者新加進來，也可以調用到新的服務。
簡單的瞭解了eureka如何管理服務調用的之後，我們看看官網提供的圖片，進一步瞭解更多信息（官網地址：https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance）：
這個圖從上而下，首先看到us-east-1c、us-east-1d、us-east-1e這些代表了一個可用區。簡單舉個栗子，假設一個Eureka Server集羣下面的分佈情況是這樣的：
“北京集羣中心”是一個區域，北京市內的機房A和B爲可用區（對應官網圖片中的us-east-1c、us-east-1d、us-east-1e）。區域（Region）和可用區（Zone或者Availability Zone）均是AWS的概念。在非AWS環境下，我們可以簡單地將region理解爲Eureka某個地區的集羣中心，zone理解成該區域的每個機房。每個區域是通過外網連接，所以速度、穩定性上不能保證。而每個可用區之間一般是內網直連，保證速度。想更多瞭解AWS概念的可用查看http://blog.csdn.net/awschina/article/details/17639191
回到官網的圖片可以看出在這個體系中，有2個主體：Eureka Server和Eureka Client。
Eureka Server：
提供服務註冊：各個微服務啓動時，會通過Eureka Client向Eureka Server進行註冊自己的信息（例如服務信息和網絡信息），Eureka Server會存儲該服務的信息。
提供服務信息提供：服務消費者在調用服務時，本地Eureka Client沒有的情況下，會到Eureka Server拉取信息。
提供服務管理：通過Eureka Client的Cancel、心跳監控、renew等方式來維護該服務提供的信息以確保該服務可用以及服務的更新。
信息同步：每個Eureka Server同時也是Eureka Client，多個Eureka Server之間通過P2P複製的方式完成服務註冊表的同步。同步時，被同步信息不會同步出去。也就是說有3個Eureka Server，Server1有新的服務信息時，同步到Server2後，Server2和Server3同步時，Server2不會把從Server1那裏同步到的信息同步給Server3，只能由Server1自己同步給Server3。
每個可用區有一個Eureka集羣，並且每個可用區至少有一個eureka服務器來處理區內故障。爲了實現高可用，一般一個可用區中由三個Eureka Server組成。
Eureka Client
Eureka Client是一個Java客戶端，用於簡化與Eureka Server的交互。並且管理當前微服務，同時爲當前的微服務提供服務提供者信息。
Eureka Client會拉取、更新和緩存Eureka Server中的信息。即使所有的Eureka Server節點都宕掉，服務消費者依然可以使用緩存中的信息找到服務提供者。
Eureka Client在微服務啓動後，會週期性地向Eureka Server發送心跳（默認週期爲30秒）以續約自己的信息。如果Eureka Server在一定時間內沒有接收到某個微服務節點的心跳，Eureka Server將會註銷該微服務節點（默認90秒）。
Eureka Client包含服務提供者Applicaton Service和服務消費者Application Client
Applicaton Service：服務提供者，提供服務給別個調用。
Application Client：服務消費者，調用別個提供的服務。
往往大多數服務本身既是服務提供者，也是服務消費者。
其它動作：
Register：服務註冊
當Eureka客戶端向Eureka Server註冊時，它提供自身的元數據，比如IP地址、端口，運行狀況指示符URL，主頁等。
Renew：服務續約
Eureka Client會每隔30秒發送一次心跳來續約。 通過續約來告知Eureka Server該Eureka客戶仍然存在，沒有出現問題。 正常情況下，如果Eureka Server在90秒沒有收到Eureka客戶的續約，它會將實例從其註冊表中刪除。 建議不要更改續約間隔。
Fetch Registries：獲取註冊列表信息
Eureka客戶端從服務器獲取註冊表信息，並將其緩存在本地。客戶端會使用該信息查找其他服務，從而進行遠程調用。該註冊列表信息定期（每30秒鐘）更新一次。每次返回註冊列表信息可能與Eureka客戶端的緩存信息不同， Eureka客戶端自動處理。如果由於某種原因導致註冊列表信息不能及時匹配，Eureka客戶端則會重新獲取整個註冊表信息。 Eureka服務器緩存註冊列表信息，整個註冊表以及每個應用程序的信息進行了壓縮，壓縮內容和沒有壓縮的內容完全相同。Eureka客戶端和Eureka 服務器可以使用JSON / XML格式進行通訊。在默認的情況下Eureka客戶端使用壓縮JSON格式來獲取註冊列表的信息。
Cancel：服務下線
Eureka客戶端在程序關閉時向Eureka服務器發送取消請求。 發送請求後，該客戶端實例信息將從服務器的實例註冊表中刪除。該下線請求不會自動完成，它需要調用以下內容：
DiscoveryManager.getInstance().shutdownComponent()；
Eviction 服務剔除
在默認的情況下，當Eureka客戶端連續90秒沒有向Eureka服務器發送服務續約，即心跳，Eureka服務器會將該服務實例從服務註冊列表刪除，即服務剔除。
結語：瞭解了以上一些基礎的概念和原理，對於Eureka的運行情況以及Eureka配置的理解就相對容易多了。最後附上一個轉載來的Eureka參數配置項詳解：http://www.jianshu.com/p/98f4e5f6bca7