微服务怎么使用消息通讯

在进行微服务开发时,我们使用Spring Cloud的消息总线组件来使用消息通讯是非常方便的。

消息服务根据消息的消费模式不同,可以分为点对点和广播型(发布/订阅)消息两种模式,开发时可以根据业务需求选择不同的模式使用。

点对点模式适用于消息生产者和消费者一一对应的方式,通讯方式如下图所示:

即由消息生产者发出的消息只能由一个消息消费者消费。

广播型消息可以由多个消息消费者同时消费,这是一种一对多的关系,通讯方式如下图所示:

上面两种消息模式的消息队列,都可以配置成持久化的消息队列,并且消息被消费时具有自动确认的功能,当一个队列被同一服务的多个实例所监听时,消息队列中的消息,将被多个实例进行均分(或争抢)消费,但不存在重复消费。

在使用Spring Cloud的开发环境中,需要使用消息总线时,引入下面依赖引用:

<!--消息总线-->

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-bus-amqp</artifactId>

</dependency>

然后在应用的配置文件application.yml中使用如下配置连接RabbitMQ服务器(这里假设RabbitMQ安装在本地上):

spring:

  rabbitmq:

    addresses: amqp://localhost:5672

    username: guest

    password: guest

对于点对点的消息,开发是很简单的。

首先,创建一个消息队列,即使用配置方式在程序启动时初始化一个消息队列:

@Configuration

public class RabbitConfig {

    @Bean

    public Queue initQueue(){

        return new Queue(“queusname”);

    }

}

点对点消息发送:

@Service

public class PtoPSender {

    @Autowired

    private AmqpTemplate amqpTemplate;



    public void send(Map<String, Object> msg){

        amqpTemplate.convertAndSend(“queusname”, msg);
    }

}

点对点消息接收:

@Component

public class Testreceiver {

    @RabbitListener(queues = "queusname")

    public synchronized void process(Map<String, Object> msg){

         System.out.println("接收到的消息:"+msg.toString());

        //消息处理

    }

}

其中,“queusname”为消息队列名称。在实际应用中,可以将消息队列名称放在配置文件中进行设置。

对于广播型的消息模式,会稍微复杂一点。但是如果我们使用Spring Cloud组件中定制的通道来设计,也会简单一些。

对于消息发布,即使用Source设置的通道:

@Service

@EnableBinding(Source.class)

public class PushSend {

    @Autowired

    @Output(Source.OUTPUT)

    private MessageChannel channel;



    public void send(Map<String, Object> msg){

        channel.send(MessageBuilder.withPayload(msg).build());
    }

}

同时在配置文件中配置发布通道:

# 广播型消息发布通道配置

spring:

  cloud:

    stream:

      bindings:

        output:

          destination: CommonMessages

          content-type: application/json

注意:上面配置的通道为“output”。

对于订阅消息,可以使用Sink定制的通道来接收:

@EnableBinding(Sink.class)

public class TestSubscribe {

    @StreamListener(Sink.INPUT)

    public synchronized void listener(String msg) {

        Map<String, Object> receiver = new Gson().fromJson(msg, new TypeToken<Map<String,Object>>(){}.getType());

     System.out.println("recerver:"+receiver.toString());

        //消息处理

    }

}

同时在配置文件中配置接收消息的订阅通道及队列:

# 广播型消息订阅队列配置

spring:

  cloud:

    stream:

      bindings:

        input:

          destination: CommonMessages

          content-type: application/json

          group: Group1

          consumer:

            durableSubscription: true

注意:上面配置的通道为“input”。

这样就相当于配置了一个持久化队列:”CommonMessages.Group1”。对于不同的订阅者,只要按照上面配置更改group的配置即可,例如:“Group2”。这样就实现了一条消息能够被多个订阅者消费的功能。

转载于:https://my.oschina.net/syic/blog/1856164

### Java微服务之间的通讯方式 #### 1. **RPC (Remote Procedure Call)** 通过远程过程调用(RPC),能够有效解耦服务,这是使用RPC的核心目标[^1]。其基本原理涉及动态代理模式的应用,在实际项目中可以通过Spring Remoting实现简单场景下的RPC需求,而像Dubbo这样的框架则适用于更复杂的分布式系统环境。 对于现代微服务体系而言,gRPC作为一种由Google主导开发的高性能RPC框架显得尤为重要[^2]。它采用Protocol Buffers(Protobuf)作为接口定义语言和序列化协议,具备以下特点: - 使用HTTP/2协议支持多路复用与流式通信,从而显著提升性能; - 提供强大的编译时类型检查机制以降低运行期错误风险; - 支持众多主流编程语言,极大促进了跨平台协作能力。 然而需要注意的是,尽管gRPC拥有诸多优势,但也存在一定的局限性,比如较高的学习门槛、相对繁琐的调试流程以及对额外依赖项的要求等。 ```java // 示例代码展示如何基于gRPC构建基础的服务端逻辑 public class GreeterServiceImpl extends GreeterGrpc.GreeterImplBase { @Override public void sayHello(HelloRequest req, StreamObserver<HelloReply> responseObserver) { String message = "Hello, " + req.getName() + "!"; HelloReply reply = HelloReply.newBuilder().setMessage(message).build(); responseObserver.onNext(reply); responseObserver.onCompleted(); } } ``` #### 2. **RESTful API** REST架构风格强调资源导向设计原则,利用标准HTTP方法操作资源状态变化。相较于传统的SOAP Web Service来说更加轻量化且易于理解实施。在Java生态系统里,借助Spring Boot框架快速搭建RESTful服务变得极为便捷高效。 虽然REST以其简洁性和广泛适用性著称,但在面对高并发实时互动场景下可能不如某些其他方案表现优越。例如当追求极致效率或者需要频繁双向数据交换的时候,则可能会考虑转向诸如WebSocket或是前面提到过的gRPC之类的技术选项。 #### 3. **消息队列(Message Queue)** 消息队列提供了一种异步通信手段,允许生产者向队列写入消息而不必立即等待消费者读取消息完成处理动作[^4]。这种特性非常适合用于解耦应用组件之间紧密联系关系的同时还能保障系统的可靠性水平。 常见的开源MQ产品有RabbitMQ、Kafka、ActiveMQ等等,它们各自针对不同业务诉求进行了优化改进。例如Apache Kafka特别擅长大规模日志收集分析任务;而RabbitMQ则因其实现AMQP协议而在灵活性方面占据一定优势地位。 --- ### 总结对比表 | 各种通讯方式优劣势比较 | 方案名称 | 主要优点 | 可能缺点 | |----------------|---------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------| | RPC | 明确区分关注点,简化编码难度 | 对于小型团队可能存在过度工程化的嫌疑 | | REST | 设计直观易懂,兼容性强 | 实时交互性能稍逊 | | gRPC | 极致速度体验,丰富的功能集 | 初学者入门曲线陡峭 | | 消息队列 | 减少阻塞现象发生几率,增强容错能力 | 增加运维管理负担 | ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值