✅作者简介:2022年博客新星 第八。热爱国学的Java后端开发者,修心和技术同步精进。
🍎个人主页:Java Fans的博客
🍊个人信条:不迁怒,不贰过。小知识,大智慧。
💞当前专栏:SpringCloud 微服务学习专栏
✨特色专栏:国学周更-心性养成之路
🥭本文内容:SpringCloud 微服务系列——【基础与服务注册中心详解】
1、什么是微服务
官网: https://www.martinfowler.com/articles/microservices.html
In short, the microservice architectural(架构) style is an approach to developing a single application as a suite(系列) of small services
, each running in its own process(进程)
and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business(业务) capabilities(单元)
and independently(独立) deployable(部署)
by fully automated deployment machinery. There is a bare(基于) minimum of centralized(分布式) management(管理) of these services
, which may be written in different programming languages and use different data storage technologies. -----[摘自官网]
- a suite of small services --一系列微小服务
- running in its own process --运行在自己的进程里
- built around business capabilities --围绕自己的业务开发
- independently deployable --独立部署
- bare minimum of centralized management of these services --基于分布式管理
- 官方定义:微服务就是由一系列围绕自己业务开发的微小服务构成,他们独立部署运行在自己的进程里,基于分布式的管理
- 通俗定义:微服务是一种架构,这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能,包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机,同一个系统和同一个应用服务器中。
2、为什么是微服务
传统单体应用
1.优点
- 单一架构模式在项目初期很小的时候开发方便,测试方便,部署方便,运行良好。
2.缺点
- 应用随着时间的推进,加入的功能越来越多,最终会变得巨大,一个项目中很有可能数百万行的代码,互相之间繁琐的jar包。
- 久而久之,开发效率低,代码维护困难
- 如果想整体应用采用新的技术,新的框架或者语言,那是不可能的。
- 任意模块的漏洞或者错误都会影响这个应用,降低系统的可靠性
微服务架构应用
1.优点
- 将服务拆分成多个单一职责的小的服务,进行单独部署,服务之间通过网络进行通信
- 每个服务应该有自己单独的管理团队,高度自治
- 服务各自有自己单独的职责,服务之间松耦合,避免因一个模块的问题导致服务崩溃
2.缺点
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度,随着服务的增加,运维的压力也在增大
- 服务治理 和 服务监控难度增加
3、微服务的解决方案
3.1、Dubbo (阿里系)
-
初出茅庐:2011年末,阿里巴巴在GitHub上开源了基于Java的分布式服务治理框架Dubbo,之后它成为了国内该类开源项目的佼佼者,许多开发者对其表示青睐。同时,先后有不少公司在实践中基于Dubbo进行分布式系统架构,目前在GitHub上,它的fork、star数均已破万。Dubbo致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案,使得应用可通过高性能RPC实现服务的输出、输入功能和Spring框架无缝集成。Dubbo包含远程通讯、集群容错和自动发现三个核心部分。
-
停止维护:从2012年10月23日Dubbo 2.5.3发布后,在Dubbo开源将满一周年之际,阿里基本停止了对Dubbo的主要升级。只在之后的2013年和2014年更新过2次对Dubbo 2.4的维护版本,然后停止了所有维护工作。Dubbo对Srping的支持也停留在了Spring 2.5.6版本上。
-
死而复生:多年漫长的等待,随着微服务的火热兴起,在国内外开发者对阿里不再升级维护Dubbo的吐槽声中,阿里终于开始重新对Dubbo的升级和维护工作。在2017年9月7日,阿里发布了Dubbo的2.5.4版本,距离上一个版本2.5.3发布已经接近快5年时间了。在随后的几个月中,阿里Dubbo开发团队以差不多每月一版本的速度开始快速升级迭代,修补了Dubbo老版本多年来存在的诸多bug,并对Spring等组件的支持进行了全面升级。
-
2018年1月8日,Dubbo创始人之一梁飞在Dubbo交流群里透露了Dubbo 3.0正在动工的消息。Dubbo 3.0内核与Dubbo 2.0完全不同,但兼容Dubbo 2.0。Dubbo 3.0将以Streaming为内核,不再是Dubbo 时代的RPC,但是RPC会在Dubbo 3.0中变成远程Streaming对接的一种可选形态。从Dubbo新版本的路线规划上可以看出,新版本的Dubbo在原有服务治理的功能基础上,将全面拥抱微服务解决方案。
-
结论:当前由于RPC协议、注册中心元数据不匹配等问题,在面临微服务基础框架选型时Dubbo与Spring Cloud是只能二选一,这也是为什么大家总是拿Dubbo和Spring Cloud做对比的原因之一。Dubbo之后会积极寻求适配到Spring Cloud生态,比如作为Spring Cloud的二进制通信方案来发挥Dubbo的性能优势,或者Dubbo通过模块化以及对http的支持适配到Spring Cloud。
3.2、Spring Cloud
-
Spring Cloud NetFlix
基于美国Netflix公司开源的组件进行封装,提供了微服务一栈式的解决方案。
-
Spring Cloud alibaba
在Spring cloud netflix基础上封装了阿里巴巴的微服务解决方案。
-
Spring Cloud Spring
目前spring官方趋势正在逐渐吸收Netflix组件的精华,并在此基础进行二次封装优化,打造spring专有的解决方案
4、什么是 SpringCloud
官网: https://cloud.spring.io/spring-cloud-static/Hoxton.SR5/reference/html/
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management
, service discovery
, circuit breakers, intelligent routing, micro-proxy, control bus
). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. -------[摘自官网]
通俗理解
- springcloud是一个含概多个子项目的开发工具集,集合了众多的开源框架,他利用了Spring Boot开发的便利性实现了很多功能,如服务注册,服务注册发现,负载均衡等.SpringCloud在整合过程中主要是针对Netflix(耐非)开源组件的封装.SpringCloud的出现真正的简化了分布式架构的开发。NetFlix 是美国的一个在线视频网站,微服务业的翘楚,他是公认的大规模生产级微服务的杰出实践者,NetFlix的开源组件已经在他大规模分布式微服务环境中经过多年的生产实战验证,因此Spring Cloud中很多组件都是基于NetFlix
核心架构及其组件
核心组件说明
-
eurekaserver、consul、nacos
服务注册中心组件 -
rabbion & openfeign
服务负载均衡 和 服务调用组件 -
hystrix & hystrix dashboard
服务断路器 和 服务监控组件 -
zuul、gateway
服务网关组件 -
config
统一配置中心组件 -
bus
消息总线组件
…
5、环境搭建
5.1、版本命名
springcloud是一个由众多独立子项目组成的大型综合项目,原则每个子项目上有不同的发布节奏,都维护自己发布版本号。为了更好的管理springcloud的版本,通过一个资源清单BOM(Bill of Materials),为避免与子项目的发布号混淆,所以没有采用版本号的方式,而是通过命名的方式。这些名字是按字母顺序排列的。如伦敦地铁站的名称(“天使”是第一个版本,“布里斯顿”是第二个版本,"卡姆登"是第三个版本)。当单个项目的点发布累积到一个临界量,或者其中一个项目中有一个关键缺陷需要每个人都可以使用时,发布序列将推出名称以“.SRX”结尾的“服务发布”,其中“X”是一个数字。
2.伦敦地铁站名称 [了解]
- Angel、Brixton、Camden、Dalston、Edgware、Finchley、Greenwich、Hoxton
5.2、版本选择
5.3、环境搭建
- springboot 2.2.5.RELEASE
- springcloud Hoxton.SR6
- java8
- maven 3.3.5
- idea 2020
1.创建springboot项目 指定版本为 2.2.5.RELEASE版本
<!-- 继承springboot的父工程-->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.5.RELEASE</version>
</parent>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
2.引入springcloud的版本管理
<!-- 统一维护依赖的版本-->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<java.version>1.8</java.version>
<spring-cloud.version>Hoxton.SR6</spring-cloud.version>
</properties>
<!--全局管理springcloud版本,并不会引入具体依赖-->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type> <!-- 其它组件小版本号的维护-->
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
3.完成上述操作springboot与springcloud环境搭建完成,接下来就是使用到具体的springcloud组件,在项目中引入具体的组件即可
6、服务注册中心
什么是服务注册中心
所谓服务注册中心就是在整个的微服务架构中单独提出一个服务,这个服务不完成系统的任何的业务功能,仅仅用来完成对整个微服务系统的服务注册和服务发现,以及对服务健康状态的监控和管理功能。
1.服务注册中心
- 可以对所有的微服务的信息进行存储,如微服务的名称、IP、端口等
- 可以在进行服务调用时通过服务发现查询可用的微服务列表及网络地址进行服务调用
- 可以对所有的微服务进行心跳检测,如发现某实例长时间无法访问,就会从服务注册表移除该实例
2.常用的注册中心
springcloud支持的多种注册中心Eureka、Consul(GO)、Zookeeper(java)、以及阿里巴巴推出Nacos(java)。这些注册中心在本质上都是用来管理服务的注册和发现以及服务状态的检查的。
6.1、Eureka注册中心
官网:https://github.com/Netflix/eureka/wiki
简介
Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务。SpringCloud将它集成在其子项目spring-cloud-netflix中,以实现SpringCloud的服务注册和发现功能。Eureka包含两个组件:
- Eureka Server
- Eureka Client
开发Eureka Server
1.创建项目并引入eureka server依赖
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!--引入 eureka server-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
</dependencies>
2.编写配置application.yml
server:
port: 8761 # eureka 默认的端口号
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:8761/eureka #指定服务注册中心的地址
#指定服务注册中心的名字
spring:
application:
name: EUREKASERVER #服务名称不要使用下划线 服务名称不区分大小写 推荐服务名大写
3.开启EurekaServer,入口类加入注解
@SpringBootApplication
@EnableEurekaServer
public class Eurekaserver8761Application {
public static void main(String[] args) {
SpringApplication.run(Eurekaserver8761Application.class, args);
}
}
4.访问Eureka的服务注册页面
http://localhost:8761
5.为什么项目启动控制台报错?
原因分析:
eureka组件包含 eurekaserver 和 eurekaclient。server是一个服务注册中心,用来接受客户端的注册。client的特性会让当前启动的服务把自己作为eureka的客户端进行服务中心的注册,当项目启动时服务注册中心还没有创建好,所以找不到服务的客户端组件就直接报错了,当服务注册中心启动成功后,就不再报错啦!
解决方案:
eureka.client.register-with-eureka=false #不再将自己作为客户端进行注册
eureka.client.fetch-registry=false # 不获取注册信息
再次启动,控制器也不再报错
开发Eureka Client
1.创建项目并引入eureka client依赖
<!--引入eureka client-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
2.编写配置application.yml
server.port=8888 #服务端口号
spring.application.name=eurekaclient8888 #服务名称唯一标识
eureka.client.service-url.defaultZone=http://localhost:8761/eureka #eureka注册中心地址
3.开启eureka客户端并加入注解
@SpringBootApplication
@EnableEurekaClient
public class Eurekaclient8888Application {
public static void main(String[] args) {
SpringApplication.run(Eurekaclient8888Application.class, args);
}
}
4.启动服务注册中心,然后启动eureka客户端服务
5.查看eureka server的服务注册情况
Eureka自我保护机制
服务频繁启动时 EurekaServer出现错误
- EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
自我保护机制
官网地址: https://github.com/Netflix/eureka/wiki/Server-Self-Preservation-Mode
默认情况下,如果Eureka Server在一定时间内(默认90秒)没有接收到某个微服务实例的心跳,Eureka Server将会移除该实例。但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,而微服务本身是正常运行的,此时不应该移除这个微服务,所以引入了自我保护机制。
Eureka Server在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%,如果低于 85%,Eureka Server 会将这些实例保护起来,让这些实例不会过期。这种设计的哲学原理就是"宁可信其有不可信其无!"。自我保护模式正是一种针对网络异常波动的安全保护措施,使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。
在Eureka server端关闭自我保护机制
eureka.server.enable-self-preservation=false #关闭自我保护
eureka.server.eviction-interval-timer-in-ms=3000 #超时3s自动清除 默认60*1000 1min钟清除
----------------------------yml风格------------------------------------------
eureka:
server:
enable-self-preservation: false # 关闭自我保护机制
eviction-interval-timer-in-ms: 3000 # 超时移除时间
微服务客户端修改减短服务心跳的时间
eureka.instance.lease-expiration-duration-in-seconds=10 #用来修改eureka server默认接受心跳的最大时间 默认是90s
eureka.instance.lease-renewal-interval-in-seconds=5 #指定客户端多久向eureka server发送一次心跳 默认是30s
--------------------------------yml风格--------------------------------------
eureka:
instance:
lease-expiration-duration-in-seconds: 10
lease-renewal-interval-in-seconds: 5
尽管如此关闭自我保护机制还是会出现警告
官方不建议关闭Eureka自我保护机制
Eureka集群的搭建
1.按照之前创建EurekaServer的方式创建多个服务器端,修改端口号和注册中心地址
2.客户端集群也可采用之前创建客户端的方式创建多个客户端,修改端口号和注册中心地址
3.不采用以上的两种形式也可以利用IDEA工具进行集群的快速搭建,操作方式如下:
修改端口号:-Dserver.port=9090
复制完成后,启动项目即可
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:8788/eureka,http://127.0.0.1:8789/eureka
#客户端
eureka:
client:
service-url:
defaultZone: http://localhost:8787/eureka,http://localhost:8788/eureka,http://localhost:8789/eureka
6.2、Consul注册中心
官网:https://www.consul.io
consul是一个可以提供服务发现,健康检查,多数据中心,Key/Value存储等功能的分布式服务框架,用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案,使用起来也较为简单。Consul用Golang实现,因此具有天然可移植性(支持Linux、Windows和Mac OS X);安装包仅包含一个可执行文件,方便部署。
1.下载consul
- https://www.consul.io/downloads
2.安装consul
- 官方安装视频地址: https://learn.hashicorp.com/consul/getting-started/install.html
- 解压之后发现consul只有一个脚本文件
3.根据解压缩目录配置环境变量
4.查看consul环境变量是否配置成功,执行命令出现如下信息代表成功
5.访问consul的web服务端口
http://localhost:8500
指定数据中心启动 consul agent -dev -datacenter mosin
6.开发consul 客户端即微服务
- 1.创建项目并引入consul客户端依赖
<!--引入consul依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>
- 编写yml配置
server.port=8889
spring.application.name=consulclient8889
spring.cloud.consul.host=localhost #注册consul服务的主机
spring.cloud.consul.port=8500 #注册consul服务的端口号
#指定注册的服务名称 默认就是应用名
spring.cloud.consul.discovery.service-name=${spring.application.name}
- 启动服务查看consul界面服务信息
- consul 开启健康监控检查
开启consul健康监控
默认情况consul监控健康是开启的,但是必须依赖健康监控依赖才能正确监控健康状态所以直接启动会显示错误,引入健康监控依赖之后服务正常
<!-- 这个包是用做健康度监控的-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
关闭consul的健康检查(不推荐)
spring.cloud.consul.discovery.register-health-check=false
不同注册中心区别
1.CAP定理
CAP定理:CAP定理又称CAP原则,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
-
一致性(C):
在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本) -
可用性(A):
在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性) -
分区容忍性(P):
就是高可用性,一个节点崩了,并不影响其它的节点(100个节点,挂了几个,不影响服务,越多机器越好)
2.Eureka特点
- Eureka中没有使用任何的数据强一致性算法保证不同集群间的Server的数据一致,仅通过数据拷贝的方式争取注册中心数据的最终一致性,虽然放弃数据强一致性但是换来了Server的可用性,降低了注册的代价,提高了集群运行的健壮性。
3.Consul特点
- 基于Raft算法,Consul提供强一致性的注册中心服务,但是由于Leader节点承担了所有的处理工作,势必加大了注册和发现的代价,降低了服务的可用性。通过Gossip协议,Consul可以很好地监控Consul集群的运行,同时可以方便通知各类事件,如Leader选择发生、Server地址变更等。
4.zookeeper特点
- 基于Zab协议,Zookeeper可以用于构建具备数据强一致性的服务注册与发现中心,而与此相对地牺牲了服务的可用性和提高了注册需要的时间。
码文不易,本篇文章就介绍到这里,如果想要学习更多Java系列知识,点击关注博主,博主带你零基础学习Java知识。与此同时,对于日常生活有困扰的朋友,欢迎阅读我的第四栏目:《国学周更—心性养成之路》,学习技术的同时,我们也注重了心性的养成。文章来源:https://www.toymoban.com/news/detail-427831.html
文章来源地址https://www.toymoban.com/news/detail-427831.html
到了这里,关于SpringCloud 微服务系列——【基础与服务注册中心详解】的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!