1.1同步直接调用的问题:
业务调用链过长，用户等待时间长
部分组件故障会瘫痪整个业务
业务高峰期没有缓冲
业务高峰期时产生大量的异步线程，造成线程池不够用或者内存爆满
使用中间件的优势：
业务调用链短，用户等待时间短
部分组件故障不会瘫痪整个业务
业务高峰期有缓冲
业务高峰期时不会产生大量的异步线程
2.1使用中间件的作用
异步处理
系统解耦
流量削峰和流控
消息广播
消息收集
最终一致性
2.2主流的4种消息中间件
activemq,老牌，但维护较慢
rabbitmq最火，适合大小公司，各种场景通杀
rocketmq最猛，功能强，单考验公司运维能力
kafka最强，支持各种超大量数据，但消息可靠性弱
2.3rabbitmq高性能的原因
Rabbitmq底层使用Erlang实现，天生具有高性能基因
Rabbitmq在互联网和金融领域都有广泛的应用
2.4AMQP协议介绍
Broker:接受和分发消息的应用，RabbitMQ就是MessageBroker
Virtual Host:虚拟Broker，将多个单元隔离开
Connection:publisher / consumer和broker之间的tcp连接
Channel:connection内部建立的逻辑连接
在AMQP协议或者是RabbitMQ实现中，最核心的组件是Exchange，Echange有多个种类，配置多变，需要详细讲解
2.5RabbitMQ的心脏，Exchange解析
Exchange是AMQP协议和RabbitMQ的核心组件，Exchange的功能是根据绑定关系和路由键为消息提供路由，将消息转发至相应的队列
Direct Exchang(直连)交换机
Message中的Routeing key如果和Binding Key一致，Direct Exchange则将message发到对应的queue中
Fanout Exchange(扇形)交换机
每个发到Fanout Exchange的message都会分发到所有绑定的queue上去
Topic Exchange(主题)交换机
根据Routing Key及通配规则，Topic Exchange将消息分发到目标Queue中
全匹配:与Direct类似
Binding key中的# : 匹配任意个数的word
Binding key中的* : 匹配任意1个word
总结：
AMQP协议直接决定了RabbitMQ的内部结构和外部行为
对于发送者来说，将消息发给特定的Exchange
消息经过Exchange路由后，到达具体队列
2.7 RabbitMq的管理控制台
2.8命令行管理
查看状态：rabbitmqctrl status
查看绑定：rabbitmqctrl list_bingings
查看channel：rabbitmqctrl list_channels
新建用户:rabbitmqctrl add_user
修改用户密码：rabbitmqctrl change_password 说
删除用户：rabbitmqctrl delete_user
3.1 RabbitMQ消息交换的关键是什么？
消息流转流程
发送者不能直接将消息发送给最终队列，必须发送给交换机
消息根据路由规则，消息由交换机转发给队列
消费者从队列将消息取走
合理的交换机和队列设置
交换机数量不能过多，一般来说同一个业务，或者同一类业务使用同一个交换机
合理设置队列数量，一般来说一个微服务监听一个队列，或者一个微服务的一个业务监听一个队列，或者一个微服务的一个业务监听一个队列。
配置交换机类型，使用topic模式时仔细设置绑定键。
尽量使用自动化配置
将创建交换机/队列的操作固化在应用代码中，免去复杂的运维操作，高效且不易出错。
一般来说，交换机由双方同时声明，队列由接收方声明并配置绑定关系。
交换机/队列的参数一定要由双方开发团队确认，否则重复声明时，若参数不一致，会导致声明失败
你认为，为什么AMQP要设计Exchange消息流转机制？为什么不直接像微服务那样直接发送？
3.2需求分析与架构设计
一个外卖后端系统，用户可以在线下单外卖
用户下单后，可以实时查询订单进度
系统可以承受段时间的大量并发请求
使用微服务系统，组件之间充分解耦
使用消息中间件，解耦业务逻辑
使用数据库，持久化业务数据
什么是微服务架构？
将应用程序构建为松耦合、可独立部署的一组服务
服务：一个单一的、可独立部署的软件组件，实现了一些有用的功能
松耦合：封装服务的实现细节，通过API调用
0
如何拆分微服务？
根据系统操作进行微服务拆分
根据业务能力进行微服务拆分(推荐使用)
根据子域进行微服务拆分
根据业务能力进行微服务拆分
订单获取和履行—-> 订单微服务
供应商和产品管理 —->商家微服务
送餐、骑手管理—->骑手微服务
记账与结算—->结算微服务
积分管理—->积分微服务
接口需求
新建订单接口
查询订单接口
接口采用REST风格
3.3微服务的数据库设计原则
每个微服务使用自己的数据库
不要使用共享数据库的方式进行通信
不要使用外键，对于数据量非常少的表慎用索引
3.4 利用Direct开发餐厅和骑手微服务
Rest风格接口是一种HTTP接口
使用URL代表资源，如imooc.com/v1/users/345
使用HTTP方法代表动词，如GET、POST、DELETE
新建用户：
POST imooc.com/v1/users
查询用户：
GET imooc.com/v1/users
删除用户：
DELETE imooc.com/v1/users/345
若有收获，就点个赞吧
0 人点赞
