Spring Cloud-Nacos版 学习理解

注册中心 Nacos

下载安装包

bin目录输入 cmd 进入命令行，输入startup.cmd -m standalone 启动

浏览器输入 http://127.0.0.1:8848/nacos/index.html，进入启动页面

账号密码均默认nacos

服务提供者 NacosProvider、服务调用者 NacosConsumer

服务提供者 NacosProvider 注册到 nacos，服务调用者 NacosConsumer 可以通过 nacos 调用 服务提供者 NacosProvider 的 接口。

三者关系

Nacos 配置中心

集中配置

Nacos 持久化

Nacos的数据通过数据库获取

Nacos 集群

1.文件路径不能有中文字符

2.数据库连接细节是否正确，比如用的utf8，连接的url写umb8

3.检查配置文件细节是否正确配上，有时候配置细节会突然消失或者突然冒出些什么东西，很麻烦

4.Java版本是否符合，需要8即以上

理解

Nacos

Nacos 是 注册中心，服务提供者 可以把 服务 注册到 多个Nacos 上，然后需要调用服务，访问 有对应服务 的 Nacos就好，相同的服务可以部署到多个Nacos上，利用 负载均衡组件Ribbon 可以有效 分担访问压力。

也可以运行时，动态加载配置。

Riddon

Riddon 是 负载均衡组件，当部署多个Nacos注册了相同功能的服务的时候，比如查询员工人数功能，可以在项目上，设置当调用者访问这个服务时，按某个模式均衡访问，比如100次访问，50%访问在A-nacos的服务上，50%访问在B-nacos的服务上，两个nacos部署在不同的服务器，相当于用两台服务器代替一台服务器分担了访问压力。

这里可选择Ribbon的 应用策略 ，比如随机访问、轮询访问，超时重试、过滤一些多次连接失败和请求并发数过高的服务器 等策略。

Sentinel

Sentinel 是 限流与防护组件，有这些功能，限流、熔断、服务降级。

限流：比如同一时间有5000个请求，同时访问一个服务，但系统限制只能100个，这个时候 限流 可以把5000个请求降到100个，然后再允许其访问服务

熔断：服务器压力太大了，直接断开服务。场景比如，请求数太多，但服务反应很慢。或者服务冒了一堆异常或者错误。

服务降级：当服务超时或者返回异常时，设定返回某个信息，比如404，页面维护中，服务不可用啥的。

GateWay

GateWay 是 网关统一入口，比如一家商场里有很多商店（微服务），不知道在哪，需要进入商店入口（GateWay ）根据入口的引导去对应的商店寻求对应的服务。

OpenFeign

简化了微服务接收请求的过程

Dubbo

Dubbo 是 远程调用组件，可以忽略掉调用服务过程中的不方便之处。

比如，你在大餐厅点菜，但菜品（微服务）来源于不同的厨房（服务器），Dubbo像服务员他知道菜品从哪里拿，而你就只用等他上菜就完了，省略掉了从不同服务器调用服务的过程。

Spring Cloud Steam 与 RocketMQ、RabbitMQ

强化版RocketMQ、RabbitMQ，适用于 大流量高并发 场景 的消息中间件。

Spring Cloud Steam 整合 RocketMQ、RabbitMQ两种消息中间件，做即时通讯的框架。

RocketMQ是 发消息的组件，RabbitMQ 是 收消息的组件。

Kafka

Kafka 是 强化版的RocketMQ、RabbitMQ，适用于 大流量低延迟 场景 的消息中间件。

Mycat

Mycat 是 分库组件，可以把一个 大数据表 分成 多个小表 部署到 不同服务器 上，分担访问数据库的压力

Seata

Seata 是 分布式事务组件，管理不同微服务的事务，确保事务一致性。

比如你要打羽毛球，需要从两个商店（微服务）分别购买球拍和羽毛球（服务），那么Seata用于保障，当没出现两个都购买的情况时，比如就买了 拍 或者 球 可以 退这个款给你，防止影响客户体验，或者出现数据混乱，比如一个数据库记了你买了 球和拍 ，另外一个数据库不记得你买了球  和 拍。

Skywalking

Skywalking 是 微服务监控组件，上面显示实时显示各个服务的性能，比如某个微服务的各个接口最近一次返回数据速度，延迟等。

Docker

Docker 是 模拟Linux系统环境 的组件，它可以分出多个独立的Linux环境容器，用于装载 微服务的组件，比如提供A服务的Nacos装在一个容器内，提供B服务的Nacos又装在一个容器内，服务和服务按容器独立分离，出错了也不影响其他的。

比如所有的微服务（各个商店）都被打包成Docker容器。每个商店都可以在独立的容器中运行，不同容器之间相互隔离，出错了也不会影响到其他商店。这就像在购物中心里的每个商店都是独立的店铺，装修和管理各自独立。

Kubernetes（K8s）

Kubernetes 是 容器管理平台，负责管理这些Docker容器。比如，当某个商店的顾客突然增加时，K8s可以自动扩展该商店的容器数量，确保能承受流量。这就像购物中心的管理人员能根据顾客流量动态调整商店的营业面积。

Jenkins

自动部署工具，新代码一更新在git或者其他什么类似的代码管理平台，就自动的 测试、构建、部署 代码在服务器上。

整体场景：

作为顾客（服务调用者），先进入 购物中心入口（GateWay），根据入口处的引导选择进入某个商店（布置在不同服务器上不同容器的微服务组件）去购买需要的商品（调用服务），这个时候 所进入商店（已确定服务器）的服务员（Dubbo）会帮你从 商店不同柜台（不同容器上的微服务组件）上拿到你需要的商品（服务），省去了你自己找的麻烦。

但是你付款的时候，你的球拍购买成功了，但羽毛球购买失败了，没关系，贴心的商店经理Seata，把你购买成功的球拍也退掉了，直达两个一起购买成功了，经理才没退掉你的球拍或者球。作为拥有多个店铺的商店老板（服务提供者），你发现突然有5000个顾客（服务调用者）要进入你的店中购物，但，店里只能容纳100个人购物，这个时候门口保安（Sentinel）帮你拦着了4900个人，只有100个人进去了，不过你的其他店铺情况就不太好了，另一家B店铺被保安直接关门了（熔断）因为里面人太多了，挤爆了，然后保安贴了一张告示，说下次再来（服务降级）

平时你经常通过 某app(Skywalking) 查看你拥有的不同店铺的销售情况，看了数据后，看起来销售相当火爆，每个店铺都挤满了，这个时候你叫了一个销售员（Ribbon）帮你把客户引导到你的其他有相同商品的商店（相同服务的微服务组件上）上去。

商品很快卖完了你要放货在商店上，但你不想一个个自己放商品（服务）上去不同的店（微服务），因为你店比较多，这个时候你请了一个服务员(Dubbo)帮你放，你直接叫他，商品就自己上去了。

Nacos作为服务注册与配置中心，商店在启动时会向Nacos注册自己的服务，顾客在购买时也会向Nacos查询服务地址。这样，商店就像一个购物中心的导航系统，顾客可以快速找到所需服务。、

在购物中心的场景中，假设商店的数据量非常大，每个商店都存储着大量的商品信息。Mycat作为分库分表组件，可以将一个大数据库拆分成多个小数据库。这样，查询和存储的压力会分散到多个数据库上，避免单一数据库的性能瓶颈，确保系统在高并发下的稳定性。

原文地址：https://blog.csdn.net/qq_70280303/article/details/142752871

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！