架构图
首先是ruoyi官方的架构图
基础框架组件
API网关
API GateWay在我理解中，是整个微服务的入口。他主要用于微服务的路由和安全控制，同时还可以提供负载，缓存，限流，熔断等功能。具体的实现有：Zuul、Spring Cloud Gateway等。这些组件能够提供统一的入口来访问微服务，从而简化客户端的访问方式。
zuul与Spring Cloud Gateway选型比较
Zuul和Spring Cloud Gateway都是常见的API网关组件，二者有以下区别：
- Zuul是Netflix开源的组件，而Spring Cloud Gateway是Spring官方提供的组件，因此在社区和支持方面有一定差异。
- Zuul1是基于阻塞I/O模型实现的，而Zuul2和Spring Cloud Gateway都是基于非阻塞I/O模型实现的，因此在性能方面有一定差异。
- Spring Cloud Gateway提供了更强大和灵活的路由配置，支持路由断言和过滤器等高级功能，可以实现更细粒度的路由控制。
- Zuul在处理WebSocket等非HTTP协议方面存在一定的局限性，而Spring Cloud Gateway支持更多的协议和传输方式。
- Spring Cloud Gateway支持集成Spring Cloud的其他组件，例如Spring Cloud Security和Spring Cloud Sleuth等，可以实现更全面的微服务治理。
综上所述，选择哪种API网关组件应该根据具体的业务需求和技术栈来选择。如果需要更高的性能和更好的路由控制，可以考虑使用Spring Cloud Gateway。如果需要更成熟和稳定的解决方案，可以选择Zuul或其他的API网关组件。
关于nginx和gateway的区别
API网关和Nginx的区别在于，API网关是专门为微服务架构设计的一种组件，用于处理微服务之间的路由和安全控制，可以提供高度灵活的配置和定制化的扩展能力。而Nginx则是一款通用的Web服务器软件，虽然也可以用作反向代理和负载均衡的组件，但其主要功能是提供Web服务，而不是为微服务架构提供专门的路由和安全控制。此外，API网关通常会提供更多的微服务相关功能，例如分布式追踪、限流、熔断等，而Nginx则更适合用于传统的Web应用和静态资源的部署和管理。
服务注册与发现组件
在微服务架构中，服务的数量是庞大的，而一个业务请求会横穿多个服务。如果简单直白的理解，每个服务都需要知道其他服务的位置和状态，才能相互通信和协同工作。
但是在服务这个维度去记录其他服务的地址和端口是不合理且不优雅的。因为地址会变化，服务会扩容，所以我们需要一个横跨于所有服务之上一个维度，去用来管理服务之间的注册与发现。
而服务注册与发现组件可以将所有的微服务实例注册到服务注册中心，从而实现微服务之间的自动发现和调用。同时，服务注册与发现组件还可以提供负载均衡和故障转移等功能，以确保整个微服务架构的可用性和稳定性。
具体的实例有Consul、Eureka、zk、Nacos等。
Consul、Eureka、zk、Nacos选型对比
Consul、Eureka、Zookeeper和Nacos都是常用的服务注册与发现组件，它们有以下区别：
- Consul是一款开源的服务注册与发现组件，支持服务健康检查、KV存储、多数据中心等功能，具有较好的可扩展性和灵活性。
- Eureka是Netflix开源的服务注册与发现组件，支持客户端和服务端的负载均衡、服务健康检查等功能，具有较好的稳定性和易用性。
- Zookeeper是Apache开源的服务注册与发现组件，支持分布式协调、配置管理、分布式锁等功能，具有较好的一致性和可靠性。
- Nacos是阿里巴巴开源的服务注册与发现组件，支持服务注册、配置管理、流量管理等功能，具有较好的易用性和可扩展性。
在选型时，需要根据实际业务需求和技术栈来选择适合自己的服务注册与发现组件。如果需要较为灵活和可扩展的方案，可以考虑使用Consul；如果需要稳定性和易用性，可以选择Eureka；如果需要一致性和可靠性，可以选择Zookeeper；如果需要易用性和可扩展性，可以选择Nacos。
关于CAP理论
Consul、Eureka、Zookeeper和Nacos都有不同的AP/CP特性：
- Consul：默认情况下是CP，但可以通过调整配置来实现AP特性。它通过Raft协议来实现一致性，可以保证数据的强一致性，但在网络分区等异常情况下可能会出现服务不可用的情况。
- Eureka：默认情况下是AP，它通过心跳机制来判断服务的可用性，可以保证服务的高可用性，但在网络分区等异常情况下可能会出现服务注册信息的不一致。
- Zookeeper：默认情况下是CP，它通过ZAB协议来实现一致性，可以保证数据的强一致性，但在网络分区等异常情况下可能会出现服务不可用的情况。
- Nacos：默认情况下是AP，它通过RAFT协议来实现一致性，可以保证数据的一致性，但在网络分区等异常情况下可能会出现服务不可用的情况。
因此，在选择适合自己的服务注册与发现组件时，需要根据实际业务需求和技术栈来选择适合自己的AP/CP特性的组件。如果需要强一致性，可以选择CP组件，例如Consul和Zookeeper；如果需要高可用性，可以选择AP组件，例如Eureka和Nacos。
但是我有看过一个理论思想，服务注册与发现是优先需要保证可用性的。因为如果是CP，那么在注册中心注册实例或移除实例时，都要等待注册中心集群中的数据达到一致后，才算注册或移除成功，而这是比较耗时的。而随着业务服务的增多和扩容，这个甚至会影响整体服务的调度。
而对于AP来说，我就没有这个顾虑，最多你的请求打到了一个已经下线的服务上。而本身服务有容错和重试机制，而我们只要保证最终一致性即可。这种代价相对较小。
服务调度
在服务通过注册中心之后，我们要进行服务之间的调度。而调度据我所知有两种，一种是以http形式的RESTful API，一种是以RPC形式的调度。
区别如下：
- 通信协议不同：RESTful API通常使用HTTP协议进行通信，而RPC可以使用多种协议（如gRPC、Thrift、Dubbo等）进行通信。
- 传输数据格式不同：RESTful API使用JSON或XML等文本格式进行数据传输，而RPC使用二进制格式进行数据传输，具有更高的效率和可靠性。注意，不管是rpc还是restful，这里的对象传输，都需要序列化和反序列化，具体实现可以是Jackson、Gson、ProtoBuf等。
- 接口定义和调用方式不同：RESTful API的接口定义和调用方式相对简单，使用HTTP请求和响应进行通信，常用于Web应用的开发。而RPC需要使用IDL（接口定义语言）来定义接口，接口调用也需要使用专门的RPC框架进行封装和调用，常用于分布式系统和大型应用的开发。
- 适用场景不同：RESTful API适用于简单的、无状态的请求响应式服务，而RPC适用于需要高效、高可靠性的分布式系统和大型应用。
因此，在实际应用中，需要根据具体的业务需求和技术栈来选择合适的服务调用方式。如果需要简单的、无状态的服务，可以使用RESTful API；如果需要高效、高可靠性的服务，可以使用RPC。
OpenFegin与Dubbo的区别
两者均为RPC框架，但是好像印象中 SpringBoot用的就是Dubbo，Cloud用的就是Fegin
具体查询区别如下：
- 框架来源不同：OpenFegin是Spring Cloud官方提供的组件，而Dubbo是阿里巴巴开源的组件，因此在社区和支持方面有一定差异。
- 功能特性不同：OpenFegin提供了一系列的微服务相关功能，例如负载均衡、熔断器等，可以方便地进行服务调用和管理。而Dubbo则提供了更为丰富和灵活的功能，例如服务治理、容错、路由等，可以满足更多的业务需求。
- 适用场景不同：OpenFegin适用于轻量级的微服务架构，例如Spring Cloud和Kubernetes等，适合于Web应用和中小型企业。而Dubbo适用于大型企业级应用，可以支持更高的并发和复杂度。
综上所述，选择OpenFegin还是Dubbo应该根据具体的业务需求和技术栈来选择。如果需要轻量级的微服务架构，可以考虑使用OpenFegin；如果需要更为丰富和灵活的功能，可以选择Dubbo。
Hystrix和Sentinel
Hystrix和Sentinel都是常见的服务熔断和限流组件，它们有以下区别：
- 来源不同：Hystrix是Netflix开源的组件，而Sentinel是阿里巴巴开源的组件，因此在社区和支持方面有一定差异。
- 功能特性不同：Hystrix提供了服务熔断、线程池隔离、请求缓存等一系列的微服务相关功能，可以提高服务的可用性和稳定性。而Sentinel则提供了服务熔断、降级、限流等一系列的微服务治理功能，可以对服务进行更加精细的管理和控制。
- 适用场景不同：Hystrix适用于轻量级的微服务架构，例如Spring Cloud等，适合于Web应用和中小型企业。而Sentinel则适用于大型企业级应用，可以支持更高的并发和复杂度，同时还提供了更丰富的控制台和监控功能。
如果记得不错的话SpringCloud是默认集成了Hystrix，做的熔断和隔离，但支持不了限流。从功能的扩展性来讲，我觉得Sentinel更加合适点。
Ribbon
ribbon是Netflix开源的一款负载均衡组件，可以与RestTemplate、Feign等组件集成使用。它可以根据不同的负载均衡算法（如轮询、随机等）来分配请求到不同的服务实例，以实现服务之间的负载均衡。同时，ribbon还支持服务的故障转移和重试等功能，可以提高服务的可用性和稳定性。在微服务架构中，ribbon是一个非常常用的组件之一。
消息队列
消息、消息协议与消息队列
消息是指在计算机系统中传输的数据单元，通常用于在不同应用程序之间进行通信和交换数据。消息通常包括数据体和元数据两部分，数据体是实际需要传输的内容，元数据则包含了数据的描述信息，例如数据格式、数据类型、数据大小等。
消息协议是指在消息传输过程中所遵循的规则和标准，用于保证消息的正确性、完整性和安全性。常见的消息协议包括TCP、HTTP、AMQP、MQTT等。
消息队列是一种基于消息通信的中间件，用于在分布式系统中传输消息。它通常包括消息生产者、消息消费者、消息队列和消息协议等组件，可以实现异步消息传输、消息持久化、消息路由、消息过滤等功能，从而提高系统的可靠性、可扩展性和性能。
综上所述，消息、消息协议和消息队列是三个不同的概念，消息是数据单元，消息协议定义了消息传输的规则和标准，消息队列则是一种基于消息通信的中间件。在实际应用中，它们通常是密切相关的，用于实现分布式系统中的消息传输和通信。
消息队列的使用场景
- 异步处理：消息队列可以将请求发送到队列中，等待消费者异步消费。这样可以提高系统的并发能力和响应速度，同时还可以避免请求阻塞和资源浪费等问题。
- 流量控制：消息队列可以实现流量控制和限流等功能，可以保证系统的稳定性和可靠性，避免系统崩溃和服务不可用等问题。
- 解耦服务：消息队列可以解耦服务之间的依赖关系，每个服务只需要向消息队列发送消息即可，无需直接调用其他服务的API接口，从而提高系统的可维护性和可扩展性。
- 日志处理：消息队列可以用于日志处理，可以将日志发送到队列中，等待消费者异步消费。这样可以提高日志处理的效率和准确性，同时还可以避免日志丢失和数据不一致等问题。
- 负载均衡：消息队列可以实现负载均衡和故障转移等功能，可以根据不同的负载均衡算法将请求分配到不同的服务实例中，从而提高系统的可用性和稳定性。
其中异步，解耦在使用过程中，我们十分的熟悉
RocketMQ、RabbitMQ、Kafak
RocketMQ、RabbitMQ、Kafka是常用的消息队列中间件，它们有以下区别：
- 适用场景不同：RocketMQ适用于大规模分布式系统的消息通信，例如阿里巴巴的电商系统；RabbitMQ适用于需要高级消息队列特性和可靠性的场景；Kafka适用于高吞吐量的分布式系统，例如大规模数据处理和日志收集等场景。
- 消息传输方式不同：RocketMQ和RabbitMQ采用Push模式，即生产者将消息推送到Broker，由Broker将消息推送给消费者；而Kafka采用Pull模式，即消费者从Broker中拉取消息。
- 功能特性不同：RocketMQ和RabbitMQ支持高级消息队列特性，例如事务消息、延迟消息、死信队列等；而Kafka则支持高吞吐量和分区特性，可以实现消息的水平扩展和负载均衡等。
- 开发语言不同：RocketMQ是用Java开发的，RabbitMQ是用Erlang开发的，Kafka是用Scala开发的。
因此，在选择适合自己的消息队列中间件时，需要根据具体的业务需求和技术栈来选择适合自己的组件。如果需要高级消息队列特性，可以选择RocketMQ或RabbitMQ；如果需要高吞吐量和分区特性，可以选择Kafka。
Spring Stream
实际上我并没有具体集成哪个mq，而是使用了Spring的Stream。他默认集成了Rabbit和Kafak，当然Rocket也有提供。
Rocket MQ Stream官网
具体描述如下：
Spring Cloud Stream由一个中间件中立的核组成。应用通过Spring Cloud Stream插入的input(相当于消费者consumer，它是从队列中接收消息的)和output(相当于生产者producer，它是从队列中发送消息的。)通道与外界交流。通道通过指定中间件的Binder实现与外部代理连接。业务开发者不再关注具体消息中间件，只需关注Binder对应用程序提供的抽象概念来使用消息中间件实现业务即可。
分布式缓存
为了提高QPS和减少RT的目的，我们设计了很多方案，其中很重要和常见的的一个就是缓存。
当然缓存又会带来很多问题，诸如经典的缓存数据一致性问题。
以下是一段大佬对于高QPS下缓存的设计和理解：
redis目前是缓存的第一首选.单机可达6-8万的qps,在面对高并发的情况下,我们可以手动的水平扩容,以达到应对qps可能无线增长的场景。但是这种做法也存在弊端,因为redis是单线程的,并且会存在热点问题。虽然redis内部用crc16算法做了hash打散,但是同一个key还是会落到一个单独的机器上,就会使机器的负载增加,redis典型的存在缓存击穿和缓存穿透两个问题,尤其在秒杀这个场景中,如果要解决热点问题,就变的比较棘手。这个时候多级缓存就必须要考虑了,典型的在秒杀的场景中,单sku商品在售卖开始的瞬间,qps会急剧上升.而我们这时候需要用memeryCache来挡一层,memeryCache是多线程的,比redis拥有更好的并发能力,并且它是天然可以解决热点问题的。有了memeryCache,我们还需要localCache，本地缓存,这是一种以内存换速度的方式。本地缓存会接入用户的第一层请求,如果它找不到,接下来走memeryCache，然后走redis，这套流程下来可以挡住百万的qps.
memcache
Memcache是一种基于内存的分布式缓存系统，它可以将数据缓存在多个节点上，从而提高系统的性能和可靠性。Memcache通常用于读多写少的应用场景，例如Web应用中的页面缓存、会话缓存等。
Memcache的优点包括：
- 高速度：Memcache采用基于内存的缓存方式，速度非常快，可以大大提高系统的读写速度和响应时间。
- 分布式缓存：Memcache支持数据分片和多节点部署，可以将数据缓存在多个节点上，从而提高系统的可靠性和扩展性。
- 简单易用：Memcache的使用非常简单，只需要调用几个API就可以实现数据的缓存和读取。
Memcache的缺点包括：
- 数据不持久化：Memcache是基于内存的缓存系统，数据不具有持久化能力，一旦服务器重启或崩溃，所有的数据将会丢失。
- 功能相对简单：Memcache的功能相对简单，不支持高级的数据结构和复杂的查询操作，例如Redis支持的Sorted Set、List、Hash等数据结构。
- 不支持事务：Memcache不支持事务操作，不能保证数据的一致性和完整性，例如Redis支持的事务操作。
综上所述，Memcache是一种基于内存的分布式缓存系统，适用于读多写少的应用场景，例如Web应用中的页面缓存、会话缓存等。它具有高速度、分布式缓存和简单易用的优点，但也存在数据不持久化、功能相对简单和不支持事务等缺点。
redis与memcache的区别
Redis与Memcache是两种常用的缓存技术，它们之间有以下区别：
- 数据类型：Redis支持多种数据类型，包括String、List、Hash、Set、Sorted Set等，可以支持更丰富和复杂的数据结构；而Memcache只支持简单的键值对数据结构。
- 数据持久化：Redis支持多种数据持久化方式，包括RDB和AOF两种方式，可以将数据定期或实时保存到磁盘上，以保证数据不丢失；而Memcache不支持数据持久化，一旦服务器重启或崩溃，所有的数据将会丢失。
- 内存管理：Redis采用内存淘汰策略，可以根据不同的策略自动清理过期和冷门数据，从而保证内存的使用效率和系统的可靠性；而Memcache则采用LRU算法进行内存管理，不能自动清理过期和冷门数据。
- 分布式支持：Redis可以通过主从复制和分片技术实现数据的分布式存储和访问，可以实现高可用性和负载均衡等功能；而Memcache不支持数据分片，只能通过多个节点进行数据复制，不能实现分布式缓存。
因此，在选择Redis或Memcache作为缓存技术时，需要根据具体的业务需求和技术栈来选择适合自己的组件。如果需要支持复杂的数据结构和数据持久化，可以选择Redis；如果需要高速缓存和简单易用的特性，可以选择Memcache。
分布式计划任务调度系统
业务场景下，必然会存在定时任务进行的触达的业务场景。诸如：每日凌晨的同步数据，业务ttl定时补偿，订单30分钟后赠送积分等等。
分布式调度框架有很多：
比如：quartz、xxl-job、Elastic-Job、Saturn
quartz
quartz是一个开源的Java任务调度框架，可用于实现各种定时任务和计划任务。它支持任务调度的各种功能，如并发执行、错过执行时的处理、持久化任务状态等。在分布式环境下，quartz可以使用JDBC Job Store或Terracotta集群来实现任务调度的分布式管理和执行。具体来说，可以使用JDBC Job Store将任务存储在关系数据库中，并使用单个quartz调度程序来管理和执行任务。另一种方法是使用Terracotta集群，它可以将任务调度数据存储在Terracotta集群中，从而实现任务调度的高可用性和可扩展性。
实现分布式任务调度的关键在于任务的分配和执行。在quartz中，可以使用以下方法来实现任务的分配和执行：
- 使用JDBC Job Store：将任务存储在关系数据库中，并使用单个quartz调度程序来管理和执行任务。在此模式下，所有quartz节点都共享同一个数据库，并使用数据库锁来实现任务的互斥执行。
- 使用Terracotta集群：将任务调度数据存储在Terracotta集群中，并使用Terracotta集群中的quartz节点来管理和执行任务。在此模式下，所有quartz节点都连接到同一个Terracotta集群，并使用Terracotta集群锁来实现任务的互斥执行。
- 使用分布式消息队列：将任务放入分布式消息队列中，并使用各个quartz节点来消费和执行任务。在此模式下，所有quartz节点都连接到同一个消息队列，并使用消息队列的锁机制来实现任务的互斥执行。
以上是quartz实现分布式任务调度的一些方法，具体的选择需要根据实际情况来决定。
xxl-job
xxl-job是一款轻量级的分布式任务调度平台，可以实现分布式环境下的任务调度和管理。它基于Spring Boot开发，提供了UI界面和RESTful API接口，具有易用性和高性能。xxl-job支持多种任务类型，包括简单任务、Bean任务、Shell任务、Python任务等。它还提供了任务执行日志、任务依赖管理、任务暂停/恢复、任务分片等功能，可以帮助开发人员和运维人员更好地管理和调度任务。
xxl-job的分布式任务调度实现原理主要基于Quartz和分布式锁。xxl-job通过Zookeeper实现分布式锁，确保同一时间只有一个任务执行器可以执行同一个任务。同时，xxl-job还支持任务分片，将一个任务分成多个子任务进行并发执行，提高任务执行效率。
Elastic-Job
Elastic-Job是一款基于分布式数据库的分布式任务调度框架，它能够很好地解决分布式环境下的任务调度和管理问题。它采用了分布式数据库（例如MySQL、Oracle等）来存储任务元数据和执行日志，从而实现任务的高可用性和可靠性。同时，它还提供了易用的API和丰富的功能，例如定时任务、Cron表达式、分片策略等，以便开发人员能够快速地实现分布式任务调度。
在Elastic-Job中，任务可以分为作业（Job）和分片（Sharding）。作业是指一个独立的任务单元，例如定时任务、异步任务等。分片是指将作业分成多个小块进行并行处理，从而提高整个作业的执行效率和可靠性。在Elastic-Job中，作业和分片都可以动态地添加、删除和修改，从而满足分布式环境下任务的动态调度和管理需求。
Elastic-Job的分布式任务调度框架是基于Spring Batch和Quartz实现的，因此具有很好的扩展性和灵活性。同时，它还提供了丰富的监控和统计功能，例如作业状态统计、作业执行日志、作业执行轨迹等，以便开发人员能够实时地了解作业的运行状态和性能指标。
实现分布式任务调度的关键在于任务的分片和负载均衡。在Elastic-Job中，任务的分片是通过分片策略来实现的，例如取模分片策略、平均分片策略等。负载均衡则是通过分片项和分片服务器之间的映射关系来实现的，其中分片项是指作业被分片后的小块，分片服务器是指执行作业的服务器。通过合理的分片策略和负载均衡算法，可以实现任务的高效、均衡、可靠地执行。
Saturn
Saturn是一个分布式任务调度平台，由美团点评公司开发和维护。它基于Java语言和Spring框架构建，具有易用性、高性能和高可靠性的特点。Saturn提供了分布式任务调度、作业流程管理、作业运维监控等功能，能够帮助开发人员实现分布式任务的调度和管理。Saturn的核心是其分布式作业调度框架，它基于ZooKeeper实现分布式锁和选举机制，确保作业的可靠运行。同时，Saturn还提供了丰富的作业运维监控功能，包括作业实时监控、告警、作业历史等，能够帮助开发人员及时发现和解决问题。
容器化技术
容器，可以在服务发布的时候，进行节点动态管理和扩展，便于跟踪和定位服务的问题。一般来说，我接触到的容器化技术就是docker、k8s和Portiner
- Docker容器技术：Spring Cloud可以与Docker容器技术无缝集成，可以将应用程序和其依赖项打包为一个容器镜像，并在不同的环境中进行部署和管理。
- Kubernetes容器编排技术：Spring Cloud可以与Kubernetes容器编排技术集成，可以实现自动化的容器部署、伸缩和管理，从而提高应用程序的可靠性和可扩展性。
- Istio服务网格技术：Spring Cloud可以与Istio服务网格技术集成，可以实现微服务应用程序的流量管理、安全性和可观测性等特性。
- Spring Cloud Kubernetes：Spring Cloud Kubernetes是Spring Cloud针对Kubernetes平台提供的一系列组件，包括服务注册与发现、配置管理、负载均衡等，可以帮助开发人员更好地构建和管理基于Kubernetes的微服务应用。
总之，Spring Cloud的容器化技术可以帮助开发人员更好地构建和管理微服务应用，提高应用程序的可靠性、可扩展性和可观测性。如果你正在开发一个微服务应用程序，那么Spring Cloud的容器化技术绝对是一个值得考虑的选择。
扩展框架组件
配置中心
当超过了一定量级的服务之后，系统配置的修改和发布就会成为项目发展一个不得不关注的难点，因此就诞生了配置中心。配置中心通过集中管理服务配置，提供统一的配置拉取接口来解决因规模不断扩展导致的配置管理问题。一般提供版本管理，权限控制，灰度发布，动态刷新等功能特性来完善配置管理体系。
具体中间件如下：Spring Cloud Config、nacos、Apollo。
区别如下：
- Spring Cloud Config：适用于Spring Cloud生态系统，需要自行搭建服务器，支持Git、SVN等多种后端存储方式。
- Nacos：阿里巴巴开源的服务注册中心和配置中心，可以作为独立的配置中心使用，也可以与Nacos服务注册中心配合使用。
- Apollo：携程开源的配置中心，支持多种语言和多种环境，拥有完善的权限管理和发布流程，适合大规模分布式系统使用。
业务配置中心与服务配置中心
我需要额外说明一下，这两个东西是不一样的，业务配置中心的使用者是业务人员或者客户的IT部门，所以他应该是内嵌在系统内部，用于选择不同的业务路由分支。
而服务配置中心，是作用于整个服务的，上面也写了版本控制，权限管理等等
分布式日志
在分布式应用中，日志被分散在储存不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。所以我们使用集中化的日志管理，分布式日志就是对大规模日志数据进行采集、追踪、处理。
为什么要使用分布式日志
一般我们需要进行日志分析场景：直接在日志文件中grep、awk就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
ELK 分布式日志
实际上ELK是三款软件的简称，分别是Elasticsearch、 Logstash、Kibana组成。
-
Elasticsearch 基于java，是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
-
Kibana 基于nodejs，也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供的日志分析友好的Web 界面，可以汇总、分析和搜索重要数据日志。
-
Logstash 基于java，是一个开源的用于收集,分析和存储日志的工具。
Arthas
Arthas是一款Java诊断工具，能够实时查看Java应用程序的运行状态和日志信息，并提供了一些诊断和优化工具，如线程分析、内存分析、性能分析等。Arthas通过Java命令行工具的形式提供服务，可以方便地与Java应用程序进行集成，而且使用起来非常简单。同时，Arthas还支持远程诊断，可以通过SSH或Telnet等协议连接到远程服务器进行诊断和优化。
链路跟踪-SkyWalking
随着微服务分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如分布式服务、分布式数据库、分布式缓存等，使得后台服务构成了一种复杂的分布式网络。在服务能力提升的同时，复杂的网络结构也使问题定位更加困难。在一个请求在经过诸多服务过程中，出现了某一个调用失败的情况，查询具体的异常由哪一个服务引起的就变得十分抓狂，问题定位和处理效率是也会非常低。
分布式链路追踪就是将一次分布式请求还原成调用链路，将一次分布式请求的调用情况集中展示，比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。
为什么要使用链路追踪
链路追踪为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。
skywalking 链路追踪
SkyWalking是一个可观测性分析平台（Observability Analysis Platform 简称OAP）和应用性能管理系统（Application Performance Management 简称 APM）。
提供分布式链路追踪，服务网格（Service Mesh）遥测分析，度量（Metric）聚合和可视化一体化解决方案。
分布式事务
在微服务独立数据源的思想，每一个微服务都有一个或者多个数据源，虽然单机单库事务已经非常成熟，但是由于网路延迟和不可靠的客观因素，分布式事务到现在也还没有成熟的方案，对于中大型网站，特别是涉及到交易的网站，一旦将服务拆分微服务，分布式事务一定是绕不开的一个组件，通常解决分布式事务问题。
seata官方文档:
seata
分布式事务可以看我之前的博客
分布式事务
服务监控
要知道在正式环境情况下，服务器存在问题有的时候是难以跟踪定位的，这个时候我们需要一个服务监控平台。用来监控服务的健康和做出对应的报警。
Zabbix
Zabbix是一款开源的跨平台企业级监控解决方案，可以监控各种网络设备、服务器和应用程序的性能和可用性。它支持多种监控方式，包括SNMP、JMX、IPMI、HTTP等，提供实时监控、历史数据查询、告警等功能，可以帮助企业及时发现和解决问题，提高系统可用性和性能。在微服务架构中，Zabbix可以作为服务监控系统的一部分，用于监控微服务的运行状态和性能指标。
Prometheus
Prometheus是一款开源的监控系统，主要用于收集和存储系统的指标数据，并提供可视化和告警功能。它支持多种数据源，包括自身的客户端库、第三方的客户端库、以及各种标准的数据格式，如Prometheus自定义格式、Graphite格式等。在微服务架构中，Prometheus可以作为服务监控系统的一部分，用于监控微服务的运行状态和性能指标。它还可以与Grafana等可视化工具集成，以便实时地了解微服务的运行情况。
Grafana
Grafana是一款开源的数据可视化工具，主要用于展示和监控各种指标数据。它支持多种数据源，包括Prometheus、InfluxDB等，提供灵活的查询和可视化功能，可以帮助开发人员和运维人员更好地了解系统的运行状态和性能指标。在微服务架构中，Grafana可以作为服务监控系统的一部分，与Prometheus等监控工具集成，以便实时地了解微服务的运行情况。
扫一扫
9706
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
