雖然出現報錯資訊，但是，整個程式並沒有出錯。至於原因，上的文字已經很好的解釋了。
在此，再簡單的說一下。
出現這種情況的原因是，我們的程式已經啟動（已經出現紅框中此條日誌，代表程式已經啟動，所以程式本身沒有問題。），為什麼會出現錯誤呢？
是因為在此系統中，我們要搭建的是集群環境， 每一台伺服器在自己啟動之後，都要去連線集群中的其他伺服器，以便於相互之間通訊傳遞資訊。
但是，我們肯定是按照次序啟動伺服器，我們不管先啟動哪一台伺服器，其他的伺服器都還沒有準備就緒，所以肯定會出現找不到要連線的伺服器，所以會報錯。
這個錯誤根本不需要解決， 把所有的伺服器全部啟動，整個集群就可以正常執行（因為出現的是連線錯誤，現在所有的伺服器已經準備就緒，所以不會再一次出現連線錯誤，除非某台伺服器down掉。）
ps:這裡有必要提醒一下，在微服務一書中使用的properties檔案配置，而啟動的是把服務都打包成jar來啟動的，不是用idea,請讀者留意
127.0.0.1peer1
127.0.0.1peer2
ps:官方文件中說到這個配置在生產環境當中（線上伺服器開發）沒有太大作用，這裡僅供本地使用
至此，在本機配置的eureka的集群完成
二、實現eureka高可用集群的優缺點
優點：也即是我們實現的目的，先來看（借用）下圖：
在實際開發中，註冊中心是存在多個節點。但從上面的例子當中，我們可以知道：
eureka server的同步遵循著乙個非常簡單的原則：只要有一條邊將節點連線，就可以進行資訊傳播與同步。
所以，如果存在多個節點，我們只需要將節點之間兩兩連線起來，形成通路，那麼他們之間的所有服務都可以共享。
而我們的服務只需要向集群中的任意乙個註冊中心中註冊，即可被所有註冊中心所共享，任意乙個註冊中心崩潰，都不會影響這個服務被呼叫。
缺點：不過這裡的缺點就是，如果peer1被關閉了，雖然peer2可以訪問到peer1上的服務，但是卻是不能實時監控的，因為這個不是向peer2中註冊的服務，所以當服務down之後，peer2中仍然會認為是up的。
HBase集群調優
2.5.2.1.zookeeper.session.timeout 這個預設值是3分鐘。這意味著一旦乙個server宕掉了，master至少需要3分鐘才能察覺到宕機，開始恢復。你可能希望將這個超時調短，這樣master就能更快的察覺到了。在你調這個值之前，你需要確認你的jvm的gc引數，否則乙個長時...
Kafka 集群調優
kafka 集群搭建鏈結 單個 kafka伺服器足以滿足本地開發或 poc要求，使用集群的最大好處是可以跨伺服器進行負載均衡，再則就是可以使用複製功能來避免因單點故障造成的資料丟失。在維護 kafka 或底層系統時，使用集群可以確保為客戶端提供高可用性。乙個 kafka 需要多少個 broker取決...
Mysql集群與調優
mysql集群與調優 實驗背景 1 安裝mysql cluster相關軟體包。2 依次配置管理 資料 sql節點。3 啟動並測試mysql cluster集群架構。實驗方案 使用6臺rhel 6.4虛擬機器，其中sqla和sqlb作為sql節點，ndba和ndbb作為資料節點，mgmd作為管理節點，...