理想主义的花最终会盛开在浪漫主义的土壤里，我的热情永远不会熄灭在现实的平凡之中，我们终将上岸，阳光万里。

Spring Cloud是一个用于构建分布是系统和微服务架构的开发工具集合。Spring Cloud为开发人员提供了一套完整的工具，用于构建和管理分布式系统和微服务架构。它的各个组件可以根据项目的需要进行选择和集成，从而帮助开发团队更容易地构建高可用、可扩展的微服务应用程序。

在项目中是使用了Gateway做统一的请求的入口，以及统一的跨域处理以及统一的token校验。但是这些工作都是之前的同事来做的，正好在新项目中也需要使用其进行统一的token校验。本着对Gateway更精进一步所以博主就对Gateway进行了较为全面的学习了解，包括动态路由、自定义过滤器、token校验和续活。

本篇博客主要是对于Spring Boot Admin的基本认识和基本运用，通过本篇博客能够对Spring Boot Admin有一个宏观认知和能够快速上手。Spring Boot Admin还可以设置通知可报警，本篇博客并没有涉及到。

目前开发的项目正是使用sleuth+zipkin的方式进行的链路追踪，为了对sleuth+zipkin这个技术点加深认识。博主对其进行了理论学习和实践。

目前开发的项目其微服务之间的熔断处理方式使用的就是Hystrix的方式，为了更加的体会到它代码的便捷和高效，所以博主对Hystrix进行了再次学习和实践，加强对Hystrix的整体理解。

在Spring Cloud中是OpenCluod的步骤主要是，引入openFeign依赖；启动类添加开启openFeign客户端；声明与服务端相同的方法并添加对应注册；需要注意根据项目情况配置调用服务的超时时间。

Spring Cloud Ribbon它是一个基于HTTP和TCP的客户端负载均衡工具，它是基于Netflix Ribbon实现的。通过Spring Cloud的封装，可以让我们轻松的面向服务的REST模板请求自动转换为客户端负载均衡的服务调用。Ribbon主要干什么工作：它用在服务消费者需要调用多个相同功能的服务提供者实例时，帮助决定选择哪个服务提供者实例来完成调用。Ribbon可以通过多种负载均衡策略（随机、轮询、加权 、iphash）等方式，将请求分配到不同的服务实例上，以实现负载均衡和高可用。

目前公司项目使用的注册中心主要是Spring Cloud Alibaba的Nacos做的注册中心和配置中心。之前也是对Nacos的基本原理通过手写代码的方式进行了实现。出于对于Eureka的好奇所以就对Spring Cloud Neflix的Eureka进行理论学习和实践。Eureka是一个注册发现中心，Eureka是Netflix公司开源的一个服务注册与发现的组件。

在实际项目开发过程中，目前负责开发的系统整体的架构采用的是微服务架构。对于微服务架构的认识只是停留在应用层面上，对于微服务的全貌并不是很清晰。最近想要对微服务的认知上更近一步，所以就重新梳理了一下微服务的基础知识。例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。

之前在项目开发的过程中，对于Nacos的理解停留在实际运用层面。但是仅仅停留在运用层面是不够的。所以就对nacos的基本原理进行了理论学习，并且对nacos的服务注册包括健康检查机制（心跳机制），nacos的配置管理进行了代码实现。项目整体结构：1.有服务A和服务B分别集成了nacosSDK（类似与此前的项目引入了nacos的相关依赖）；2.nacosService服务端中分别有两个核心的服务注册和配置管理。项目框架为spring boot框架配置文件具体类nacosSDK代码pom文

arpro生产部署了两台服务器，进行负载。都用的是同一个nacos命名空间。只更新了一台。导致请求到了没有更新的那一台所以出现了404问题。OpenFeign是Spring Cloud对Feign的二次封装，在Feign的基础而上支持了Spring MVC的注解。OpenFeign的@FeignClient可以解析Spring MVC的@RequestMapping @GetMapping 和 @PostMapping 等等。对生产环境需要有一份敬畏之心。

发布确认是解决消息不丢失的重要环节，在设置队列持久化、消息持久化的基础上，设置发布确认，一旦生产者投递消息之后，如果Broker接收到消息，会给生产者一个应答。生产者进行接收应答，用来确认这条消息是否正常发送到Broker。生产者也可以根据收没有收到这条消息的应答进行相应的处理。在某些应用程序中，确保发布的消息到达代理非常重要。发布者确认RabbitMQ的特性可以帮助满足这一要求。发布者确认本质上是异步的，但也可以同步地处理它们。没有确定的方法来实现发布者确认，这通常归结于应用程序和整个系统中的约束。

通过本篇博客能够简单使用RabbitMQ的主题模式。本篇博客主要是博主通过官网总结出的RabbitMQ主题模式。其中如果有误欢迎大家及时指正。Topic模式与Direct模式相比，他们都可以根据Routing key把消息路由到对应的队列上，但是Topic模式相较于Direct来说，它可以基于多个标准进行路由。也就是在队列绑定Routing key的时候使用通配符。这使我们相较于Direct模式灵活性更大。

通过本篇博客能够简单使用RabbitMQ的路由模式。本篇博客主要是博主通过官网以及学习他人的博客总结出的RabbitMQ发布订阅模式。其中如果有误欢迎大家及时指正。

通过本篇博客能够简单使用RabbitMQ的发布订阅模式。本篇博客主要是博主通过官网以及学习他人的博客总结出的RabbitMQ发布订阅模式。其中如果有误欢迎大家及时指正。

学习一门知识需要亲自动手去验证去证明这种方式是可行了，这样对于这个知识点才算是理解的更深。按照这样做一定行，而不是应该可以，大概可以吧。

本篇博客主要是实现RabbitMQ最简单的模式，一个生产者，一个队列，一个消费者。通过本篇博客能够掌握RabbitMQ最基本的运用。本篇博客主要学习至RabbitMQ官网的教程，RabbitMQ官网教程地址入门教程选择最简单的模式，本篇博客选择的是Java语言入门教程只是简单的运用，里面的具体细节是没有具体分析的。但是能够起到初步接触和使用RabbitMQ进行消息的存储、转发。

操作系统：CentOS Stream 9 64位安装RabbitMQ版本：目前官网最新版本3.11.6安装Erlang版本：与RabbitMQ3.11.6配套的Erlang最新版本25.2在安装RabbitMQ之前，需要安装Erlang/OTP支持的版本。RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的。本篇博客主要是阅读的RabbitMQ官网进行的安装操作，并借此总结的博客。

如有一个电商交易的场景，用户下单之后调用库存系统减库存，然后调用物流系统进行发货，如果刚开始交易，库存，物流都是属于一个系统，那么他们之间就是接口调用。但是随着系统的发展，各个模块业务越来越庞大、业务逻辑越来越复杂，这个时候就必然要做服务化和业务拆分。这个时候就需要考虑这些系统之间是如何交互的。首先想到的就是RPC（Remote Procedure Call），但是随着系统的发展，可能一笔交易后序需要调用几十个接口位于不同系统的接口，比如短信服务、邮件服务等等，这个时候就需要消息中间件来解决问题了。