SpringCloud

什么是微服务呢?

微服务架构风格就是一种把一个单一的应用程序开发成为一组小型服务的方法，每个服务都运行在自己的进程当中，服务之间通都是信采用的轻量级通信机制。这些服务围绕着业务能力构建并且可以通过全自动部署机制去独立部署。这些服务是共用一个最小型的集中式的管理的，服务可运用不同的语言去开发，也可以使用不同的数据存储技术。所以微服务架构应该具备以下几个特性：

每个微服务都可独立运行在自己的进程里。
一系列独立运行的微服务共同地构建起了整个系统。
每个服务都为独立的业务开发，一个微服务可能只关注某个特定的功能，例如订单管理，用户管理等等。
微服务之间会通过一些轻量的通信机制去进行通信，例如通过RESTful API进行接口调用。
可以使用不同的语言与数据的存储技术。
全自动部署机制。

优点：

第一个，易于开发和维护。一般来说一个微服务只会关注一个特定的业务功能，所以它业务清晰，代码量会比较少。
第二个，单个微服务启动较快。因为单个微服务代码量比较少，所以启动会比较快。
第三个，局部修改容易去部署。单体应用一旦有修改，就得重新部署整个应用，微服务就很好的解决了这样的问题。
第四个，技术栈不受限。在微服务架构里面，我们可以结合项目业务及团队的特点，合理地去选择合适的技术栈。
第五个，按需伸缩。可以根据具体需求，去实现细粒度的扩展。

缺点：

同样的，微服务架构所面临的挑战也是存在的，比如说，运维要求高。如果有更多的服务就意味着更多的运维投入。分布式本身固有的复杂性。由于使用微服务架构是分布式系统，那么对于一个分布式系统来说，系统容错，网络延迟，分布式事务等等，都会带来严峻的挑战。接口调整成本较高。微服务之间是通过接口进行通信的。如果说修改某一个微服务的API，那么可能所有使用了该接口的微服务都需要做适用的调整。重复的劳动。因为很多服务可能都会使用到相同的功能，然而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而就导致了代码的重复。

SpringCloud架构图

Chandler.png

SpringCloud特点

以下为 Spring Cloud 的核心特性：
分布式/版本化配置（Config）
服务注册和发现（Eureka）
路由（Zuul/Gateway）
服务和服务之间的调用（Feign）
负载均衡（Ribbon）
断路器（Hystrix）
分布式消息传递（Bus）

1.Eureka
1）、Eureka服务端：也称服务注册中心，同其他服务注册中心一样，支持高可用配置。如果Eureka以集群模式部署，当集群中有分片出现故障时，那么Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中其他分片会把它们的状态再次同步回来
2）、Eureka Server的高可用实际上就是将自己作为服务向其他注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用效果

2.Ribbon
Ribbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到服务均衡的作用。当Ribbon和Eureka联合使用时，Ribbon的服务实例清单RibbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来去定服务端是否已经启动
在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心（比如Eureka）。在客户端负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤需要与服务注册中心配合完成

3.Fegin
Fegin的关键机制是使用了动态代理，Fegin是和Ribbon以及Eureka紧密协作的
1）、首先Ribbon会从Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口
2）、然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器
3）、Fegin就会针对这台机器，构造并发起请求

4.Hystrix
在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。为了解决这样的问题，产生了断路器等一系列的服务保护机制
在分布式架构中，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延
Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能

5.Zuul
Spring Cloud Zuul通过与Spring Cloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息
对于路由规则的维护，Zuul默认会将通过以服务名作为ContextPath的方式来创建路由映射
Zuul提供了一套过滤器机制，可以支持在API网关无附上进行统一调用来对微服务接口做前置过滤，已实现对微服务接口的拦截和校验

小结
Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务