Student111w的博客

Eureka集群的搭建

第一步 创建一个监控页面的module第二部 导入所需要的依赖 <dependencies> <!--hystrix依赖--> <!--导入hystrix依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-clo

@RestControllerpublic class DeptConsumerController { //RestTemplate 供我们直接调用 使用需要注册到Spring中 //三个参数（url,实体：map,Class<T>responseType,） @Autowired RestTemplate restTemplate;//提供多种便捷访问远程http服务的方法，简单的restful服务模板~ //前缀是固定的 http://l

前言上一篇文章地址点击此处我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。

前言上一篇文章 点击此处在之前的工程中我们使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码：String user = this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);如果就学到这里，你可能以后需要编写类似的大量重复代码，格式基本相同，无非参数不一样。有没有更简洁的方式，来对这些代码再次优化呢？简介Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC

Hystrix简介Hystrix,英文意思是豪猪，全身是刺，看起来就不好惹，是一种保护机制。Hystrix也是Netflix公司的一款组件。那么Hystix的作用是什么呢？具体要保护什么呢？Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。雪崩问题就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需

负载均衡结合上篇文章 点击查看Eureka注册中心什么是RibbonSpring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud构建的微服务和基础设施中。因为

服务消费方使用服务时报错看的我是一头雾水org.springframework.web.client.HttpServerErrorException: 500 null at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:97) ~[spring-web-5.0.8.RELEASE.jar:5.0.8.RELEASE] at org.sp

认识EurekaEureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。这就实现了服务的自动注册、发现、状态监控。Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址提供者：启动后向Eureka注册自己信息（地址，提供什么服务）消费者：向Eurek

产生背景系统架构演变集中式架构当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。存在的问题：代码耦合，开发维护困难无法针对不同模块进行针对性优化无法水平扩展单点容错率低，并发能力差垂直拆分当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分优点：系统拆分实现了流量分担，解决了并发问题可以针对不同模块进行优化方便水平扩展，负载均衡