男生和女生做污的事情免费网站,wordpress 系统要求,网站seo推广平台,网站开发学徒工作如何SpringCloud微服务之Eureka、Ribbon、Nacos详解 1、认识微服务1.1、单体架构1.2、分布式架构1.3、微服务1.4、SpringCloud 2、服务拆分与远程调用2.1、服务拆分的原则2.2、服务拆分示例2.2、提供者与消费者 3、Eureka注册中心3.1、Eureka的结构和作用3.2、搭建eureka-server3.2… SpringCloud微服务之Eureka、Ribbon、Nacos详解 1、认识微服务1.1、单体架构1.2、分布式架构1.3、微服务1.4、SpringCloud 2、服务拆分与远程调用2.1、服务拆分的原则2.2、服务拆分示例2.2、提供者与消费者 3、Eureka注册中心3.1、Eureka的结构和作用3.2、搭建eureka-server3.2.1、创建eureka-server微服务3.2.2、引入eureka依赖3.2.3、编写启动类3.2.4、编写配置文件3.2.5、启动服务 3.3、服务注册3.3.1、启动多个user-service实例 3.4、服务发现 4、Ribbon负载均衡4.1、负载均衡的原理4.2、负载均衡策略4.3、饥饿加载 5、Nacos注册中心5.1、认识和安装Nacos5.1.1、Windows安装5.1.2、Linux安装 5.2、Nacos的依赖5.3、服务分级存储模型5.3.1、给user-service配置集群5.3.2、同集群优先的负载均衡 5.4、权重配置5.5、环境隔离5.5.1、创建namespace5.5.2、给微服务配置namespace 5.6、Nacos与Eureka的区别 1、认识微服务
随着互联网行业的发展对服务的要求也越来越高服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢
1.1、单体架构
单体架构将业务的所有功能集中在一个项目中开发打成一个包部署。 单体架构的优缺点如下
优点
架构简单、部署成本低
缺点
耦合度高维护困难、升级困难
1.2、分布式架构
分布式架构根据业务功能对系统做拆分每个业务功能模块作为独立项目开发称为一个服务。 分布式架构的优缺点
优点
降低服务耦合、有利于服务升级和拓展
缺点
服务调用关系错综复杂 思考分布式架构虽然降低了服务耦合但是服务拆分时也有很多问题需要思考 服务拆分的粒度如何界定服务之间如何调用服务的调用关系如何管理
人们需要制定一套行之有效的标准来约束分布式架构。
1.3、微服务
微服务的架构特征
单一职责微服务拆分粒度更小每一个服务都对应唯一的业务能力做到单一职责自治团队独立、技术独立、数据独立独立部署和交付面向服务服务提供统一标准的接口与语言和技术无关隔离性强服务调用做好隔离、容错、降级避免出现级联问题 微服务的上述特性其实是在给分布式架构制定一个标准进一步降低服务之间的耦合度提供服务的独立性和灵活性。做到高内聚低耦合。
因此可以认为微服务是一种经过良好架构设计的分布式架构方案 。但方案该怎么落地选用什么样的技术栈全球的互联网公司都在积极尝试自己的微服务落地方案。其中在Java领域最引人注目的就是SpringCloud提供的方案了。
1.4、SpringCloud
SpringCloud是目前国内使用最广泛的微服务框架。官网地址https://spring.io/projects/spring-cloud。
SpringCloud集成了各种微服务功能组件并基于SpringBoot实现了这些组件的自动装配从而提供了良好的开箱即用体验。
其中常见的组件包括 另外SpringCloud底层是依赖于SpringBoot的并且有版本的兼容关系如下 2、服务拆分与远程调用
2.1、服务拆分的原则
不同微服务不要重复开发相同业务微服务数据独立不要访问其它微服务的数据库微服务可以将自己的业务暴露为接口供其它微服务调用 每个微服务都有自己的数据库用户功能里面存的是用户相关的数据库商品功能里面存的是商品相关的数据库如果想在用户功能里面需要订单的信息那么订单模块就对外暴露成一个接口供用户功能的微服务调用。
2.2、服务拆分示例
创建订单模块的数据库KuangStudy_springcloud_order然后导入下述sql
DROP TABLE IF EXISTS tb_order;
CREATE TABLE tb_order (id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 订单id,user_id bigint(20) NOT NULL COMMENT 用户id,name varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT 商品名称,price bigint(20) NOT NULL COMMENT 商品价格,num int(10) NULL DEFAULT 0 COMMENT 商品数量,PRIMARY KEY (id) USING BTREE,UNIQUE INDEX username(name) USING BTREE
) ENGINE InnoDB AUTO_INCREMENT 109 CHARACTER SET utf8 COLLATE utf8_general_ci ROW_FORMAT Compact;INSERT INTO tb_order VALUES (101, 1, Apple 苹果 iPhone 12 , 699900, 1);
INSERT INTO tb_order VALUES (102, 2, 雅迪 yadea 新国标电动车, 209900, 1);
INSERT INTO tb_order VALUES (103, 3, 骆驼CAMEL休闲运动鞋女, 43900, 1);
INSERT INTO tb_order VALUES (104, 4, 小米10 双模5G 骁龙865, 359900, 1);
INSERT INTO tb_order VALUES (105, 5, OPPO Reno3 Pro 双模5G 视频双防抖, 299900, 1);
INSERT INTO tb_order VALUES (106, 6, 美的Midea) 新能效 冷静星II , 544900, 1);
INSERT INTO tb_order VALUES (107, 2, 西昊/SIHOO 人体工学电脑椅子, 79900, 1);
INSERT INTO tb_order VALUES (108, 3, 梵班FAMDBANN休闲男鞋, 31900, 1);创建用户模块的数据库KuangStudy_springcloud_user然后导入下述sql
DROP TABLE IF EXISTS tb_user;
CREATE TABLE tb_user (id bigint(20) NOT NULL AUTO_INCREMENT,username varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT 收件人,address varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT 地址,PRIMARY KEY (id) USING BTREE,UNIQUE INDEX username(username) USING BTREE
) ENGINE InnoDB AUTO_INCREMENT 109 CHARACTER SET utf8 COLLATE utf8_general_ci ROW_FORMAT Compact;INSERT INTO tb_user VALUES (1, 柳岩, 湖南省衡阳市);
INSERT INTO tb_user VALUES (2, 文二狗, 陕西省西安市);
INSERT INTO tb_user VALUES (3, 华沉鱼, 湖北省十堰市);
INSERT INTO tb_user VALUES (4, 张必沉, 天津市);
INSERT INTO tb_user VALUES (5, 郑爽爽, 辽宁省沈阳市大东区);
INSERT INTO tb_user VALUES (6, 范兵兵, 山东省青岛市);tb_user表中初始数据如下 tb_order表中初始数据如下 tb_order表中持有tb_user表中的id字段。 在order-service服务中有一个根据id查询订单的接口 根据id查询订单返回值是Order对象如图 在user-service中有一个根据id查询用户的接口 查询的结果如图 案例需求修改order-service中的根据id查询订单业务要求在查询订单的同时根据订单中包含的userId查询出用户信息一起返回 因此我们需要在order-service中 向user-service发起一个http的请求调用http://localhost:8081/user/{userId}这个接口。
大概的步骤是这样的
注册一个RestTemplate的实例到Spring容器修改order-service服务中的OrderService类中的queryOrderById方法根据Order对象中的userId查询User将查询的User填充到Order对象一起返回
在order-service服务中的OrderApplication启动类中注册RestTemplate实例
MapperScan(cn.itcast.order.mapper)
SpringBootApplication
public class OrderApplication {public static void main(String[] args) {SpringApplication.run(OrderApplication.class, args);}/*** 注册RestTemplate*/Beanpublic RestTemplate restTemplate() {return new RestTemplate();}
}修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法 访问http://localhost:8080/order/101 2.2、提供者与消费者
在服务调用关系中会有两个不同的角色 服务提供者一次业务中被其它微服务调用的服务。提供接口给其它微服务 服务消费者一次业务中调用其它微服务的服务。调用其它微服务提供的接口
但是服务提供者与服务消费者的角色并不是绝对的而是相对于业务而言。 思考如果服务A调用了服务B而服务B又调用了服务C服务B的角色是什么 对于A调用B的业务而言A是服务消费者B是服务提供者对于B调用C的业务而言B是服务消费者C是服务提供者因此服务B既可以是服务提供者也可以是服务消费者。 总结一个服务既可以是提供者也可以是消费者
3、Eureka注册中心
读音Eurekayou rui ka
假如我们的服务提供者user-service部署了多个实例如图 大家思考几个问题
order-service在发起远程调用的时候该如何得知user-service实例的ip地址和端口有多个user-service实例地址order-service调用时该如何选择order-service如何得知某个user-service实例是否依然健康是不是已经宕机
3.1、Eureka的结构和作用
这些问题都需要利用SpringCloud中的注册中心来解决其中最广为人知的注册中心就是Eureka其结构如下 Eureka分为两层结构
服务端也就是注册中心客户端包含服务消费者和服务提供者
每一个user-service在启动时都会去 注册中心 注册服务信息Eureka会把这些信息记录下来包括ip、端口等等如果 order-service 需要调用user-service的接口先去找注册中心注册中心有关于user-service的信息则order-service就可以获取到user-service的信息了。
如上图order-service拿到了3个user-service的信息通过负载均衡挑出一个这样order-service就可以调用user-service了。 思考那挑选出来的user-service会不会宕机呢 答案不会因为客户端会每30秒给Eureka发送心跳来续费自己的信息以此来让Eureka来确保自己还活着 这样我们就可以回答之前的各个问题了
order-service如何得知user-service实例地址 获取地址信息的流程如下user-service服务实例启动后将自己的信息注册到eureka-serverEureka服务端。这个叫服务注册eureka-server保存服务名称到服务实例地址列表的映射关系order-service根据服务名称拉取实例地址列表。这个叫服务发现或服务拉取 order-service如何从多个user-service实例中选择具体的实例 order-service从实例列表中利用负载均衡算法选中一个实例地址向该实例地址发起远程调用 order-service如何得知某个user-service实例是否依然健康是不是已经宕机 user-service会每隔一段时间默认30秒向eureka-server发起请求报告自己状态称为心跳当超过一定时间没有发送心跳时eureka-server会认为微服务实例故障将该实例从服务列表中剔除order-service拉取服务时就能将故障实例排除了
3.2、搭建eureka-server
3.2.1、创建eureka-server微服务
在cloud-demo父工程下创建一个子模块 填写Maven模块信息 然后填写服务信息 3.2.2、引入eureka依赖
引入SpringCloud为eureka提供的starter依赖
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-netflix-eureka-server/artifactId
/dependency3.2.3、编写启动类
给eureka-server服务编写一个启动类
src/main/java/cn/itcast/eureka/EurekaApplication.java一定要添加一个EnableEurekaServer注解开启eureka的注册中心功能
EnableEurekaServer
SpringBootApplication
public class EurekaApplication {public static void main(String[] args) {SpringApplication.run(EurekaApplication.class, args);}
}3.2.4、编写配置文件
编写一个application.yml文件内容如下
server:port: 10086 # 服务端口
spring:application:name: eurekaserver # eureka的服务名称
eureka:client:service-url: # eureka的地址信息defaultZone: http://127.0.0.1:10086/eureka3.2.5、启动服务
启动erueka-server微服务EurekaApplication然后在浏览器访问http://127.0.0.1:10086看到如下结果则成功。 3.3、服务注册
下面我们将user-service注册到eureka-server中去。 引入依赖 在user-service的pom文件中引入下面的eureka-client依赖
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-netflix-eureka-client/artifactId
/dependency配置文件 在user-service中修改application.yml文件添加服务名称、eureka地址
spring:application:# 微服务的名字name: userservice# eureka 服务注册
eureka:client:service-url:# eureka的地址信息defaultZone: http://127.0.0.1:10086/eureka3.3.1、启动多个user-service实例
为了演示一个服务有多个实例的场景我们添加一个SpringBoot的启动配置再启动一个user-service。模拟多实例部署但是为了避免端口冲突需要修改端口设置。
首先复制原来的user-service启动配置 填写信息将第二个user-service的端口写为8082 启动两个user-service实例(第一个是8081端口、第二个是8082端口)、启动eureka-service 注册中心
3.4、服务发现
下面我们将order-service的逻辑修改向eureka-server拉取user-service的信息实现服务发现。
引入依赖之前说过服务发现、服务注册统一都封装在eureka-client依赖因此这一步与服务注册时一致在order-service的pom文件中引入下面的eureka-client依赖
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-netflix-eureka-client/artifactId
/dependency配置文件服务发现也需要知道eureka地址因此第二步与服务注册一致都是配置eureka信息在order-service中修改application.yml文件添加服务名称、eureka地址
spring:application:# 微服务的名字name: orderservice# eureka 服务注册
eureka:client:service-url:# eureka的地址信息defaultZone: http://127.0.0.1:10086/eureka服务拉取与负载均衡
最后我们要去eureka-server中拉取user-service服务的实例列表并且实现负载均衡。不过这些动作不用我们去做只需要添加一些注解即可。
在order-service的OrderApplication中给RestTemplate这个Bean添加一个LoadBalanced注解 修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法。修改访问的url路径用服务名代替ip、端口 spring会自动帮助我们从eureka-server端根据userservice这个服务名称获取实例列表而后完成负载均衡。
4、Ribbon负载均衡
读音Ribbon瑞奔
4.1、负载均衡的原理
SpringCloud底层其实是利用了一个名为Ribbon的组件来实现负载均衡功能的。 当微服务 order-service 发起 http://userservice/user/1 的请求时会先被 Ribbon 拦截获得另一个微服务名称 user-serviceRibbon 会去找 eureka-server 注册中心拉取 user-service 的ip和端口号然后对 ip 和端口号进行负载均衡。 思考: 那么我们发出的请求明明是http://userservice/user/1怎么变成了http://localhost:8081的呢 SpringCloudRibbon的底层采用了一个拦截器拦截了RestTemplate发出的请求对地址做了修改。用一幅图来总结一下 基本流程如下
拦截我们的RestTemplate请求http://userservice/user/1RibbonLoadBalancerClient会从请求url中获取服务名称也就是user-serviceDynamicServerListLoadBalancer根据user-service到eureka拉取服务列表eureka返回列表localhost:8081、localhost:8082IRule利用内置负载均衡规则从列表中选择一个例如localhost:8081RibbonLoadBalancerClient修改请求地址用localhost:8081替代userservice得到http://localhost:8081/user/1发起真实请求
4.2、负载均衡策略
负载均衡的规则都定义在IRule接口中而IRule有很多不同的实现类 不同规则的含义如下
内置负载均衡规则类规则描述RoundRobinRule简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule对以下两种服务器进行忽略 1在默认情况下这台服务器如果3次连接失败这台服务器就会被设置为“短路”状态。短路状态将持续30秒如果再次连接失败短路的持续时间就会几何级地增加。 2并发数过高的服务器。如果一个服务器的并发连接数过高配置了AvailabilityFilteringRule规则的客户端也会将其忽略。WeightedResponseTimeRule为每一个服务器赋予一个权重值。服务器响应时间越长这个服务器的权重就越小。这个规则会随机选择服务器这个权重值会影响服务器的选择。ZoneAvoidanceRule以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。BestAvailableRule忽略那些短路的服务器并选择并发数较低的服务器。RandomRule随机选择一个可用的服务器。RetryRule重试机制的选择逻辑 默认的实现就是ZoneAvoidanceRule是一种轮询方案注意一般用默认的负载均衡规则不做修改。 4.3、饥饿加载
Ribbon默认是采用懒加载即第一次访问时才会去创建LoadBalanceClient请求时间会很长。而饥饿加载则会在项目启动时创建降低第一次访问的耗时通过下面配置开启饥饿加载
在 order-service 的 application.yaml 里面开启饥饿加载
ribbon:eager-load:# 开启饥饿加载enabled: true# 指定饥饿加载的服务名称clients: userservice假如有多个服务需要开启饥饿加载
ribbon:eager-load:# 开启饥饿加载enabled: true# 指定饥饿加载的服务名称clients: - userservice- xxxservice5、Nacos注册中心
国内公司一般都推崇阿里巴巴的技术比如注册中心SpringCloudAlibaba也推出了一个名为Nacos的注册中心。
5.1、认识和安装Nacos
Nacos是阿里巴巴的产品现在是SpringCloud中的一个组件。相比Eureka功能更加丰富在国内受欢迎程度较高。 去GitHub的Release下载Nacoshttps://github.com/alibaba/nacos/releases 5.1.1、Windows安装 我这里下载nacos-server-1.4.7.zip ,解压到非中文目录下目录说明 bin启动脚本conf配置文件 Nacos的默认端口是8848如果你电脑上的其它进程占用了8848端口请先尝试关闭该进程。如果无法关闭占用8848端口的进程也可以进入nacos的conf/application.properties目录修改配置文件中的端口 启动:进入 bin目录打开 cmd执行如下命令
# 以单机模式启动
startup.cmd -m standalone访问:http://127.0.0.1:8848/nacos即可默认账号密码都是 nacos 5.1.2、Linux安装
Nacos依赖于JDK运行索引Linux上也需要安装JDK才行。略:参考Linux下安装JDK环境将nacos-server-1.4.7.tar.gz 上传到Linux服务器的某个目录解压
tar -xvf nacos-server-1.4.7.tar.gz端口配置:与Windows类似启动在nacos/bin目录中输入命令启动
sh startup.sh -m standalone5.2、Nacos的依赖
引入依赖在cloud-demo父工程的pom文件中的dependencyManagement中引入SpringCloudAlibaba的依赖
!--nacos的管理依赖--
dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-alibaba-dependencies/artifactIdversion2.2.5.RELEASE/versiontypepom/typescopeimport/scope
/dependency注释掉 order-service 和 user-service 中原有的 eureka 依赖引入依赖然后在user-service和order-service中的pom文件中引入nacos-discovery依赖
!-- nacos客户端依赖包 --
dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId
/dependency服务注册到nacos在user-service和order-service的application.yml中添加nacos地址
spring:cloud:nacos:# nacos服务地址server-addr: localhost:8848 注释掉 eureka 的配置启动 order-service、user-service 微服务登录 nacos 管理页面http://127.0.0.1:8848/nacos可以看到微服务信息 5.3、服务分级存储模型
一个服务可以有多个实例例如我们的user-service可以有:
127.0.0.1:8081127.0.0.1:8082127.0.0.1:8083
假如这些实例分布于全国各地的不同机房例如
127.0.0.1:8081在上海机房127.0.0.1:8082在上海机房127.0.0.1:8083在杭州机房 Nacos就将同一机房内的多个实例划分为一个集群。 也就是说user-service是服务一个服务可以包含多个集群如杭州、上海每个集群下可以有多个实例形成分级模型如图 微服务互相访问时应该尽可能访问同集群实例因为本地访问速度更快。当本集群内不可用时才访问其它集群。例如 杭州机房内的order-service应该优先访问同机房的user-service。
5.3.1、给user-service配置集群
修改user-service的application.yml文件添加集群配置
spring:cloud:nacos:server-addr: localhost:8848discovery:# 集群名称杭州cluster-name: HZ 重启两个user-service实例后我们可以在nacos控制台看到下面结果 我们再次复制一个user-service启动配置添加属性
# 端口为8083 集群为上海
-Dserver.port8083 -Dspring.cloud.nacos.discovery.cluster-nameSH启动UserApplication3后再次查看nacos控制台
5.3.2、同集群优先的负载均衡
默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。因此Nacos中提供了一个NacosRule的实现可以优先从同集群中挑选实例。所以需要给 order-service也需要配置 HZ 集群信息。
给order-service配置集群信息修改order-service的application.yml文件添加集群配置
spring:cloud:nacos:server-addr: localhost:8848discovery:cluster-name: HZ # 集群名称修改负载均衡规则修改order-service的application.yml文件修改负载均衡规则
userservice:ribbon:# 负载均衡规则 NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule 5.4、权重配置
实际部署中会出现这样的场景服务器设备性能有差异部分实例所在机器性能较好另一些较差我们希望性能好的机器承担更多的用户请求。但默认情况下NacosRule是同集群内随机挑选不会考虑机器的性能问题。
因此Nacos提供了权重配置来控制访问频率权重越大则访问频率越高。在nacos控制台找到user-service的实例列表点击编辑即可修改权重 注意如果权重修改为0则该实例永远不会被访问 5.5、环境隔离
Nacos提供了namespace来实现环境隔离功能。
nacos中可以有多个namespacenamespace下可以有group、service等不同namespace之间相互隔离例如不同namespace的服务互相不可见 5.5.1、创建namespace
默认情况下所有service、data、group都在同一个namespace名为public 我们可以点击页面新增按钮添加一个namespace 5.5.2、给微服务配置namespace
给微服务配置namespace只能通过修改配置来实现。例如修改order-service的application.yml文件
spring:cloud:nacos:server-addr: localhost:8848discovery:cluster-name: HZnamespace: d494f25a-438d-4927-bdf8-aaa9d3fc0279 # 命名空间填ID重启order-service后访问控制台可以看到下面的结果 order-service在 dev 的命名空间user-service在 public 命名空间此时访问order-service因为namespace不同会导致找不到userservice控制台会报错
5.6、Nacos与Eureka的区别
Nacos的服务实例分为两种类型 临时实例如果实例宕机超过一定时间会从服务列表剔除默认的类型。 非临时实例如果实例宕机不会从服务列表剔除也可以叫永久实例。
配置一个服务实例为永久实例
spring:cloud:nacos:discovery:ephemeral: false # 设置为非临时实例Nacos与eureka的共同点 都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测 Nacos与Eureka的区别 Nacos支持服务端主动检测提供者状态临时实例采用心跳模式非临时实例采用主动检测模式临时实例心跳不正常会被剔除非临时实例则不会被剔除Nacos支持服务列表变更的消息推送模式服务列表更新更及时Nacos集群默认采用AP方式当集群中存在非临时实例时采用CP模式Eureka采用AP方式
