skeely1234 / springcloud

SpringCloud

微服务是什么? 每次都是一次独立的进程 提倡将单一的应用程序划分成一组小的服务 专业的事情交给专业的人做,尽量降低耦合度 各个模块/服务,各自独立出来,分灶吃饭 各自微小的一个进程,让专业的人专业的模块,来做专业的事情,独自部署 1.拆分 2.各自独立的进程 3.拥有自己独立的数据库

dubbo基于rpc远程调用 springcloud基于rest

微服务架构 eclipse工具里面用maven开发的一个个独立的小moudle,它具体是使用 springboot开发的一个小模块,专业的事情交给专业的模块来做,一个 模块就做这一件事情 强调的是一个个的个体,每一个个体完成一个具体的任务或者功能

微服务的优缺点: 微服务只是业务逻辑代码,不会和html,css或其他界面组件混合

微服务的技术栈:多种技术的结合体

springcloud=分布式微服务架构下的一站式解决方案,是各个微服务架构落地技术的集合体,俗称微服务全家桶

springboot和springcloud的关系 1.区别: boot:微观,是一个个的微服务,是医院里一个个的科室,不依赖于springcloud, cloud:宏观,微服务的集合体,是把一个个科室组合起来的医院,依赖于springboot boot专注于快速方便的开发单个微服务个体,cloud关注全局的服务治理框架

springcloud与dubbo的区别 1.dubbo rpc远程调用通信 cloud采用的是基于http的rest方式 2.品牌机cloud 组装机dubbo 3.社区支持与更新力度

mybatis参数 parameterType:传入的参数 resultType:传出的参数

服务注册与发现 eureka: 就像刚进一栋腾讯大楼的导航图,上面写着几楼是开发部几楼是测试部什么,这个开发部和测试部我们称为微服务, 这个花名册我们就称为eureka c-s架构设计,有服务端eureka service主管eureka的服务与发现 有客户端(eureka client)

eureka自我保护 一句话：某时刻某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存

在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着 Application.yml文件配置技巧: #配置后面最好保留一个空格防止配置读不出来

服务发现: 拿到已注册的服务列表

一、首先介绍下CAP RDBMS(mysql/oracle/sqlServer) -----> ACID NOSQL(redis/mongdb) ----> CAP
ACID：A（atomicity）原子性 C（Consistency）一致性 I（Isolation）独立性 D（Durability）持久性 CAP： C（Consistency）强一致性 A（Availability） 可用性
P（Partition tolerance）分区容错性 CAP的3进2： 最多只能同时较好的满足两个。 CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和 分区容错性这三个需求。 因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则 和满足AP原则三大类； CA-单点集群，满足一致性，可用性的系统，通常在课扩展性上不太强大。 CP-满足一致性，分区容错性的系统，通常性能不是特别高。 AP-满足可用性，分区容错性的系统，通常可能对一致性要求低一些。

    CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络

硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须要实现的。 所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

二、Eureka 和 Zookeeper区别？ 著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。 因此 Zookeeper保证的是CP, Eureka则是AP。

1.Eureka是遵守A(高可用)P(分区容错性)原则 Zookeeper是遵守C(一致性)P(分区容错性)原则
Zookeeper保证CP原则： 1.1当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息， 但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求高于一致性。 但是zk会出现这一种情况，当master节点因为网络故障与其他节点失去联系时，剩余注册 功能就会重新进行leader选举看。问题在于，选举leader的时间太长，30~120s，且选举期间 整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题 使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的 选举时间导致的注册长期不可用是不能容忍的。 1.2Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等 的，几个节点挂掉不会影响正常节点的工作，剩余节点依然可以提供注册和查询服务。 而Eureka的客户端在向某个Eureka注册或者如果发现链接失败时，则会自动切换至其他节点， 只要有一台Eureka还在，就能保证注册服务可用（保证可用），只不过查到的信息可能不是 最新的（不保证一致性）。除此以外，Eureka还有一种自我保护机制，如果在15分钟内超过85% 的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现 一下几种情况： （1）Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务 （2）Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 （保证当前节点依然可用） （3）当网络稳定时，当前实例新的注册信息会被同步到其他节点中 因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

双十一选择a(高可用)p(分区容错性)分区容错性是在分布式系统中必须要保证的

Ribbon:负载均衡(lb) 客户端 进程内lb

Feign: 只需创建一个接口 然后在上面添加注解即可

Feign集成了Ribbon 利用Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡。而与Ribbon不同的是，通过feign只需要定义服务绑定接口且以声明式的方法，优雅而简单的实现了服务调用

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

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

服务熔断 熔断机制是应对雪崩效应的一种微服务链路保护机制。 当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。

备注：熔断模式：这种模式主要是参考电路熔断，如果一条线路电压过高，保险丝会熔断，防止火灾。放到我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。 备注：限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

服务降级: 服务降级处理是在客户端实现完成的，与服务端没有关系

整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。

//一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法 @HystrixCommand(fallbackMethod = "processHystrix_Get") 不想让他一个方法对应一个HystrixCommand的异常处理方法,要实现解耦,用我们spring面向切面的织入和异常通知的**,避免代码膨胀,业务逻辑和异常处理分离,现在我们不用一个方法对应一个异常处理方法了,在面向接口的业务逻辑增删改查处理类上,加上@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory=DeptClientServiceFallbackFactory.class)注解 表明此类所有方法被监控,发生异常会跳转到异常处理类处理

此时服务端provider已经down了，但是我们做了服务降级处理，让客户端在服务端不可用时也会获得提示信息而不会挂起耗死服务器

服务熔断: 一般是某个服务器故障或者异常引起,类似生活中的保险丝,当某个异常被触发,直接熔断整个服务,而不是一直等到此服务超时

服务监控hystrixDashboard:

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

Zuul包含了对请求的路由和过滤两个最主要的功能： 其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础.Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

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

提供=代理+路由+过滤三大功能