spring cloud服務之間的調用之ribbon詳解

昨天，我們通過一個實例演示了，spring-cloud服務注冊組件——Eureka的基本配置和簡單用法，但是服務注冊就是為了方便后期的發現和調用，所以今天我們趁熱打鐵，分享下spring-cloud服務之間的調用。

關于spring-cloud的服務調用，我們首先需要了解它的兩個核心組件Ribbon和Feign。

我們都知道，spring boot的接口都是基于REST實現的，但是在實際線上運行的時候，考慮到用戶規模、服務可用性等方面的因素，我們一般很少是單節點運行的，通常都是以集群模式部署的，但是在集群部署中，又有一個核心的問題必須解決——負載均衡。關于負載均衡，各位小伙伴應該不陌生，最常用的組件之一nginx其中一個很核心的用途就是做負載均衡，但是nginx在實際做負載均衡的時候，確實不夠方便，需要手動配置服務地址，如果服務地址發生變化，相關配置也需要修改，所以不夠靈活。

當然spring cloud作為一款微服務綜合框架，它自然也提供了自己的一套負載均衡解決方案，所以接下來我們就來看下spring cloud的負載均衡組件——Ribbon。

Ribbon中文的意思是絲帶、帶狀物，正如它的含義，它就是連接調用方和服務之間的紐帶。

我們先通過一個簡單實例，來演示下，然后在示例的過程中來解釋，首先是它的核心依賴：

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-ribbon</artifactId> <version>2.2.9.RELEASE</version></dependency>配置

這個組件你需要添加到服務調用方的依賴中。同時，還需要增加它的配置：

@Configurationpublic class RibbonConfig { // 多節點負載 @LoadBalanced @Bean(name = 'restTemplate') public RestTemplate restTemplate() {return new RestTemplate(); }}

@LoadBalanced注解的作用是啟用多節點負載，這樣后期我們在調用的時候，RestTemplate客戶端其實就是通過負載均衡的方式在調用服務提供者。

然后，在服務調用方，我們通過RestTemplate去調用我們的服務提供者：

@Autowiredprivate RestTemplate restTemplate;@GetMapping('/ribbon')public Object queryUserByProductId() { List<JSONObject> jsonObjectList = Lists.newArrayList(); for (int i = 0; i < 10; i++) {JSONObject forObject = restTemplate.getForObject('http://user-center/user/' + (i + 1), JSONObject.class);jsonObjectList.add(forObject); } return jsonObjectList;}

這里我們通過前面配置的restTemplate來調用我們的用戶服務，接口的地址就是我們eureka注冊中心顯示的地址：

這里的地址不區分大小寫，都可以正常訪問。調用十次，主要是為了測試負載均衡的效果。

首先我們看下服務提供者配置：

server.port=8776eureka.client.service-url.defaultZone=http://localhost:8999/eureka, http://localhost:9000/eureka

第一個配置是指定服務的端口，如果在本地啟動的話，需要每啟動一次改一個端口，否則會提示端口沖突，如果你用的是IDEA的話，要先運行多應用啟動：

第二個配置就是設定我們的注冊中心，我們有兩個注冊中心，所以指定了兩個地址。

服務提供者就是一個簡單的controller，在controller內部，我們通過DiscoveryClient打印出被調用者的信息，方便我們查看。

@RestControllerpublic class UserController { private Logger logger = LoggerFactory.getLogger(UserController.class); @Autowired private DiscoveryClient discoveryClient; @GetMapping('/user/{id}') public JSONObject getUserById(@PathVariable(name = 'id') Long id) {List<ServiceInstance> instances = discoveryClient.getInstances('user-center');logger.info('instances = {}', instances);JSONObject user = new JSONObject();user.put('id', id);user.put('name', 'syske');return user; }}

這里需要注意的是，我們導入的DiscoveryClient是org.springframework.cloud.client.discovery包下的，如果不是同這個類，啟動的時候會報錯：

Consider defining a bean of type ’com.netflix.discovery.DiscoveryClient’ in your configuration.

我們分別啟動服務調用發和被調用方，這里我啟動了5個user-center，同時eureka服務也啟動了兩個，這個兩個注冊中心互相注冊監控，在實際應用中也可以確保服務穩定性。5個user-center有2個注冊在8999的注冊中心上，有3個注冊在9000的注冊中心上：

然后，我們訪問product的ribbon接口：

http://localhost:8881/ribbon

瀏覽器返回結果如下：

同時，在user-center端口為8771和8775的控制臺，會看到如下信息：

為什么只有8771和8775收到了請求，因為8771和8775都注冊到了8999的注冊中心，而且我們的product-service也注冊在該服務中心，所以就只調用了8771和8775這兩個服務：

根據運行結果，我們還發現在10次請求中，8771和8775各處理五次，這里面還有一個潛藏的知識點：Ribbon默認的負載策略是輪詢策略，這樣可以確保同一個注冊中心下的所有服務節點接收到同樣的請求頻次。

如果你把user-center（5個服務）、product-serive都注冊在同一個注冊中心，那么你會發現每個服務都會被調用2次。

總體來說，Ribbon對用戶來說感知確實不夠強，而且經過我的測試，我發現就算拿掉ribbon的依賴，依然可以正常負載均衡，這是因為eureka-client的依賴，已經添加過ribbon的依賴了：

好了，今天的Ribbon分享就先到這里吧，我們明天分享基于Feign的聲明式調用。

到此這篇關于spring-cloud服務之間的調用之ribbon的文章就介紹到這了,更多相關spring cloud服務調用內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！