springcloud笔记

springcloud

前序

需要掌握的技术点

springboot+spring+springmvc+mybatis+dubbo+zukker+javaee

springcloud 就是all is one 模块化编程

目前存在的问题

1   1 就是公共的api 网关访问
    2 模块间的通信问题    rpc http
    3 模块管理问题       注册中心 eureka
    4 服务如果挂掉的问题  熔断机制  hystrix

dubbo 专业的rpc通信工程良好的解决企业模块通信（zookeeper 服务注册）

现在新一代的一站式解决问题的框架

Spring Cloud Alibaba 一站式解决问题

api 网关 zuul组件
fegin–httpclinet—http 通信方式，同步阻塞
服务注册发现 eureka
熔断机制：hystrix

总结

api
http rpc
注册与发现
熔断机制

微服务

微服务架构是“新常态”。构建小型，独立且可运行的应用程序可以带来极大的灵活性，并为您的代码增加弹性。Spring Boot的许多专用功能使在大规模生产中轻松构建和运行微服务变得容易。而且请不要忘记，如果没有微服务架构，那么没有完整的微服务架构春云 ‒简化管理并提高容错能力

什么是微服务？

微服务是一种现代化的软件方法，通过该方法，应用程序代码以可管理的小段形式交付，彼此独立。

为什么要建立微服务？

它们的规模小且相对隔离可以带来许多其他好处，例如更容易维护，提高生产率，更大的容错能力，更好的业务调整等等。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bqtoVhqx-1613357874317)(https://spring.io/images/diagram-microservices-88e01c7d34c688cb49556435c130d352.svg)]

3.2 springcloud和springboot关系

springboot专注于快速方便的开发单个个体微服务。
springcloud是关注全局的微服务协调整理治理框架，它将spirngboot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。
springboot可以离开springcloud独立使用，开发项目，但是springcloud不能离开springboot属于依赖关系.
springboot专注于快速、方便的开发单个个体微服务，springc关注全局的服务治理框架

3.3 、Dubbo和springcloud选型

1.分布式+服务治理Dubbo

目前成熟的互联网架构：应用服务化拆分+消息中间件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xKAbH3t7-1613357874321)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20210209132554780.png)]

springcloud版本选型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SJHtjcHe-1613357874322)(C:\Users\hp\Desktop\笔记图片惠存点\屏幕截图 2021-02-09 140822.png)]

eureka服务注册与发现

1.什么是eureka

eureka you rui ka
netflix 在设计eureka时遵循的就是ap原则
eureka是netflix的子模块也是核心模块之一。eureka是一个基于rest的服务，用于定位服务，以实现云端中间层服务发现与故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务注册与发现，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了功能类似于dubbo的注册中心比如zookeeper；

原理讲解
eureka基本架构

springcloud封装了neflix公司开发的eeureka模块来实现服务注册和发现（对比zookeeper）
eureka采用了c-s架构设置，eurekaserver作为服务注册功能的服务器，他是注册中心
而系统中的其他微服务。使用eureka的客户端连接到eurekaserver并维持心跳连接，这样系统的维护人员就可以通过eurekaserver来监控系统中的各个微服务是否正常运行，springcloud的一些其他模块（比如zuul）就可以通过eurekaserver来发现系统中的其他微服务，并执行相关的逻辑；
和dubbo架构相比
eureka包含两个组件 eurekaserver 和 eureka client
eurekaserver提供服务注册，各个节点启动后，会在eurekaserver进行注册，这样eurekaserver中的服务注册表中将会存取所有可用服务节点的信息服务节点的信息可以在界面中直观的看到i
- eureka client是一个java客户端用于简化eurekaserver交互客户端同时也具备一个内置的使用轮询算法的负载均衡器，启动后会向eurekaserver发送心跳（默认30s）如果某个节点没有了心跳 eurekaserver会在服务注册表中移除这个服务节点（默认90s）
三大角色
- eureka server 提供服务的注册于发现。zookeeper
- service provider 将自身服务注册到eureka中从而使消费者方能够找到
- service consumer 服务消费方从eureka中获取注册服务列表从而找到消费服务

eureka 保护机制
一但服务发生崩溃 eureka 不会立即清理 会保存服务的信息
这就是eureka的保护机制

DiscoveryClient 服务发现 查看服务详情
    //注册进来的微服务获取一些消息
    @RequestMapping("/logs")
    public Object discover(){
   
        //获取服务列表清单
        List<String> services = discoveryClient.getServices();
        System.out.println("discover=>service"+services);
        //查看具体的微服务信息
        List<ServiceInstance> instances = discoveryClient.getInstances("SPRINGCLOUD-PROVIDE-DEPT");
        for (ServiceInstance instance : instances) {
   
            System.out.println(instance.getHost()+instance.getPort()+instance.getUri());
        }
        return this.discoveryClient;
    }

CAP 原则

C : 一致性

A : 可用性

P : 一致性

著名的cap理论指出一个分布式系统不可能同时满足cap 由于分区容错性P必须存在所以只能在CA里面做权衡

因此根据CAP原则讲nosql 数据库分成了满足CA原则，满足CP原则和满足 AP原则三大类 CA - 单点集群，满足一致性，可用性，通常在可拓展性上不太强大 CP - 满足一致性，分区容错性的系统，通常性能不是特别的高 AP - 满足可用性，分区容错性，通过对数据一致性要求低一些。所以，分布式系统考虑到集群的拓展，只能选择CP 或者 AP 。

zookeeper 保证的是cp
eureka 保证的是ap

zookeeper保证cp

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down调不可用，也就是说，服务注册功能对可用性的要求高宇一致性。 但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点回重新进行leader选举，问题在于选举leader的时间太长，30~120s且选举期间整个zk集群都是不可用的。这就导致在选举期间注册服务瘫痪，在云部署的环境下，因网络问题使得zk集群失去master节点很大概率会发生的事情。虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用时不能容忍的。
zookeeper的选举过程速度很慢 并且选举过程中所有服务都会停掉也没有eureka的暂时保存功能
zookeeper的性能是有限的 查到的数据也可能是过期数据
zookeeper无法进行有效的权限控制

eureka的ap原则

eureka 看明白了这一点，因此在设计时就先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而eureka客户端再向某个eureka服务端注册时如果发现连接失败，则会自动切换至其他节点。只要有一台eureka server 是ok的，就能保证服务可用(保证服务可用)。只不过查询到的信息可能不是最新的(不保证强一致性)。除此之外，eureka还有一种自我保护机制，上篇中也?说。如果在15分钟内超过85%的节点都没有正常的心跳，那么eureka就认为客户端与注册中心出现了网络故障，此时会出现如下几种情况：
1. eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2. eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中，因此，eureka可以很好的应对网络故障导致部分节点失去联系的情况而不会像zk那样使整个注册服务瘫痪。

ribbon负载均衡

LB既负载均衡在微服务集群常见的应用
负载均衡简单的说就是将请求平摊实现高可用
常见的负载均衡有 nginx lvs等
dubbo springcloud 中提供了负载均衡 springcloud的负载均衡算法可以自定义
负载均衡简单分类：
- 集中式LB
- 既服务器的消费方和提供之间使用独立的lb设施如nginx 反向代理服务器由该设施通过某种策略将访问请求合理转发
- 进程式lb
- 将lb集成到消费方，消费者从注册中心获取那些地址可用然后在从地址中选出一个合适的服务器
- ribbon就属于进程式lb 它只是一个类库集成于消费方进程消费方通过它来获取到服务提供方的地址！！！

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2020.0.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>