第三篇：Spring Cloud client服務集羣

1.爲什麼要集羣？

eureka client相當於一個訂單項目 放在tomcat中。

客戶端-->Nginx-->Zuul-->eureka client ，當（eureka client）在單節點的情況下，如果宕機，會影響到客戶使用，這個時候需要一個備胎做替補。

【奇思妙想】

可以把馬路當作一個模塊【訂單模塊的class文件】，而路燈是tomcat，我在馬路上操作的時候，你的路燈得亮着，也就是tomcat得是運行狀態。

如果你只有一個tomcat在運行，那麼當路燈由於天氣或者人爲情況導致滅了，那麼作爲客戶就不能在馬路上行走。

 但是如果你一條馬路上是有多個路燈，那麼就有很好的替補機制，一個壞了沒事，還有其他的路燈亮着，不影響人在路上行走。

 

把馬路看成模塊，多條馬路構建一個區域，這個區域就是系統，一個完整的生態圈。

 

代碼演示：

package com.cohesion.rest;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class OrderController {
    @Value("${server.port}")
    private String port;
    
    @Value("${spring.application.name}")
    private String serviceName;
    
    @RequestMapping(value="/order/helloWord")
    public String helloWord() {
        String returnStr = "您訪問的是：【"+serviceName+"】服務,【端口號】"+port;
        return returnStr;
    }

}

返回結果

如果這個order服務的8081端口服務掛了，那麼客戶端去請求order【訂單服務】的時候，就會出現異常。做的好的用【斷路器Hystrix】，來進行沒必要的資源浪費和等待。

但是【斷路器Hystrix】只能起到提供友好的客戶體驗和節省資源浪費&客戶等待時間，並不能讓客戶繼續操作下去。

 

這個時候就需要集羣來彌補這個操作，也就是服務從單節點變成多節點，當一個節點出現問題，會自動轉發到沒問題的節點中。從而讓客戶能繼續在系統上操作。不過可能會出現慢的問題，這個時候就需要提供一個服務報警的功能，讓運維人員知道情況，安排工程師去解決損壞的節點。

 

現在我們來配置多個order模塊。我的方法還是創建order項目，只是端口不一樣。IDEA可以直接把一個項目配置成多個端口，如果用IDEA可以這樣搞。

如項目結構圖，order是2個項目，已8081，一個是8082端口的服務，切換到註冊中心服務，發現有2發order服務註冊進來了。

 

 

 

 下一篇構建zuul路由項目，來演示多節點服務宕機，系統還能運行的案例。