qq_16570607的博客

基于server和client端实现全局刷新 将热刷新逻辑和具体的服务应用解耦

前言 开发高并发系统时有三把利器用来保护系统：缓存、降级和限流，API网关作为所有请求的入口，请求量大，我们可以通过对并发访问的请求进行限速来保护系统的可用性。 常用的限流算法比如有令牌桶算法，漏桶算法，计数器算法等。 目前限流提供了基于Redis的实现,我们需要增加对应的依赖： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-s

使用@HystrixCommand注解 如果我们使用的是@HystrixCommand注解，那么可以在注解中直接指定超时时间，如下： @HystrixCommand(fallbackMethod="fallback", commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000" ) } ) Hystrix配置整体的超时时间 h

直接使用hystrix时: 服务消费方: @RestController @RequestMapping("/consumer/users") public class UserController { @Autowired private RestTemplate restTemplate; @Autowired private DiscoveryClient discoveryClient; @GetMapping("{id}") // 当此方法无法正

RPC和MQ的区别 同步调用：对于要立即等待返回处理结果的场景，RPC是首选。 MQ 的使用： 一方面是基于性能的考虑，比如服务端不能快速的响应客户端（或客户端也不要求实时响应），需要在队列里缓存。 另外一方面，它更侧重数据的传输，因此方式更加多样化，除了点对点外，还有订阅发布等功能。 随着业务增长，有的处理端处理量会成为瓶颈，会进行同步调用改造为异步调用，这个时候可以考虑使用MQ。 RPC和MQ分别的适用场景 RPC比较适合–调用需要立即得到返回结果 比如在一个ERP系统中，有

比如说电商的商品服务，当我们把商品从大的单体里拆分出来的时候，就商品服务本身来讲，逻辑并没有足够复杂到 2 ~ 3 个人没法维护的地步，这时我们没有必要继续将商品服务拆的更细，但是随着业务的发展，商品的业务逻辑变的越来越复杂，可能同时服务公司的多个平台，此时你会发现商品服务本身面临的问题跟单体架构阶段面临的问题基本一样，这个阶段就需要我们将商品拆成更细粒度的服务，比如，库存服务、价格服务、类目服务、商品基础信息服务等等。3 个人负责开发一个系统。