原文: https://martinfowler.com/articles/microservices.html
可能有的人觉得官方的话太过生涩,我们从技术维度来理解下:
目前成熟的互联网架构: 应用服务化拆分+消息中间件
最大区别: SpringCloud 抛弃了 Dubbo的RPC通信,采用的是基于HTTP的REST方式。
严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了.上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约, 不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适。
官网: https://spring.io/projects/spring-cloud#overview
学习参考书:
大版本对应
Spring Boot | Spring Cloud |
---|---|
1.2.x | Angel版本 |
1.3.x | Brixton版本 |
1.4.x stripes | Camden版本 |
1.5.x | Dalston版本、Edgware版本 |
2.0.x | Finchley版本 |
2.1.x | Greenwich.SR2 |
在实际开发过程中,我们需要更详细的版本对应(部分)
SpringCloud版本 | SpringBoot版本 |
---|---|
2021.0.1-SNAPSHOT | Spring Boot >=2.6.4-SNAPSHOT and <2.7.0-M1 |
2021.0.0 | Spring Boot >=2.6.1 and <2.6.4-SNAPSHOT |
2021.0.0-RC1 | Spring Boot >=2.6.0-RC1 and <2.6.1 |
2021.0.0-M3 | Spring Boot >=2.6.0-M3 and <2.6.0-RC1 |
2021.0.0-M1 | Spring Boot >=2.6.0-M1 and <2.6.0-M3 |
2020.0.5 | Spring Boot >=2.4.0.M1 and <2.6.0-M1 |
Hoxton.SR12 | Spring Boot >=2.2.0.RELEASE and <2.4.0.M1 |
Hoxton.BUILD-SNAPSHOT | Spring Boot >=2.2.0.BUILD-SNAPSHOT |
Hoxton.M2 | Spring Boot >=2.2.0.M4 and <=2.2.0.M5 |
Greenwich.BUILD-SNAPSHO | Spring Boot >=2.1.9.BUILD-SNAPSHOT and <2.2.0.M4 |
Greenwich.SR2 | Spring Boot >=2.1.0.RELEASE and <2.1.9.BUILD-SNAPSHOT |
Greenwich.M1 | Spring Boot >=2.1.0.M3 and <2.1.0.RELEASE |
Finchley.BUILD-SNAPSHOT | Spring Boot >=2.0.999.BUILD-SNAPSHOT and <2.1.0.M3 |
Finchley.SR4 | Spring Boot >=2.0.3.RELEASE and <2.0.999.BUILD-SNAPSHOT |
Finchley.RC2 | Spring Boot >=2.0.2.RELEASE and <2.0.3.RELEASE |
Finchley.RC1 | Spring Boot >=2.0.1.RELEASE and <2.0.2.RELEASE |
Finchley.M9 | Spring Boot >=2.0.0.RELEASE and <=2.0.0.RELEASE |
Finchley.M7 | Spring Boot >=2.0.0.RC2 and <=2.0.0.RC2 |
目前我使用的版本是:SpringCloud Hoxton.SR12和 Springboot 2.3.4.RELEASE
pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0modelVersion>
<groupId>com.xzgroupId>
<artifactId>springcloudartifactId>
<version>1.0-SNAPSHOTversion>
<properties>
<maven.compiler.source>8maven.compiler.source>
<maven.compiler.target>8maven.compiler.target>
<project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
<maven.compiler.source>1.8maven.compiler.source>
<maven.compiler.data>1.8maven.compiler.data>
<junit.version>4.12junit.version>
<log4j.version>1.2.17log4j.version>
<lombok.version>1.18.22lombok.version>
properties>
<packaging>pompackaging>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-dependenciesartifactId>
<version>Hoxton.SR12version>
<type>pomtype>
<scope>importscope>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-dependenciesartifactId>
<version>2.3.4.RELEASEversion>
<type>pomtype>
<scope>importscope>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starterartifactId>
<version>2.3.4.RELEASEversion>
dependency>
<dependency>
<groupId>org.mybatis.spring.bootgroupId>
<artifactId>mybatis-spring-boot-starterartifactId>
<version>2.2.2version>
dependency>
<dependency>
<groupId>mysqlgroupId>
<artifactId>mysql-connector-javaartifactId>
<version>5.1.47version>
dependency>
<dependency>
<groupId>com.alibabagroupId>
<artifactId>druidartifactId>
<version>1.2.8version>
dependency>
<dependency>
<groupId>ch.qos.logbackgroupId>
<artifactId>logback-coreartifactId>
<version>1.2.11version>
dependency>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>${junit.version}version>
dependency>
<dependency>
<groupId>log4jgroupId>
<artifactId>log4jartifactId>
<version>${log4j.version}version>
dependency>
<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<version>${lombok.version}version>
dependency>
dependencies>
dependencyManagement>
project>
可以视情况导入资源导入问题的配置:
<build>
<resources>
<resource>
<directory>src/main/resourcesdirectory>
<includes>
<include>**/*.propertiesinclude>
<include>**/*.xmlinclude>
includes>
<filtering>falsefiltering>
resource>
<resource>
<directory>src/main/javadirectory>
<includes>
<include>**/*.propertiesinclude>
<include>**/*.xmlinclude>
includes>
<filtering>falsefiltering>
resource>
resources>
build>
想要该项目的小伙伴可以私信跟我要~ 一起加油
Eureka的基本架构
SpringCloud 封装了NetFlix公司开发的Eureka模块来实现服务注册和发现(对比Zookeeper)
Eureka采用了C-S的架构设计,EurekaServer 作为服务注册功能的服务器,他是服务注册中心
而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。 这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行,SpringCloud的一些其他模块(比如Zuul)就可以通过EurekaServer来发现系统中的其他微服务,并执行相关的逻辑;
和Dubbo架构对比
注册
效果:
CAP理论的核心
Zookeeper保证的是CP
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接
down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30~120s,且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因为网络问题使得zk集群失去master节点是较大概率会发生的事件,虽然服务最终能够恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka保证的是AP
Eureka看明白了这一-点, 因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保住注册服务的可用性,只不过查到的信息可能不是最新的,除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
因此,Eureka可以很好的应对因网络故障 导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪
Feign集成了Ribbon
分布式系统面临的问题
复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免的失败!
什么是Hystrix
Hystrix是一个用于处理分布式系统的延迟和容错的开源库, 在分布式系统里,许多依赖不可避免的会调用失败,比如超时,异常等, Hystrix能够保证在一个依赖出问题的情况下, 不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个服务预期的,可处理的备选响应(FallBack) ,而不是长时间的等待或者抛出调用方法无法处理的异常,这样就可以保证了服务调用方的线程不会被长时间,不必要的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩.
Hystrix能做什么
官网资料
https://github.com/Netflix/Hystrix/wiki
熔断机制是对应雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况,当失败的调用到一定阈值,缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand.
如何看
七色
一圈
实心圆:公有两种含义,他通过颜色的变化代表了实例的健康程度
它的健康程度从绿色<黄色<橙色<红色 递减
该实心圆除了颜色的变化之外,它的大小也会根据实例的请求流量发生变化,流量越大,该实心圆就越大,所以通过该实心圆的展示,就可以在大量的实例中快速发现故障实例和高压力实例。
一线
曲线: 用来记录2分钟内流量的相对变化, 可以通过他来观察到流量的上升和下降趋势
整图说明
搞懂一个才能看懂复杂的
官方文档: https://github.com/Netflix/zuul
什么是SpringCloud config分布式配置中心
Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置。
Spring Cloud Config 分为服务端和客户端两部分;
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密,解密信息等访问接口。
客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。
SpringCloud config分布式配置中心能干嘛
SpringCloud config分布式配置中心与github整合
由于Spring Cloud Config默认使用Git来存储配置文件(也有其他方式,比如支持SVN和本地文件),但是最推荐的还是Git,而且使用的是http/https访问的形式;