你都用过SpringCloud的哪些组件，它们的原理是什么？

前言

服务治理 Spring Cloud Eureka

服务注册

服务发现

• 向注册中心注册自身提供的服务，并周期性的发送心跳来更新它非服务租约。
• 同时，也能从服务端查询当前注册的服务信息，并把他们缓存到本地，并周期性的刷新服务状态。

举例

客户端负载均衡 Spring Cloud Ribbon

服务A：
192.168.12.10:9001
192.168.12.11:9001
192.168.12.12:9001

• RandomRole： 从服务实例清单中随机选择一个服务实例。
• RoundRobinRule： 按照线性轮询的方式依次选择每个服务实例。
• RetryRule：根据轮询方式进行，且具备重试机制进行选择实例。
• WeightedResponseTimeRule：对RoundRobinRule的扩展，增加了根据实例的运行情况来计算权重，并根据权重来挑选实例。
• ZoneAvoidanceRule：根据服务方的zone区域和可用性来轮询选择。

实例代码

@RestController
public class ConsumerController {
    @Autowired
    RestTemplate restTemplate;
    @GetMapping("/ribbon-consumer")
    public String helloConsumer(){
        return restTemplate.getForEntity("http://example-service/index",String.class).getBody();
    }
}

声明式服务调用 Spring Cloud Feign

import org.springframework.cloud.netflix.feign.FeignClient;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
/**
 * 接口定义
 */
@FeignClient(value="service-hi",fallback = TestFeignServiceImpl.class)
public interface TestFeignService {

    @RequestMapping(value="/hi",method = RequestMethod.GET)
    String sayHi(@RequestParam("name") String name);
}
/**
 * 具体的服务实现
 */
@Component
public class TestFeignServiceImpl implements TestFeignService {
    @Override
    public String sayHi(String name) {
        return "你好,"+name;
    }
}

@RestController
public class TestController
{
    @Resource
    private TestFeignService testFeignService;

    @RequestMapping(value="/hi",method = RequestMethod.GET)
    public String sayHi(@RequestParam String name)
    {
    	// 调用远程服务
        return testFeignService.sayHi(name);
    }
}

那么Feign是如何实现这套封装逻辑的呢？

• 如果一个接口上定义了@FeignClient注解，Feign就会根据这个接口生成一个动态代理类。
• 如果调用方，在调用这个定义了@FeignClient注解的接口时，本质上是会调用Feign生成的代理类。
• Feign生成的动态代理类，会根据具体接口方法中的@RequestMapping等注解，来动态构造出需要请求的服务地址。
• 最后针对这个地址，再通过Ribbon发起服务调用，解析响应等操作。

服务容错保护 Spring Cloud Hystrix

@H_301_2@如果目前电商网站正在搞活动，进行抢购活动，下单的人非常多，这种高并发的场景下，订单服务的已经同时在处理50个下单请求了，并且都卡在了请求积分服务的过程中。订单服务已经没有能力去处理其他请求了。

@H_301_2@那么其他服务再来调用订单服务时，发订单服务无响应，这样就导致订单服务也不可用了。然后其他依赖订单服务的服务，也最终会导致不可用。这就是微服务架构中的服务雪崩。

API网关服务Spring Cloud Zuul

zuul.routes.api-zuul.path= /api-zuul/**
zuul.routes.api-zuul.serviceId= service-jimoer

总结

• 分布式配置中心：Spring Cloud Config；
• 消息总线：Spring Cloud Bus；
• 消息驱动：Spring Cloud Stream；
• 分布式服务跟踪：Spring Cloud Sleuth。

• Spring Cloud Eureka 各个微服务在启动时将自己注册到Eureka Server中，并且各个服务中的Eureka Client又能从注册中心获取各个服务的实例地址清单。
• Spring Cloud Ribbon 各个服务相互调用的时候，通过Ribbon来进行客户端的负载均衡，从多个实例中根据一定的策略选择一台进行请求。
• Spring Cloud Feign 基于动态代理机制，根据注解和参数拼接URL，选择具体的服务实例发起请求，简化了服务间相互调用的开发工作。
• Spring Cloud Hystrix 调用每个服务的时候都是通过线程池中的线程来发起的，不同的服务走不同的线程池，实现了服务的隔离，而且服务不可用时还提供了熔断机制以及支持降低措施。
• Spring Cloud Zuul 外部请求统一通过Zuul网关来进入，支持自定义路由规则，自定义过滤规则，可以实现同一的鉴权、限流、认证等功能。

（编辑：北几岛）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!