SpringCloud微服务（原理篇）

SpringCloud微服务

微服务的模式和形式我在前面已经进行部分的提及，但是一直没落实到技术层面，这段时间我也在次研究了一下微服务，下面我先贴出SpringCloud整体涉及的结构

上面展示的这些是SpringCloud整体的结构

先对这些空间做一个初步的介绍：

Ribbon，客户端负载均衡，重试机制。

Hystrix，客户端容错保护，服务熔断、请求缓存、请求合并、依赖隔离。

Feign，声明式服务调用，本质上就是Ribbon+Hystrix（优化代码，避免直接使用RestTemplate的混乱）

Bus，消息总线，配合Config仓库修改的一种Stream实现，

独自启动不需要依赖其它组件。

Eureka，服务注册中心，特性有失效剔除、服务保护。

Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。

Zuul，API服务网关，功能有路由分发和过滤。

还有其它服务空间，包括configuration等等

那么什么是注册中心呢？

注册中心，是服务的提供者发布自己服务的地方，传统手写的restful接口提供的服务会涉及到服务发布者的端口IP等等，通过注册中心可以直接调用已经发布在上面的服务，只需要通过服务名即可

从图中可以看出，服务提供者将自己的服务发布到注册中心，消费者从注册中心取出服务，然后消费，这样生产者只需要关注自身的业务，将自己的服务发布到注册中心就行了，消费者无需关注生产者的内容，只需要从注册中心取出服务就行了，这样将生产者和消费者直接的耦合给断绝了

为什么使用Restful?

首先springcloud对比dubbo，最大的特点之一就是使用Restful的模式进行交互，dubbo是基于RPC进行通信的，而Restful是基于Http协议进行的，从协议的角度上来说Http和RPC都是基于TCP进行研发的协议，Http是最广泛的，不仅支持浏览器还支持各种APP通信，这么来说吧Http就是大家都在用的协议，而RPC是针对某一个平台某一个环节针对性开发的自定义协议，Http由于大众化，所以本身协议会有点笨重，解析起来自然也比RPC要慢，这也是RPC的优势之一，但是Http具有良好的跨平台性质，如下图：

SpringCloud服务的横向拓展

使用SpringCloud的另一个目的就是便于服务的横向拓展，大家都知道，当某一个服务由于访问压力变成瓶颈的时候，我们常常希望这个服务能进行负载均衡，分摊压力，以便于更好的像外界提供服务

我们可以在图片中看出，用户服务是具有两个实例的，但是消费者并不知道用户服务是具有两个实例，消费者只知道，当前有用户服务对外提供服务，所以消费者只需要知道服务名就行了，不用在意是哪个服务实例对其提供服务，这样也是进一步封装生产者对外提供服务，同时做了负载均衡，这样加入用户服务突然增加业务量，那么我们只需要再运行多个用户服务的实例即可

SpringCloud熔断机制

在开始熔断机制原理讲解之前,先理解一下什么是服务依赖

从图片上来看，第一行服务A是调用服务B，第二行服务A调用服务B，服务B调用服务C，这样就有一个服务链，A->B->C，假设现在由于网络动荡或者服务器奔溃的原因，服务C挂掉了，然而服务A的访问仍然很大，这样服务A继续请求服务B，而服务B由于无法调用服务C一直在等待，最后导致请求过多，服务B也被压垮了

熔断的原理

熔断的原理其实就和保险丝差不多

当C服务停止的时候，B自动调用写死的数据进行回复，从而避免因为请求过多导致A服务奔溃的情况