NetTree

微服务概念 [引用] Microservice architectures are the ‘new normal’. Building small, self-contained, ready to run applications can bring great flexibility and added resilience to your code. Spring Boot’s many purpose-built features make it easy to build and run your microservices in production at scale. And don’t forget, no microservice architecture is complete without Spring Cloud ‒ easing administration and boosting your fault-tolerance. [说明] 微服务是一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。 每个服 ...

在了解分布式微服务之前，请先了解Dubbo的核心思想。 SpringCloud 全家桶 1 微服务入门 2 服务注册与发现 Eureka、Zookeeper、Consul 3 服务调用 Ribbon、OpenFeign 4 服务熔断与降级 Hystrix 5 服务网关 Gateway 6 服务配置 Config 7 消息总线 Bus 8 消息驱动 Stream 9 分布式请求链路追踪 Sleuth SpringCloudAlibaba 全家桶 SpringCloud Alibaba 中文文档 服务限流降级：默认支持Servlet、Feign、RestTemplate、Dubbo和RocketMQ限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级Metrics监控 服务注册与发现：适配Spring Cloud服务注册与发现标准，默认集成Ribbon的支持 分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新 消息驱动能力：基于SpringCloudStream为微服务应用构建新消息驱动能力 阿里云对象存储：阿里云提供的海量、安全、低 ...

Publisher confirms 是 RabbitMQ 实现可靠发布的扩展。当在信道上启用 publisher confirms时，客户端发布的消息将由代理异步确认，这意味着它们已在服务器端得到处理。 在本教程中，我们将使用 publisher confirms 来确保发布的消息已安全到达代理。我们将介绍使用发布者确认的几种策略，并解释它们的优缺点。 Enabling Publisher Confirms on a Channel Publisher confirms 是对 AMQP 0.9.1 协议的 RabbitMQ 扩展，因此默认情况下不会启用。 Publisher confirms 是通过 confirmSelect方法在通道级别启用的： 12Channel channel = connection.createChannel();channel.confirmSelect(); 必须在预期使用 publisher confirms 的每个通道上调用此方法。确认功能只应启用一次，而不是发布的每条信息。 Strategy #1: Publishing Messages In ...

在本篇中我们将使用 RabbitMQ 构建一个 RPC 系统：一个客户端和一个可扩展的 RPC 服务器。由于我们没有任何值得分发的耗时任务，因此我们将创建一个返回斐波那契数字的虚拟 RPC 服务。 Client interface为了说明如何使用 RPC 服务，我们将创建一个简单的客户端类。它将公开一个名为 call的方法，该方法发送 RPC 请求并阻塞，直到收到应答为止： 123FibonacciRpcClient fibonacciRpc = new FibonacciRpcClient();String result = fibonacciRpc.call("4");System.out.println( "fib(4) is " + result); Callback queue一般来说，通过 RabbitMQ 进行 RPC 非常简单。客户端发送请求消息，服务器回复响应消息。为了接收响应，我们需要随请求发送一个callback队列地址。我们可以使用默认队列。 12345678910callbackQueueName = channel. ...

Topic exchange发送到 topic exchange 的消息不能有任意的 routing_key—它必须是一个用点分隔的单词列表。这些单词可以是任何内容，但通常会指定与信息相关的一些特征。 A few valid routing key examples, there can be as many words in the routing key as you like, up to the limit of 255 bytes. stock.usd.nyse、nyse.vyw、quick.orange.rabbit。路由密钥的字数不限，最多 255 字节。 binding key 的形式也必须相同。 topic exchange 背后的逻辑与直接交换类似—使用特定routing key发送的消息将被传送到所有使用匹配binding key 绑定的队列。不过，binding key 有两种重要的特殊情况： * (star) can substitute for exactly one word. # (hash) can substitute for zero o ...

Direct exchangedirect exchange路由算法 -消息会进入binding key 与消息routing key完全匹配的队列。 可以看到Direct exchange X 绑定了两个队列。第一个队列的绑定键为orange，第二个队列有两个绑定键，一个绑定键为black，另一个绑定键为green。 在此情况下，如果发布到交换机的消息routing key 为orange，则会被路由到队列 Q1。routing key 为black或green的消息将进入 Q2，其他消息都将被丢弃 Multiple bindings 用同一个binding key绑定多个队列是完全合法的。在我们的例子中，我们可以用binding key black 在 X 和 Q1 之间添加一个绑定。在这种情况下，direct exchange 将像fanout exchange 一样，向所有匹配队列广播消息，routing key为 black 的消息将同时发送到 Q1 和 Q2。 Emitting logs我们和以往一样继续使用日志Demo，不同的是将fanout换成direct。我们将 t ...