我們來解決微服務的第一問題，服務的管理。
服務中心對外提供服務，需要對外暴露自己的位址。而consumer（呼叫者）需要記錄服務提供者的位址。將來位址出現變更，還需要及時更新。這在服務較少的時候並不覺得有什麼，但是在現在日益複雜的網際網路環境，乙個專案肯定會拆分出十幾，甚至數十個微服務。此時如果還人為管理位址，不僅開發困難，將來測試、發布上線都會非常麻煩，這與devops的思想是背道而馳的。
eureka做什麼？
eureka就好比是滴滴，負責管理、記錄服務提供者的資訊。服務呼叫者無需自己尋找服務，而是把自己的需求告訴eureka，然後eureka會把符合你需求的服務告訴你。
同時，服務提供方與eureka之間通過「心跳」機制進行監控，當某個服務提供方出現問題，eureka自然會把它從服務列表中剔除。
這就實現了服務的自動註冊、發現、狀態監控。
心跳(續約)：提供者定期通過http方式向eureka重新整理自己的狀態
我們公司採取的方案是自建式的基礎服務註冊中心
eureka架構中的三個核心角色：
eureka server即服務的註冊中心，在剛才的案例中，我們只有乙個eurekaserver，事實上eurekaserver也可以是乙個集群，形成高可用的eureka中心。
多個eureka server之間也會互相註冊為服務，當服務提供者註冊到eureka server集群中的某個節點時，該節點會把服務的資訊同步給集群中的每個節點，從而實現資料同步。因此，無論客戶端訪問到eureka server集群中的任意乙個節點，都可以獲取到完整的服務列表資訊。
乙個良好的註冊中心，除了高可用，還要有負載均衡，分發流量；
微服務中的註冊中心 Eureka
1 角色 1 eureka server 服務註冊中心 可以是乙個集群 對外暴露自己的位址給每個微服務使用 2 服務提供者 啟動後向 eurekaserver註冊自己資訊 位址 服務名 3 服務消費者 向 eurekaserver訂閱服務，eureka會將對應服務的所有提供者位址列表傳送給消費者，並...
Eureka服務註冊中心
1.適用場景有侷限 如果服務提供者的網路位址 ip和埠 發生變化，將會影響服務消費者。2.無法動態伸縮 每個微服務一般都會部署多個例項，從而實現實現容災和負載均衡，微服務系統需要具備自動伸縮的能力。如何解決上述方案 1 需要乙個強大的服務發現機制，服務消費者使用這種機制獲取服務提供者的網路資訊，及時...
eureka 服務註冊中心
作為服務註冊中心，eureka比zookeeper區別 著名的cap理論指出，乙個分布式系統不可能同時滿足c 一致性 a 可用性 和p 分割槽容錯性 由於分割槽容錯性在是分布式系統中必須要保證的，因此我們只能在a和c之間進行權衡。在此zookeeper保證的是cp,而eureka則是ap 1.zoo...