第十章深入了解Eureka學習目標了解Eureka的自我保護模式。學會搭建Eureka的高可用集群。了解Eureka安全認證，以及Eureka和ZooKeeper的區別。第9章我們了解了SpringCloud的搭建，了解了什么是Eureka，以及它的服務端和客戶端，本章我們來更加深入地了解Eureka。Eureka的自我保護模式12搭建Eureka的高可用集群3EurekaRESTAPI4Eureka安全認證5Eureka和Zookeeper比較Eureka的自我保護模式默認情況下，如果EurekaServer在90s內沒有接收到某個微服務的心跳，EurekaServer將會移除該微服務。但是當發生網絡故障時，微服務與EurekaServer之間無法正常通信，而微服務本身是正常運行的，則此時不應該移除這個微服務。所以Eureka引入了自我保護模式。官方對于自我保護模式的定義是：一種針對網絡異常波動的安全保護措施。使用自我保護模式能使Eureka集群更加健壯、穩定地運行。自我保護模式的工作機制是：如果在15min內超過85%的客戶端節點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心之間出現了網絡故障，EurekaServer將自動啟動自我保護機制，此時EurekaServer不再從注冊列表中移除因為長時間沒收到心跳而應該過期的服務。我們來做實驗驗證一下該機制。先啟動第9章我們創建的EurekaServer和兩個微服務，然后訪問注冊中心。Eureka的自我保護模式Eureka的自我保護模式然后，我們停止其中一個微服務order，大概90s后再刷新一下這個頁面，可以看到頁面中出現紅色文字提示，如圖所示。出現這個提示就表明EurekaServer觸發了自我保護，而實例列表中確實沒有移除我們停止的order微服務。Eureka的自我保護模式為了驗證續約頻率高于閾值的情況，我們必須增加微服務的數量。為了方便，我們通過在同一個微服務中配置多個運行的方式快速得到6個微服務，如圖所示。單擊左上角的加號選擇SpringBoot，然后選擇Mainclass啟動類，再添加不同的端口號和名字即可。因為每個微服務都要分配一個不同的端口號和名字，所以需要通過設置覆蓋端口號和名字的配置。Eureka的自我保護模式然后我們啟動這些微服務，再次訪問注冊中心，可以看到注冊了6個微服務，如圖所示。接著，我們停止一個微服務goods5，大概90s后刷新此頁面，結果如圖所示。可以發現注冊中心直接移除了goods5，證明此時并沒有觸發自我保護，因為我們只停止了眾多微服務中的一個，續約頻率低于閾值85%。Eureka的自我保護模式通過上面的實驗，我們證實了EurekaServer的自我保護模式。在開發過程中，更多時候我們想知道服務真實的續約狀態，這時就需要關閉EurekaServer的自我保護模式了。通過配置eureka.server.enable-self-preservation為false禁用自我保護模式，如程序清單10-1所示。不過在生產環境時建議開啟此配置。Eureka的自我保護模式12搭建Eureka的高可用集群3EurekaRESTAPI4Eureka安全認證5Eureka和Zookeeper比較搭建Eureka的高可用集群用了注冊中心后，所有的服務都要通過注冊中心來進行信息交換。注冊中心的穩定性非常重要，一旦注冊中心掉線，將會影響到整個系統的穩定性。所以在實際開發中，Eureka一般都是以集群的形式出現的。EurekaServer集群中的節點通過點對點通信的方式共享服務注冊表。下面我們搭建一個3個EurekaServer的集群。前面單個注冊中心實例名稱是localhost，現在是集群，不能都是localhost，所以需要配置本機hosts，來實現本機域名映射。打開C:\Windows\System32\drivers\etc中的hosts文件，添加配置，如程序清單10-2所示。搭建Eureka的高可用集群然后，為了方便，我們直接在第9章創建的EurekaServer中通過增加YAML配置的方式添加兩個EurekaServer。能這樣添加是因為多個YAML文件可以寫在一起，并且IDEA支持通過指定不同配置啟動多個同一項目。我們先注釋掉之前的配置，然后添加配置，如程序清單10-3所示。搭建Eureka的高可用集群搭建Eureka的高可用集群然后，我們修改order微服務配置中的注冊中心地址，如程序清單10-4所示。先注釋掉之前的地址，再添加一個指向注冊中心server1的地址。最后我們啟動3個注冊中心，再啟動order微服務。當啟動前兩個注冊中心時可能會出現連接超時的異常，因為這3個注冊中心通過互相連接共同組成注冊中心集群，先啟動的必然無法連接到后啟動的，這時只需要等待啟動所有的就行，因為雖然有連接超時異常，但每過一定時間會嘗試再次連接，最終都會正常運行。搭建Eureka的高可用集群啟動完成后，我們分別訪問這3個注冊中心，如圖所示。可以看到，盡管我們只把order微服務注冊到了server1，但server2和server3中也有order微服務的注冊信息。在這個集群架構中，不區分主從節點，所有節點都是平等的。即使某一個節點宕機，EurekaClient也會自動切換到新的EurekaServer上，從而提高整個注冊中心的可用性。搭建Eureka的高可用集群搭建Eureka的高可用集群Eureka的自我保護模式12搭建Eureka的高可用集群3EurekaRESTAPI4Eureka安全認證5Eureka和Zookeeper比較EurekaRESTAPIEurekaRESTAPI是指通過指定的URL來查詢或操縱注冊到EurekaServer的EurekaClient。Netflix官方在GitHub的Wiki上專門寫了一篇文章“EurekaRESToperations”來介紹EurekaRESTAPI，具體內容如表所示。其中，實例表示注冊的微服務，即EurekaClient。API一列中，POST、GET、DELETE和PUT是指HTTP發送方法。而這種通過指定不同的方法便能對同一URL映射的資源做增刪改查操作的方式稱為RESTful風格，因此叫RESTAPI。EurekaRESTAPI下面，我們演示其中兩個API的使用。先啟動第9章創建的EurekaServer和兩個EurekaClient。然后使用Postman訪問“http://localhost:7000/eureka/apps”查詢所有實例，如圖所示。由于瀏覽器中無法添加請求頭“Accept:application/json”，并且需要使用PUT和DELETE方法，所以這里使用專業的接口測試工具Postman來發送請求。我們可以看到，這時返回的數據是非常直觀的JSON格式的數據，如果用瀏覽器則返回XML格式的數據，因為XML優先級高于JSON。EurekaRESTAPI然后，我們來演示一下暫停order微服務的操作。我們先復制order微服務的instanceId“LAPTOP-RMO4O7NO:order:7002”，而appId就是實例名，所以請求的URL如圖所示。EurekaRESTAPI發送后，顯示“Status:200”狀態碼則表示暫停order微服務成功。接著，在瀏覽器中訪問注冊中心，如圖所示，order微服務的狀態的確變為了OUT_OF_SERVICE。Eureka的自我保護模式12搭建Eureka的高可用集群3EurekaRESTAPI4Eureka安全認證5Eureka和Zookeeper比較Eureka安全認證Eureka負責服務治理，是微服務架構的核心基礎，所以它的重要性不言而喻。默認情況下，只要知道地址和端口，就能訪問和查看所有微服務的狀態以及一些監控信息，缺乏一定的安全性。Eureka的安全認證可以通過設置用戶名和密碼來確保對Eureka的面板信息進行安全的訪問，此時客戶端只能通過安全認證方式進行服務注冊。首先，在EurekaServer中導入Security依賴，如程序清單10-5所示。Eureka安全認證然后我們先不配置用戶名和密碼，直接重啟Eureka?？梢钥吹娇刂婆_輸出一個密碼，如圖所示。這就是Security隨機生成的密碼。我們先復制密碼，然后在瀏覽器中訪問注冊中心，如圖所示，輸入用戶名“user”，粘貼密碼，單擊“Signin”即可查看注冊中心服務列表。Eureka安全認證那么，如何自定義用戶名和密碼呢？只需要在YAML中配置，如程序清單10-6所示。設spring.security.和spring.security.user.password為hzdl，下面的defaultZone也要加上用戶名和密碼。Eureka安全認證那么現在EurekaClient該如何通過安全認證注冊呢？首先，在order微服務的配置文件中，像上面一樣修改defaultZone。然后在EurekaServer中，添加一個配置類用來關閉CSRF（Cross-SiteRequestForgery，跨站請求偽造），否則order微服務無法連接EurekaServer，如程序清單10-7所示。Eureka安全認證最后，分別啟動EurekaServer和order微服務，訪問注冊中心，如圖所示。Eureka的自我保護模式12搭建Eureka的高可用集群3EurekaRESTAPI4Eureka安全認證5Eureka和Zookeeper比較Eureka和Zookeeper比較SpringCloud中，除了可以使用Eureka作為注冊中心外，還可以通過配置的方式使用Zookeeper作為注冊中心。ZooKeeper是Apache軟件基金會的一個軟件項目，它為大型分布式計算提供開源的分布式配置服務、同步服務和命名注冊。在分布式領域有一個很著名的CAP理論：一致性（Consistency）、可用性（Availability）、分區容錯性（Partitiontolerance）。一致性是指數據在多個副本之間能夠保持一致的特性，等同于所有節點訪問同一份最新的數據副本。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作后，應該保證系統的數據仍然處于一致的狀態。可用性是指每次請求都能獲取到正確的響應，但是不保證獲取的數據為最新數據。分區容錯性是指分布式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非整個網絡環境都發生了故障。這3個特性中任何分布式系統只能保證兩個。由于分區容錯性在分布式系統中是必須要保證的，因此我們只能在可用性和一致性之間進行權衡。Eureka和Zookeeper最大的不同就是，Eureka保證的是可用性、分區容錯性，而ZooKeeper保證的是一致性、分區容錯性。Eureka和Zookeeper比較ZooKeeper中節點有主從之分，在ZooKeeper集群中，通常節點有多個，如果服務器節點啟動或者運行過程中leader服務器宕機了，就會通過選舉模式選出一個leader（“老大”），被稱為Master“主節點”。leader服務器為