第三篇：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路由項目，來演示多節點服務宕機，系統還能運行的案例。