分布式:不同模块部署在不同服务器上 作用:分布式解决网站高并发带来问题
集群:多台服务器部署相同应用构成一个集群 作用:通过负载均衡设备共同对外提供服务
SOA:业务系统分解为多个组件,让每个组件都独立提供离散,自治,可复用的服务能力,通过服务的组合和编排来实现上层的业务流程 作用:简化维护,降低整体风险,伸缩灵活
微服务:架构设计概念,各服务间隔离(分布式也是隔离),自治(分布式依赖整体组合)其它特性(单一职责,边界,异步通信,独立部署)是分布式概念的跟严格执行SOA到微服务架构的演进过程 作用:各服务可独立应用,组合服务也可系统应用
SpringCloud的基础功能:
SpringCloud的高级功能:
现在有A、B、C、D四个服务,它们之间会互相调用(而且IP地址很可能会发生变化),一旦某个服务的IP地址变了,那服务中的代码要跟着变,手动维护这些静态配置(IP)非常麻烦!
创建一个E服务,将A、B、C、D四个服务的信息都注册到E服务上,E服务维护这些已经注册进来的信息
A、B、C、D四个服务都可以拿到Eureka(服务E)那份注册清单。A、B、C、D四个服务互相调用不再通过具体的IP地址,而是通过服务名来调用
Eureka专门用于给其他服务注册的称为Eureka Server(服务注册中心),其余注册到Eureka Server的服务称为Eureka Client。
在Eureka Server一般我们会这样配置:
register-with-eureka: false #false表示不向注册中心注册自己。 fetch-registry: false #false表示自己端就是注册中心,我的职责就是维护服务实例,并不需要去检索服务
Eureka Client分为服务提供者和服务消费者。
Eureka的治理机制:
最后,我们就有了这张图:
优秀博文:
通过Eureka服务治理框架,我们可以通过服务名来获取具体的服务实例的位置了(IP)。一般在使用SpringCloud的时候不需要自己手动创建HttpClient来进行远程调用。
可以使用Spring封装好的RestTemplate工具类,使用起来很简单:
// 传统的方式,直接显示写死IP是不好的! //private static final String REST_URL_PREFIX = "http://localhost:8001";
// 服务实例名 private static final String REST_URL_PREFIX = "http://MICROSERVICECLOUD-DEPT";
/** * 使用 使用restTemplate访问restful接口非常的简单粗暴无脑。 (url, requestMap, * ResponseBean.class)这三个参数分别代表 REST请求地址、请求参数、HTTP响应转换被转换成的对象类型。 */ @Autowired private RestTemplate restTemplate;
@RequestMapping(value = "/consumer/dept/add") public boolean add(Dept dept) { return restTemplate.postForObject(REST_URL_PREFIX + "/dept/add", dept, Boolean.class); }
为了实现服务的高可用,我们可以将服务提供者集群,实现负载均衡
负载均衡又区分了两种类型:
所以,我们的图可以画成这样:
如果我们在调用多个远程服务时,某个服务出现延迟,会怎么样?
在高并发的情况下,由于单个服务的延迟,可能导致所有的请求都处于延迟状态,甚至在几秒钟就使服务处于负载饱和的状态,资源耗尽,直到不可用,最终导致这个分布式系统都不可用,这就是“雪崩”。
针对上述问题, Spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能。
Hystrix提供几个熔断关键参数:滑动窗口大小(20)、 熔断器开关间隔(5s)、错误率(50%)
Hystrix还有请求合并、请求缓存这样强大的功能,在此我就不具体说明了,有兴趣的同学可继续深入学习~
Hystrix仪表盘:它主要用来实时监控Hystrix的各项指标信息。通过Hystrix Dashboard反馈的实时信息,可以帮助我们快速发现系统中存在的问题,从而及时地采取应对措施。
现在的服务是这样的:
除了可以开启单个实例的监控页面之外,还有一个监控端点 /turbine.stream
是对集群使用的。 从端点的命名中,可以引入Turbine, 通过它来汇集监控信息,并将聚合后的信息提供给 HystrixDashboard 来集中展示和监控。
参考资料:
为了简化我们的开发,Spring Cloud Feign出现了!它基于 Netflix Feign 实现,整合了 Spring Cloud Ribbon 与 Spring Cloud Hystrix, 除了整合这两者的强大功能之外,它还提供了声明式的服务调用(不再通过RestTemplate)。
Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验,开发者完全感知不到这是远程方法,更感知不到这是个HTTP请求。
下面就简单看看Feign是怎么优雅地实现远程调用的:
服务绑定:
// value --->指定调用哪个服务 // fallbackFactory--->熔断器的降级提示 @FeignClient(value = "MICROSERVICECLOUD-DEPT", fallbackFactory = DeptClientServiceFallbackFactory.class) public interface DeptClientService {
// 采用Feign我们可以使用SpringMVC的注解来对服务进行绑定! @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET) public Dept get(@PathVariable("id") long id);
@RequestMapping(value = "/dept/list", method = RequestMethod.GET) public List<Dept> list();
@RequestMapping(value = "/dept/add", method = RequestMethod.POST) public boolean add(Dept dept); }
Feign中使用熔断器:
/** * Feign中使用断路器 * 这里主要是处理异常出错的情况(降级/熔断时服务不可用,fallback就会找到这里来) */ @Component // 不要忘记添加,不要忘记添加 public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> { @Override public DeptClientService create(Throwable throwable) { return new DeptClientService() { @Override public Dept get(long id) { return new Dept().setDeptno(id).setDname("该ID:" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭") .setDb_source("no this database in MySQL"); }
@Override public List<Dept> list() { return null; }
@Override public boolean add(Dept dept) { return false; } }; } }
调用:
基于上面的学习,我们现在的架构很可能会设计成这样:
这样的架构会有两个比较麻烦的问题:
还是画个图来理解一下吧:
每个服务都有自己的IP地址,Nginx想要正确请求转发到服务上,就必须维护着每个服务实例的地址!而这些服务实例的IP地址还有可能会变,服务之间的划分也很可能会变。
购物车和订单模块都需要用户登录了才可以正常访问,基于现在的架构,只能在购物车和订单模块都编写校验逻辑,这无疑是冗余的代码。
为了解决上面这些常见的架构问题,API网关的概念应运而生。在SpringCloud中了提供了基于Netfl ix Zuul实现的API网关组件Spring Cloud Zuul。
Spring Cloud Zuul是这样解决上述两个问题的:
Zuul天生就拥有线程隔离和断路器的自我保护功能,以及对服务调用的客户端负载均衡功能。也就是说:Zuul也是支持Hystrix和Ribbon。
关于Zuul还有:
Zuul支持Ribbon和Hystrix,也能够实现客户端的负载均衡。我们的Feign不也是实现客户端的负载均衡和Hystrix的吗?既然Zuul已经能够实现了,那我们的Feign还有必要吗?
或者可以这样理解:
参考资料:
随着业务的扩展,我们的服务会越来越多,越来越多。每个服务都有自己的配置文件。
既然是配置文件,给我们配置的东西,那难免会有些改动的。
比如我们的Demo中,每个服务都写上相同的配置文件。万一我们有一天,配置文件中的密码需要更换了,那就得三个都要重新更改。
在分布式系统中,某一个基础服务信息变更,都很可能会引起一系列的更新和重启
Spring Cloud Config项目是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分,server提供配置文件的存储、以接口的形式将配置文件的内容提供出去,client通过接口获取数据、并依据此数据初始化自己的应用。
SpringCloud Config其他的知识:
使用SpringCloud Config可能的疑问:application.yml和 bootstrap.yml区别
SpringCloud系列文章参考资料:
参考书籍:
SpringCloud GitHub Demo(看完文章的同学可以自己练手玩玩,写好了ReadMe了):