微服务之spring-cloud

一 什么是微服务

微服务就是把一个原本臃肿的项目按照功能模块进行拆分，形成多个功能较为独立和单一的服务，这些服务联合起来可以完成原来整个大服务的功能。

 

二 为什么要微服务化

一个服务包含太多功能，当某个部分出现故障，或是需要维护重启时，所有功能模块都会受到影响。

如果服务过大，部署时需要的时间也很长，也会对用户体验造成较大影响。

微服务化后，对单个小服务的维护不会对其他服务造成影响，且部署时间大大缩短，极大的降低了维护成本和提高了用户体验。

 

三 微服务和分布式的区别

微服务和分布式在某些方面很相似，比如都会通过多个服务模块来完成一件事情，可能都有多个实例运行在多台机器上。

但是，他们是有本质的区别的。微服务各个服务实例之间做的事情不同，而分布式的服务实例做的事情相同，只是各个实例处理的数据不同而已。而且，微服务并不要求各个实例一定要运行在不同的机器上，而分布式则是使用多台机器的算力来加快服务的执行。

 

四 spring-cloud与微服务的关系

微服务是一种项目架构方式，是一种概念，spring-cloud是对这种技术的一种实现方式。微服务有很多种实现方式，不只spring-cloud一种，我们也可以不借助任何框架自己来实现。

 

五 spring-cloud

spring-cloud是封装了多种框架的集合，是基于spring-boot来进行开发的。我们进行spring-cloud开发的时候，就是创建spring-boot项目，分别引入不同的框架实现对应的功能，这些框架各司其职，为微服务的正常运行保驾护航。那么，目前为止，spring-cloud微服务项目架构主要包含哪些框架呢，他们各自的作用和使用场景又是什么样子的呢？下面我们一一来看。

1. Eureka

 Eureka 是Netflix的子模块之一，也是一个核心的模块，Eureka 里有2个组件，一个是EurekaServer(一个独立的项目) ，用于定位服务以实现中间层服务器的负载平衡和故障转移，另一个便是EurekaClient（我们的微服务） 它是用于与Server交互的，可以使得交互变得非常简单:只需要通过服务标识符即可拿到服务。

Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。

而系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。

Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现。

Eureka Server可以搭建成集群做高可用，搭建的原则是，集群中的每个Eureka Server都可以看到所有的微服务，这样，即使集群种只有一个Eureka Server在工作，服务仍然可用。

集群服务要适应CAP（Consistency ，Availability，Partition tolerance：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在本地，另一台服务器放在外地（可能是外省，甚至是外国），这就是两个区，它们之间可能无法通信。），由于分区容错的特性，Consistency 和 Availability可能不能做到同时满足，Eureka遵循的是AP原则。

2. Ribbon + IRule

• Ribbon

Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项，如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

客户端负载均衡，是指在客户端来进行选择连接哪个服务，客户端去向Eureka Server获取了所有的微服务信息，因此可以自己做出选择。nginx是服务端负载均衡，客户端连接的时候不会自己去选择，这个任务交给了nginx，即服务端去进行。

• IRule

IRule是Ribbon对于负载均衡策略实现的接口， 实现这个接口，就能定义负载均衡策略。

框架中内置了多种默认实现：

我们也可以通过实现这个接口来自定义负载均衡算法。

3. Feign

Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单, 它的使用方法是定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解。Feign也支持可拔插式的编码器和解码器。Spring Cloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。Feign旨在使编写Java Http客户端变得更容易。

Feign集成了Ribbon，引入了Feign的依赖后，就不需要单独再引入Ribbon。

4. Hystrix

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

针对服务时效，可以做的防御措施有：服务限流、超时监控、服务熔断、服务降级。这些都可以由Hystrix来实现。

• 服务降级&超时
• 降级是当我们的某个微服务响应时间过长，或者不可用了，不能把错误信息直接返回出来，或者让他一直卡在那里，所以要准备一个对应的策略（一个方法）当发生这种问题的时候我们直接调用这个方法来快速返回这个请求，不让他一直卡在那 。降级行为是在调用端做的（服务端已经无法响应请求了，因此无法在服务端做）。
• 熔断

熔断，就好像我们生活中的跳闸一样， 比如说你的电路出故障了，为了防止出现大型事故，直接切断了你的电源以免意外继续发生。把这个概念放在我们程序上也是如此， 当一个微服务调用多次出现问题时（默认是10秒内20次当然 这个也能配置），Hystrix就会采取熔断机制，不再继续调用你的方法（会在默认5秒钟内和电器短路一样，5秒钟后会试探性的先关闭熔断机制，但是如果这时候再失败一次{之前是20次} 那么又会重新进行熔断） 而是直接调用降级方法，这样就一定程度上避免了服务雪崩的问题。

• 限流

限流， 就是限制你某个微服务的使用量（可用线程）

Hystrix通过线程池的方式来管理你的微服务调用，他默认是使用一个线程池（大小为10） 管理你的所有微服务，你可以给某个微服务开辟新的线程池。threadPoolKey 就是在线程池唯一标识， hystrix 会拿你这个标识去计数，看线程占用是否超过了， 超过了就会直接降级该次调用。

Feign 默认是支持hystrix的， 但是在Spring - cloud Dalston 版本之后就默认关闭了， 因为不一定业务需求要用的到，所以现在要使用首先得打开他。

5. Zuul

Zuul主要是对请求进行路由和过滤。

其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础.

Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

 注意：Zuul服务最终还是会注册进Eureka

过滤器(filter)是Zuul的核心组件 Zuul大部分功能都是通过过滤器来实现的。 Zuul中定义了4种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期。

PRE：这种过滤器在请求被路由之前调用。可利用这种过滤器实现身份验证、在 集群中选择请求的微服务、记录调试信息等。

ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送请求，并使用 Apache HttpCIient或 Netfilx Ribbon请求微服务 。

POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准 的 HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

ERROR：在其他阶段发生错误时执行该过滤器。

如果要编写一个过滤器，则需继承ZuulFilter类实现其中方法。

Zuul默认是整合了Hystrix和Ribbon的， 提供降级回退。引入了Zuul之后，就不需要再单独引入Hystrix和Ribbon了。

6. HystrixDashbord

Hystrix（注意是单纯的Hystrix） 提供了对于微服务调用状态的监控， 但是，需要结合spring-boot-actuator 模块一起使用。提供了一个可视化的监控界面，方便开发者监控服务状态信息。

7. Spring-Cloud-Config

把所有的微服务配置通过某个平台：比如 github， gitlib 或者其他的git仓库进行集中化管理（当然，也可以放在本地），方便开发者维护配置文件。

8. spring -cloud -sleuth

对于一个大型的微服务架构系统，会有哪些常见问题？

• 如何串联调用链，快速定位问题
• 如何厘清微服务之间的依赖关系
• 如何进行各个服务接口的性能分折
• 如何跟踪业务流的处理

spring Cloud Sleuth为 spring Cloud提供了分布式跟踪的解决方案，它大量借用了Google Dapper、 Twitter Zipkin和 Apache HTrace的设计。

Spring Cloud Sleuth可以追踪10种类型的组件：async、Hystrix，messaging，websocket，rxjava，scheduling，web（Spring MVC Controller，Servlet），webclient（Spring RestTemplate）、Feign、Zuul。

9. Zipkin

sleuth对于分布式链路的跟踪仅仅是一些数据的记录， 这些数据我们人为来读取和处理难免会太麻烦了，所以我们一般吧这种数据上交给Zipkin Server 来统一处理。所以，sleuth一般是整合Zipkin一起使用。