微服务与SpringCloud_微服务架构和springcloud

微服务架构与SpringCloud

什么是微服务

SpringCloud

服务注册与发现(eureka),服务调用,服务熔断,负载均衡,服务降级,服务消息队列,配置中心管理,服务网关,服务监控,全链路追踪,自动化构建部署,服务定时任务调度操作

分布式微服务架构的一站式解决方案,是多种微服务架构落地技术的集合体,称为微服务全家桶

boot和colud的版本选型

https://spring.io/projects/spring-cloud#overview

https://spring.io/projects/spring-cloud#overview

Cloud升级

服务注册中心

(1)Eureka(停止更新,不停用)

(2)Zookeeper

(3)Consul(go语言写的,不建议使用)

(4)Nacos(几乎可以完美的替换Eureka)

服务调用

(1)Ribbon(半生不熟,进入维护状态,停止更新)

(2)LoadBalanc(会逐渐慢慢取代Ribbon,但也不成熟)

服务调用2

(1)Feign(挂了)

(2)OpenFeign

服务降级

(1)Hystrix(官网不建议使用,停更,国内使用的多)

(2)resilience4j(Java)(官网推荐,国内使用少)

(3)sentienl(强烈推荐)

服务网关

(1)Zuul(停用)

(2)Zuul2(没有出来,内部吵架,员工跳槽)

(3)gateWay(目前的主流,spring极度推荐的网关)

服务配置

(1)Config(不再使用)

(2)Nacos(主流)

(3)apolo(也是主流,但是不推荐)

服务总线

(1)Bus(停用)

(2)Nacos(主流)

订单支付模块的微服务

总父工程

POM

project

model

dependencyManagement和dependencies的区别

dependencyManagement元素能让所有在子项目中引用一个依赖而不显示的列出版本号.maven会沿着父子层次向上走,直到找到一个拥有dependencyManagement元素的项目,然后它就会使用dependencyManagement元素中指定的版本号.只是声明依赖,并不实现引入依赖,因此子项目需要显示的声明需要用额依赖.

如果不再子项目中声明依赖,是不会从父项目中继承下来的;只有在子项目中写入了该依赖项,并且没有指定具体版本,才会从父项目中继承该项,并且version和scope都读取字父pom

dependencies

微服务模块

1.健modul

2.改pom

3.写YML

4.主启动

5.业务类

自动热部署Devtools

httpClient

restTemplate

Eureka服务注册与发现

Eureka基础知识

什么是服务治理

在传统的rpc远程调用框架中,管理每个服务与服务之间依赖关系比较复杂,管理比较复杂,所以需要使用服务治理,管理服务与服务之间依赖关系,可以实现服务调用,负载均衡,容错等,实现服务发现与注册.

什么是服务注册

Eureka采用了CS的设计架构,Eureka Server作为服务注册功能的服务器,它是服务注册中心,而系统中的其他微服务,使用Eureka的客户端链接到Eureka Server并维持心跳连接,这样系统的维护人员就可通过Eureka Server来监控系统中各个微服务是否正常运行.

在服务注册与发现中,有一个注册中心,当服务器启动的时候,会把当前自己服务器的信息,比如 服务地址通讯地址等以别名方式注册到注册中心上,另一方(消费者|服务提供者),以该别名的方式区注册中心上获取到实际的服务通讯地址,然后再实现本地RPC调用RPC远程调用框架核心设计思想:在于注册中心,因为使用注册中心管理每个服务与服务之间的一个依赖关系(服务治理概念),在任何RPC远程框架中,都会有一个注册中心(存放服务地址相关信息(接口地址))

Eureka包含两个组件:Eureka Server和Eureka Client

Eureka Server提供服务注册服务

各个微服务结点通过配置启动后,会在EurekaServer中进行注册,这样EurekaServer中的服务注册表中将会存储所有可用服务结点的信息,服务结点的信息可以在界面中直观看到.

Eureka Client通过注册中心进行访问

是一java客户端,用于简化Eureka Server的交互,客户端同时也具备一个内置的,使用轮询(round-robin)负载算法的负载均衡器.在应用启动后,将会向Eureka Server发送心跳(默认周期为30秒).如果Eureka Server在多个心跳周期内没有接受到某个结点的心跳,Eureka Server将会从服务注册表中把这个服务结点移除(默认为90秒).

单机Eureka构建步骤

集群Eureka构建步骤

服务注册:将服务信息注册进注册中心.

服务发现,从注册中心上获取服务信息实质;存key服务名取value调用地址.

1.先启动eureka注册中心

2.启动服务提供者payment支付服务

3.支付服务启动后会将自身信息(比如服务地址以别名方式注册进eureka)

4.消费者order服务再需要调用接口时,使用服务别名去注册中心获取实际的RPC远程调用地址.

5.消费者获得调用地址后,底层实际是利用httpClient技术实现远程调用.

6.消费者获得服务地址后会缓存在本地JVM内存中,默认每间隔30秒更新一次服务调用地址.

微服务RPC远程服务调用最核心的是什么

高可用,试想你的注册只有一个only one,它出故障了那就呵呵了,会导致整个为服务环境不可用.所以,解决办法:搭建Eureka注册中心集群,实现负载均衡+故障容错

actuator微服务信息完善

服务发现Discovery

对于注册进eureka里面的微服务,可以通过服务发现来获得该服务的信息.

Eureka自我保护

将会尝试保护其服务注册表中的信息,

某时刻某一个微服务不可用了,Eureka不会立刻清理,依旧会对该微服务的信息进行保存

为什么会产生Eureka自我保护机制?

为了防止EurekaClient可以正常运行,但是与EurekaServer网络不通的情况下,EurekaServer不会立刻将EurekaClient服务剔除.

什么是自我保护模式

默认情况下,如果EurekaServer在一定时间内没有接受到某个微服务实例的心跳,EurekaServer将会注销该实例(默认为90秒).但是当网络分区故障发生(延时,卡顿,拥挤)时,微服务与EurekaServer之间无法正常通信,以上行为可能变得非常危险了-因为微服务本身是健康的,此时本不应该注销这个微服务.Eureka通过"自我保护模式"来解决这个问题-当EurekaServer结点在短时间内丢失过多客户端时(可能发生了网络分区故障),那么这个结点就会进入自我保护模式.

属于CAP里面的AP分支

如何禁止自我保护

单点故障

Zookeeper服务注册与发现

配置稳健

tickTime心跳默认2000毫秒

initLimit=10 10*2s l和f通讯的时长

syncLimit=5 5*2s 集群正常启动后 l和f通讯的时长

clientPort=2181 客户端连接端口

Zookeeper(保持着最终一致性)

dubbo注册中心和配置中心

springcloud注册中心

elastic-job注册中心

solr管理集群

kafka管理集群

Curator分布式锁

Tinyld分布式id

seata配置中心

大数据领域

SpringCloud整合Zookeeper代替Eureka

1.Zookeeper原子广播协议(Zab)底层原理详解

2.Zab&Raft&Paxos的算法过程和异同点分析

3.快速领导者选举算法底层工作流程分析

4.过半机制与两阶段提交底层核心源码详解

5.云环境下Zookeeper集群会不会出现脑裂

6.高性能Zookeeper&Redis分布式锁原理分析

两个数据库为一个集群.用户将数据库A中的数据改为value=2,用户然后通过数据库B来读取value

强一致性:分布式锁

弱一致性:用户读取value可能永远读到的老数据,有可能不一致,

最终一致性:我在处理读取vlaue的时候,返回的是还是1,用户会隔一段时间在读取value是2.

Zookeeper是一个开源的分布式的,为分布式应用提供协调服务的Apache项目

Zookeeper从设计模式角度来理解,是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册得到那些观察者作出相应的反应.

1.服务端启动时去注册信息(创建的都是临时结点).

2.获取到当前在线服务器列表,并注册监听.

3.服务器结点下线

4.服务器结点下线事件通知

5.process(){

重新获取服务器列表,并注册监听

}

Zookeeper=文件系统+通知机制

文件系统:Zookeeper中存放了一些数据

通知机制:Zookeeper上的结点变化,就会通知客户端

Zookeeper特点:

(1)Zookeeper:一个领导者,多个跟随者.

(2)集群中只要有半数以上结点存活,Zookeeper集群就能正常服务.

(3)全局数据一致,每个server保存一份相同的数据副本,Client无论连接到那个Server,数据都是一致的.

(4)更新请求顺序进行,来自同一个Client的更新请求按器发送顺序执行.

(5)数据更新原子性,一次数据更新要么成功要么失败

(6)实时性,在一定时间范围内,Client能读到最新的数据

Zookeeper数据结构

Zookeeper数据模型的结构与Unix文件系统很类似,整体上可以看做一棵树,每个结点称作一个ZNode.每一个ZNode默认能够存储1MB的数据,每个ZNode都可以通过其路径唯一标识,

应用场景

提供的服务

统一命名服务:统一域名下有多个Ip地址

统一配置管理:

1.分布式环境下,配置文件同步非常常见

(1)一般要求一个集群中,所有结点的配置信息时一致的,比如kafka集群,

(2)对配置文件修改后,希望能够快速同步到各个结点上.

2.配置管理可交由Zookeeper实现.

(1)可将