Spring Cloud和常用组件Consul+Fegin+zuul总结
一、微服务设计原则
- 单一职责原则
- 服务自治原则:服务是实体,它们独立地配置、更新和管理
- 轻量级通信原则
- 接口明确原则:每个服务的对外接口应该明确定义，并尽量保持不变。
参考网站https://blog.csdn.net/qq_27384769/article/details/79062290
1.1、什么是微服务（Microservice）
微服务英文名称Microservice，Microservice架构模式就是将整个Web应用组织为一系列小的Web服务。这些小的Web服务可以独立地编译及部署，并通过各自暴露的API接口相互通讯。它们彼此相互协作，作为一个整体为用户提供功能，却可以独立地进行扩。
微服务架构需要的功能或使用场景
1：我们把整个系统根据业务拆分成几个子系统。
2：每个子系统可以部署多个应用，多个应用之间使用负载均衡。
3：需要一个服务注册中心，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。
4：所有的客户端都通过同一个网关地址访问后台的服务，通过路由配置，网关来判断一个URL请求由哪个服务处理。请求转发到服务上的时候也使用负载均衡。
5：服务之间有时候也需要相互访问。例如有一个用户模块，其他服务在处理一些业务的时候，要获取用户服务的用户数据。
6：需要一个断路器，及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪。
7：还需要一个监控功能，监控每个服务调用花费的时间等。
二、Spring Cloud （常用组件总结）
升级到 Spring boot 2.0.0，引入 Swagger 生成 api 文档。
2.1 Feign
@FeignClient 对内部服务之前提供调用
在微服务的开发中，我们还会碰到很多微服务之间内部相互调用的情况，特别是对数据服务的调用。在Spring Cloud中，有两种方式可以，一种是使用Rest(RestTemplate)+Ribbon，另一种是使用Feign框架。
如果具体的使用Ribbon调用服务的话，你就可以感受到使用Ribbon的方式还是有一些复杂，因此Spring Cloud Feign应运而生。
Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。
比如：访问feign服务的hi接口，出现访问hello和hello2的信息循环出现，因为hi接口内部调用的hello服务。
微服务之间的调用本质还是http请求，如果对于每个请求都需要写请求代码，增加请求参数，同时对请求结果做处理，就会存在大量重复工作，而feign非常优雅的帮助我们解决了这个问题，只需要定义一个interface，fegin就知道http请求的时候参数应该如何设置
本质上就是Ribbon+Hystrix
- feign也集成了ribbon，只要在微服务中依赖了ribbon，feign默认会使用ribbon定义的负载均衡策略。
- Feign默认集成了hystrix。
运用举例1： 调用指定的某台机器联调需配置URL
@FeignClient(name = "${feign.application.fatp-lm-service.name}", url = "http://10.126.0.174:8099" , fallbackFactory = FatpLMFeign.LcrmScFeignFallbackFactory.class)
2.2 Spring boot Admin（监控）
spring boot admin为spring boot应用提供了整合的视图，应用的详情视图提供了应用本身及运行时环境（OS和JVM）运维比较关心的数据，应用的运行时信息，log输出，metrics统计，environment和logging level实时调整，thread线程运行时状态，trace，audit和Hystrix
2.3 zuul（路由网关）对外提供调用入口
Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分，比如／api/user转发到到user服务，/api/shop转发到到shop服务。zuul默认实现了负载均衡的功能。
Zuul：类似于网关，反向代理。为外部请求提供统一入口。
由于Spring Cloud为服务治理做了一层抽象接口，所以在Spring Cloud应用中可以支持多种不同的服务治理框架，比如：Netflix Eureka、Consul、Zookeeper
2.4 Consul/Eureka：服务发现 （根据情况选择一个）
2.5 zuul（路由网关）对外提供调用入口
spring cloud zuul 服务路由、请求过滤转发
spring cloud zuul是netflix提供的一个组件，功能类似于nginx ，提供如下功能：
- 动态路由
- 监控
- 安全
- 认证鉴权
- 压力测试
- 金丝雀测试
- 审查
- 服务迁移
- 负载剪裁
- 静态应答处理
通过服务路由的功能，我们在对外提供服务的时候，只需要通过暴露Zuul中配置的调用地址就可以让调用方统一的来访问我们的服务，而不需要了解具体提供服务的主机信息了。
2.6 Spring Cloud Ribbon 客户端负载均衡组件
服务发现以后，每个service在本地知道自己要调用的服务有多少台机器，机器的ip是什么，端口号是多少，那这个service在本地需要有一个负载均衡策略，为每一次请求选择一台目标机器进行调用，而ribbon做的就是负载均衡策略的选择。
2.7 Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式
配置管理工具包，让你可以把配置放到远程服务器，几种化管理集群配置，目前支持本地存储，Git以及Subversion
2.8 hystrix
- 断路器，类似于物理电路图中的断路器。
- 正常情况下，当整个服务环境中，某一个服务提供方由于网络原因、数据库原因或者性能原因等，造成响应很慢的话，调用方就有可能短时间内累计大量的请求线程，最终造成调用方down，甚至整个系统崩溃。而加入hystrix之后，如果hystrix发现某个服务的某台机器调用非常缓慢或者多次调用失败，就会短时间内把这条路断掉，所有的请求都不会再发到这台机器上。
- 如果某个服务所有的机器都挂了，hystrix会迅速失败，马上返回，保证被调用方不会有大量的线程堆积。
- Feign默认集成了hystrix。
- 上面有提到，使用eureka时，当一个服务提供方挂掉以后，服务订阅者最长可能30s以后才知道，那这30s就会出现大量的调用失败。如果在系统里面集成了hystrix，就会马上把挂掉的这台服务提供方断路掉，让请求不再转发到这台机器上，大量减少调用失败。
- hystrix执行断路操作以后，并不表示这条路就永远断了，而是会一定时间间隔内缓慢尝试去请求这条路，如果能请求成功，断路就会恢复。
- 有一点需要注意的是hystrix在做断路时，默认所有的调用请求都会放在一个的线程池中进行，线程池的作用很明显，有隔离性。比如gateway，集成了5个子业务系统，可能其中一个系统的调用量非常大，而另外四个系统的调用很小，如果没有线程池的话，显然第一个系统的大量调用会影响到后面四个系统的调用性能。hystrix的线程池和java标准线程池一样，可以配置一些参数：coreSize、maximumSize、maxQueueSize、queueSizeRejectionThreshold、allowMaximumSizeToDivergeFromCoreSize、keepAliveTimeMinutes等，如果某一个子系统的调用量突然激增，超过了线程池的容量，也会迅速失败，直接返回，起到降级和保护系统本身的作用。当然hystrix也支持非线程池的方式，在本地请求线程中做调用，即semaphore模式，官方不建议，除非系统qps真的很大。
2.9 Dashboard，Hystrix仪表盘
监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。
三、常用组件详细介绍
3.1、 Feign
Feign在默认情况下使用的是JDK原生的URLConnection发送HTTP请求，没有连接池，但是对每个地址会保持一个长连接，即利用HTTP的persistence connection
3.2 、Consul 和 Eureka
Consul 和 Eureka 都是用来解决服务发现（就是类似DNS服务）。
Eureka 在应用主类中通过加上@EnableDiscoveryClient，该注解能激活Eureka中的DiscoveryClient。（微服务中说加上@EnableEurekaClient也可以）；
@EnableDiscoveryClient //发现服务和注册服务
@EnableHystrix //断路器，对服务的延迟和容错进行兜底处理
- 最大的区别是Eureka保证AP, Consul为CP。
- 一致性(Consistency)
- 可用性(Availability)
- 分区容忍性(Partition tolerance)
Consul强一致性(C)带来的是：
- 服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
- Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性：
- 服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
- 当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。
在业界，一般有两种微服务的实践方法：基于dubbo的微服务架构、基于Spring Cloud的微服务架构。从概念上来讲，Dubbo和Spring Cloud并不能放在一起对比，
因为Dubbo仅仅是一个RPC框架，实现Java程序的远程调用，实施服务化的中间件则需要自己开发；而Spring Cloud则是实施微服务的一系列套件，
包括：服务注册与发现、断路器、服务状态监控、配置管理、智能路由、一次性令牌、全局锁、分布式会话管理、集群状态管理等。
服务注册
Restful基于Http协议，良好的跨平台 （dubbo是基于RPC，RPC都是基于TCP进行研发的协议）
熔断的原理
3.3Consul界面 删除无效的服务或多实例下的无效节点
原因：停掉服务修改服务名或者端口之后，重启服务会发现Consul界面上面之前的服务也是passing正常状态。
1.不多解释，直接按下图，找到服务的服务id,在浏览器中将下面的地址中的server ip改成你相应的ip,后面加上server id，执行就ok了，比较简单就不多讲述，比起网上写的要简单好用多了
删除无效服务：（注意用put方式请求，不是post或者get方式，postman等工具可以选择put方式请求）
http://server_ip:8500/v1/agent/service/deregister/plms-repay-service-8199-10-126-2-68-8199
plms-repay-service-8199-10-126-2-68-8199 为server id不是服务名称 是ID
删除无效节点：
http://server_ip:8500/v1/agent/force-leave/4b36b27317a0
4b36b27317a0 为节点名（也就是容器id)
总结：服务实例只能在注册的Agent上进行注销
3.4 consul 特性
做服务发现的框架常用的有
- zookeeper
- eureka
- etcd
- consul
那么consul是啥？consul就是提供服务发现的工具。然后下面是简单的介绍：
consul是分布式的、高可用、横向扩展的。consul提供的一些关键特性：
- service discovery：consul通过DNS或者HTTP接口使服务注册和服务发现变的很容易，一些外部服务，例如saas提供的也可以一样注册。
- health checking：健康检测使consul可以快速的告警在集群中的操作。和服务发现的集成，可以防止服务转发到故障的服务上面。
- key/value storage：一个用来存储动态配置的系统。提供简单的HTTP接口，可以在任何地方操作。
- multi-datacenter：无需复杂的配置，即可支持任意数量的区域。
我们从上图可以看出consul的集群是由N个SERVER，加上M个CLIENT组成的。而不管是SERVER还是CLIENT，都是consul的一个节点，所有的服务都可以注册到这些节点上，正是通过这些节点实现服务注册信息的共享。除了这两个，还有一些小细节，一一简单介绍。
- CLIENT
CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。
- SERVER
SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。
- SERVER-LEADER
中间那个SERVER下面有LEADER的字眼，表明这个SERVER是它们的老大，它和其它SERVER不一样的一点是，它需要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。
- 其它信息
其它信息包括它们之间的通信方式，还有一些协议信息，算法。它们是用于保证节点之间的数据同步，实时性要求等等一系列集群问题的解决。这些有兴趣的自己看看官方文档。