今天學習了spring cloud 中的註冊中心——eureka，作為微服務的註冊中心，eureka需要對服務的可用狀態進行一個體現。直觀的體現方式就是在eureka啟動後的ui界面上可以看到服務的是否可用。 在某一個時刻下，如果後端某一個服務不可用了，eureka不會立即將其從ui界面上刪除。而是 ...
今天學習了spring cloud 中的註冊中心——eureka，作為微服務的註冊中心，eureka需要對服務的可用狀態進行一個體現。直觀的體現方式就是在eureka啟動後的ui界面上可以看到服務的是否可用。
在某一個時刻下，如果後端某一個服務不可用了，eureka不會立即將其從ui界面上刪除。而是等待一段時間後再刪除，在預設情況下，這個時間是90s。在90s內，eureka會有一個心跳機制來判斷服務是否健康。每相隔30s會發送一個心跳信號。如果超過3次，也就是90s未收到信號，則判定發送心跳信號的服務不可用了，這時候才會將服務刪除。
但是，這裡有一個問題。eureka接收心跳信號，信號也是通過網路傳輸的。假如，不是服務失效，而是網路狀態不好。導致eureka伺服器接收不到信號，那是否會因為網路的問題造成eureka誤判了服務的可用情況，導致服務被誤刪了呢？
考慮到這種情況，eureka設置了閾值。當15分鐘之內，若掛掉的服務超過了15%。（也就是eureka突然對項目服務中的15%失去了心跳信號）那eureka會判斷，這些15%的服務掛掉的原因，不是由於服務真的掛掉了，而是網路不好，心跳信號傳達不到。然後eureka不會刪除這些服務。
例子：三年一班今天老師上課突然發現了15%的學生（服務）都沒來上課（失效）。老師進行判斷，這15%的學生有可能是堵車（網路擁堵）了，不是故意遲到的。因為平常不會突然大量的學生同時遲到。老師不對他們追究責任（不刪除服務）。
