一、微服务设计原则

单一职责原则
服务自治原则:服务是实体,它们独立地配置、更新和管理
轻量级通信原则
接口明确原则:每个服务的对外接口应该明确定义，并尽量保持不变。

参考网站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，同时也要负责各个节点的健康监测。

其它信息

其它信息包括它们之间的通信方式，还有一些协议信息，算法。它们是用于保证节点之间的数据同步，实时性要求等等一系列集群问题的解决。这些有兴趣的自己看看官方文档。

Spring Cloud和常用组件Consul+Fegin+zuul总结相关推荐

Spring Cloud（二）Consul 服务治理实现
Spring Cloud Consul 项目是针对Consul的服务治理实现.Consul是一个分布式高可用的系统,具有分布式.高可用.高扩展性. Consul 简介 Consul 是 HashiCo ...
Spring Cloud（二） Consul 服务治理实现
Spring Cloud Consul 项目是针对Consul的服务治理实现.Consul是一个分布式高可用的系统,具有分布式.高可用.高扩展性. Consul 简介 Consul 是 HashiCo ...
Spring Cloud浅谈个人尝鲜------Zuul 服务网关（五）
Spring Cloud浅谈个人尝鲜------Zuul 服务网关(五) 前面几篇文章我们学习了Eureka用于服务的注册于发现,Feign支持服务的调用以及均衡负载,Hystrix处理服务的熔断防止 ...
Spring Cloud（六）服务网关 zuul 快速入门
服务网关是微服务架构中一个不可或缺的部分.通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由.均衡负载功能之外,它还具备了权限控制等功能.Spring Cloud Netflix中 ...
SpringCloud微服务架构,Spring Cloud 服务治理(Eureka,Consul,Nacos),Ribbon 客户端负载均衡,RestTemplate与OpenFeign实现远程调用
什么是SpringCloud 微服务架构 • "微服务"一词源于 Martin Fowler的名为 Microservices的博文,可以在他的官方博客上找到 http://mar ...
Spring Cloud Netflix五大组件简介
微服务与微服务架构微服务的优缺点优点缺点 Dubbo与Spring Cloud Spring Cloud Netflix Eureka Eureka的自我保护机制 Eureka和ZooKeepe ...
spring cloud 入门系列六：使用Zuul 实现API网关服务
通过前面几次的分享,我们了解了微服务架构的几个核心设施,通过这些组件我们可以搭建简单的微服务架构系统.比如通过Spring Cloud Eureka搭建高可用的服务注册中心并实现服务的注册和发现: 通 ...
Spring Cloud Alibaba 实战（五）Zuul篇
网关:主要作用认证和鉴权.最合适的解决办法是:网关解决认证问题, 子系统解决授权问题. 1. Zuul 简介 Zuul 微服务网关是为 Spring Cloud Netflix 提供动态路由,监控,弹 ...
Spring Cloud（七）服务网关 Zuul Filter 使用
上一篇文章中,讲了Zuul 转发,动态路由,负载均衡,等等一些Zuul 的特性,这个一篇文章,讲Zuul Filter 使用,关于网关的作用,这里就不再次赘述了,重点是zuul的Filter ,我们可 ...

Spring Cloud和常用组件Consul+Fegin+zuul总结

一、微服务设计原则

1.1、什么是微服务（Microservice）