国内外高校门户网站建设的成功经验与特色分析,wordpress 极简博客,凡科网站登录入,贵州网站seo目录 1.初识MQ1.1.同步调用1.2.异步调用1.3.技术选型 2.RabbitMQ2.1.安装2.2.收发消息2.2.1.交换机2.2.2.队列2.2.3.绑定关系2.2.4.发送消息 2.3.数据隔离2.3.1.用户管理2.3.2.virtual host 1.初识MQ 1.1.同步调用 之前说过#xff0c;我们现在基于OpenFeign的调用都属于是同… 目录 1.初识MQ1.1.同步调用1.2.异步调用1.3.技术选型 2.RabbitMQ2.1.安装2.2.收发消息2.2.1.交换机2.2.2.队列2.2.3.绑定关系2.2.4.发送消息 2.3.数据隔离2.3.1.用户管理2.3.2.virtual host 1.初识MQ 1.1.同步调用 之前说过我们现在基于OpenFeign的调用都属于是同步调用那么这种方式存在哪些问题呢 举个例子我们以昨天留给大家作为作业的余额支付功能为例来分析首先看下整个流程 目前我们采用的是基于OpenFeign的同步调用也就是说业务执行流程是这样的 支付服务需要先调用用户服务完成余额扣减然后支付服务自己要更新支付流水单的状态然后支付服务调用交易服务更新业务订单状态为已支付 三个步骤依次执行。 这其中就存在3个问题 第一拓展性差 我们目前的业务相对简单但是随着业务规模扩大产品的功能也在不断完善。 在大多数电商业务中用户支付成功后都会以短信或者其它方式通知用户告知支付成功。假如后期产品经理提出这样新的需求你怎么办是不是要在上述业务中再加入通知用户的业务 某些电商项目中还会有积分或金币的概念。假如产品经理提出需求用户支付成功后给用户以积分奖励或者返还金币你怎么办是不是要在上述业务中再加入积分业务、返还金币业务 。。。 最终你的支付业务会越来越臃肿 也就是说每次有新的需求现有支付逻辑都要跟着变化代码经常变动不符合开闭原则拓展性不好。 第二性能下降 由于我们采用了同步调用调用者需要等待服务提供者执行完返回结果后才能继续向下执行也就是说每次远程调用调用者都是阻塞等待状态。最终整个业务的响应时长就是每次远程调用的执行时长之和 假如每个微服务的执行时长都是50ms则最终整个业务的耗时可能高达300ms性能太差了。 第三级联失败 由于我们是基于OpenFeign调用交易服务、通知服务。当交易服务、通知服务出现故障时整个事务都会回滚交易失败。 这其实就是同步调用的级联失败问题。 但是大家思考一下我们假设用户余额充足扣款已经成功此时我们应该确保支付流水单更新为已支付确保交易成功。毕竟收到手里的钱没道理再退回去吧。 因此这里不能因为短信通知、更新订单状态失败而回滚整个事务。 综上同步调用的方式存在下列问题 拓展性差性能下降级联失败 而要解决这些问题我们就必须用异步调用的方式来代替同步调用。 1.2.异步调用 异步调用方式其实就是基于消息通知的方式一般包含三个角色 消息发送者投递消息的人就是原来的调用方消息Broker管理、暂存、转发消息你可以把它理解成微信服务器消息接收者接收和处理消息的人就是原来的服务提供方 在异步调用中发送者不再直接同步调用接收者的业务接口而是发送一条消息投递给消息Broker。然后接收者根据自己的需求从消息Broker那里订阅消息。每当发送方发送消息后接受者都能获取消息并处理。 这样发送消息的人和接收消息的人就完全解耦了。 还是以余额支付业务为例 除了扣减余额、更新支付流水单状态以外其它调用逻辑全部取消。而是改为发送一条消息到Broker。而相关的微服务都可以订阅消息通知一旦消息到达Broker则会分发给每一个订阅了的微服务处理各自的业务。 假如产品经理提出了新的需求比如要在支付成功后更新用户积分。支付代码完全不用变更而仅仅是让积分服务也订阅消息即可 不管后期增加了多少消息订阅者作为支付服务来讲执行问扣减余额、更新支付流水状态后发送消息即可。业务耗时仅仅是这三部分业务耗时仅仅100ms大大提高了业务性能。 另外不管是交易服务、通知服务还是积分服务他们的业务与支付关联度低。现在采用了异步调用解除了耦合他们即便执行过程中出现了故障也不会影响到支付服务。 综上异步调用的优势包括 耦合度更低性能更好业务拓展性强故障隔离避免级联失败 当然异步通信也并非完美无缺它存在下列缺点 完全依赖于Broker的可靠性、安全性和性能架构复杂后期维护和调试麻烦 1.3.技术选型 消息Broker目前常见的实现方案就是消息队列MessageQueue简称为MQ. 目比较常见的MQ实现 ActiveMQRabbitMQRocketMQKafka 几种常见MQ的对比 RabbitMQActiveMQRocketMQKafka公司/社区RabbitApache阿里Apache开发语言ErlangJavaJavaScalaJava协议支持AMQPXMPPSMTPSTOMPOpenWire,STOMPREST,XMPP,AMQP自定义协议自定义协议可用性高一般高高单机吞吐量一般差高非常高消息延迟微秒级毫秒级毫秒级毫秒以内消息可靠性高一般高一般 追求可用性Kafka、 RocketMQ 、RabbitMQ 追求可靠性RabbitMQ、RocketMQ 追求吞吐能力RocketMQ、Kafka 追求消息低延迟RabbitMQ、Kafka 据统计目前国内消息队列使用最多的还是RabbitMQ再加上其各方面都比较均衡稳定性也好因此我们课堂上选择RabbitMQ来学习。 2.RabbitMQ RabbitMQ是基于Erlang语言开发的开源消息通信中间件官网地址 Messaging that just works — RabbitMQ 接下来我们就学习它的基本概念和基础用法。 2.1.安装 我们同样基于Docker来安装RabbitMQ使用下面的命令即可 docker run -e RABBITMQ_DEFAULT_USERshenyang -e RABBITMQ_DEFAULT_PASS1 23456 -v mq-plugins:/plugins --name mq --hostname mq -p 15672:15672 -p 5672:5672 --network hmall -d rabbitmq:3.8-management[rootcentos ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE mysql 8.0.32 412b8cc72e4a 8 months ago 531MB redis latest 31f08b90668e 8 months ago 117MB rabbitmq 3.8-management 85e83aca5d60 2 years ago 249MB canal/canal-server v1.1.5 0c7f1d62a7d8 2 years ago 874MB本地镜像命令 要启动RabbitMQ镜像并映射管理界面端口默认是15672同时设置用户和密码你需要使用以下的 docker run 命令。这里我假设你的RabbitMQ镜像标签是 3.8-management。 首先你需要为RabbitMQ设置环境变量来定义默认用户和密码。这可以通过在 docker run 命令中添加 -e 参数来实现 docker run -d --name myrabbitmq \-e RABBITMQ_DEFAULT_USERshenyang \-e RABBITMQ_DEFAULT_PASS123456 \-p 15672:15672 \rabbitmq:3.8-management下面是每个选项的解释 -d: 运行容器在后台detached mode。--name myrabbitmq: 给容器命名为 “myrabbitmq”。-e RABBITMQ_DEFAULT_USERshenyang: 设置环境变量来创建用户 “shenyang”。-e RABBITMQ_DEFAULT_PASS123456: 设置环境变量来为用户 “shenyang” 设置密码 “123456”。-p 15672:15672: 映射本地机器的15672端口到容器中的15672端口。该端口用于RabbitMQ管理界面。rabbitmq:3.8-management: 指定要运行的镜像名称和标签。 运行这个命令后将会创建一个后台运行的容器在本地15672端口提供RabbitMQ服务。你可以通过 http://localhost:15672 访问管理界面并使用用户名 “shenyang” 和密码 “123456” 登录。 可以看到在安装命令中有两个映射的端口 15672RabbitMQ提供的管理控制台的端口5672RabbitMQ的消息发送处理接口 安装完成后我们访问 http://192.168.193.141:15672即可看到管理控制台。首次访问需要登录默认的用户名和密码在配置文件中已经指定了。 登录后即可看到管理控制台总览页面 在这里插入图片描述 RabbitMQ对应的架构如图 其中包含几个概念 **publisher**生产者也就是发送消息的一方**consumer**消费者也就是消费消息的一方**queue**队列存储消息。生产者投递的消息会暂存在消息队列中等待消费者处理**exchange**交换机负责消息路由。生产者发送的消息由交换机决定投递到哪个队列。**virtual host**虚拟主机起到数据隔离的作用。每个虚拟主机相互独立有各自的exchange、queue 上述这些东西都可以在RabbitMQ的管理控制台来管理。 2.2.收发消息 2.2.1.交换机 我们打开Exchanges选项卡可以看到已经存在很多交换机 我们点击任意交换机即可进入交换机详情页面。仍然会利用控制台中的publish message 发送一条消息 这里是由控制台模拟了生产者发送的消息。由于没有消费者存在最终消息丢失了这样说明交换机没有存储消息的能力。 2.2.2.队列 我们打开Queues选项卡新建一个队列 命名为hello.queue1 再以相同的方式创建一个队列密码为hello.queue2最终队列列表如下 此时我们再次向amq.fanout交换机发送一条消息。会发现消息依然没有到达队列 怎么回事呢 发送到交换机的消息只会路由到与其绑定的队列因此仅仅创建队列是不够的我们还需要将其与交换机绑定。 2.2.3.绑定关系 点击Exchanges选项卡点击amq.fanout交换机进入交换机详情页然后点击Bindings菜单在表单中填写要绑定的队列名称 相同的方式将hello.queue2也绑定到改交换机。 最终绑定结果如下 2.2.4.发送消息 再次回到exchange页面找到刚刚绑定的amq.fanout点击进入详情页再次发送一条消息 回到Queues页面可以发现hello.queue中已经有一条消息了 点击队列名称进入详情页查看队列详情这次我们点击get message 可以看到消息到达队列了 这个时候如果有消费者监听了MQ的hello.queue1或hello.queue2队列自然就能接收到消息了。 2.3.数据隔离 2.3.1.用户管理 点击Admin选项卡首先会看到RabbitMQ控制台的用户管理界面 这里的用户都是RabbitMQ的管理或运维人员。目前只有安装RabbitMQ时添加的itheima这个用户。仔细观察用户表格中的字段如下 Nameshenyang也就是用户名Tagsadministrator说明shenyang用户是超级管理员拥有所有权限Can access virtual host /可以访问的virtual host这里的/是默认的virtual host 对于小型企业而言出于成本考虑我们通常只会搭建一套MQ集群公司内的多个不同项目同时使用。这个时候为了避免互相干扰 我们会利用virtual host的隔离特性将不同项目隔离。一般会做两件事情 给每个项目创建独立的运维账号将管理权限分离。给每个项目创建不同的virtual host将每个项目的数据隔离。 比如我们给测试用例创建一个新的用户命名为shenjie 在这里插入图片描述 你会发现此时hmall用户没有任何virtual host的访问权限 别急接下来我们就来授权。 2.3.2.virtual host 我们先退出登录 切换到刚刚创建的shenjie用户登录然后点击Virtual Hosts菜单进入virtual host管理页 可以看到目前只有一个默认的virtual host名字为 /。 我们可以创建一个单独的virtual host而不是使用默认的/。 创建完成后如图 由于我们是登录shenjie账户后创建的virtual host因此回到users菜单你会发现当前用户已经具备了对/shen这个virtual host的访问权限了 此时点击页面右上角的virtual host下拉菜单切换virtual host为 /hmall 然后再次查看queues选项卡会发现之前的队列已经看不到了 这就是基于virtual host 的隔离效果。