分布式RPC框架
应用系统要进行分布式改造,必须要有分布式的RPC框架。
分布式RPC框架一般是下列结构:管理控制台,注册中心,服务提供方,服务消费方,服务管控。
分布式RPC框架有以下几个功能:
(1)服务注册。服务要能被发现,要先注册,注册后,服务提供方所在的机器要与注册中心保持心跳以维持自己处于一直可以提供服务的状态。否则注册中心就会踢掉机器。
(2)服务发现。服务注册后,服务消费方就要能够发现服务。服务发现的最重要的一个目标就是把服务提供方和服务消费方解耦。
(3)服务调度和负载均衡。
(4)统一的SDK封装。
分布式消息框架
在应用之间传递消息数据,那么消息中间件的接入必不可少,消息中间件主要用于异步和一个Provider多个Consumer的场景中。消息主要分为实时消息和延时消息。主要有RocketMQ和ApacheKafka等。
通过中间的消息队列可以做很多事情,但是需要注意下面几点:
(1)最终一致性。要求是不能丢消息,保证消息最终可达,如果不可达应该反馈给发送方。
(2)消息的有序性。有序性是指消息的顺序,按照时间进行排序。
实时消息
- 异步解耦
异步解耦可以分开调用者和被调用者的处理逻辑,降低系统耦合,解决处理语言之间的差异,数据结构之间的差异,以及生产者和消费者之间的速度差异,一个比较典型的场景就是流量控制,削峰填谷。 - 多消费端
一个消息被多个订阅者消费是典型的一种应用场景,例如一个订单生成会通知多个消费端对这个订单进行处理。
典型的问题是:
(1)确认消息是否被消费。出现多个消费者时,需要确认哪些消费发送成功,发送失败,需要重新发送,所以要增加消息消费确认标识。
(2)消息队列要有容错能力。当消费失败后,能够重新投递。要能够报讯一定的消息量。
延时消息
延时消息的核心是要有一个延时事件触发器,此外还必须解决消息的持久化存储问题。
一个典型的应用场景就是电影票的订单产生后,15分钟未付款,则取消该订单。
总结
所有的消息队列都必须解决最终一致性,高性能,高可靠问题。
下一章我们介绍分布式数据层。
作者:select you from me
来源:CSDN
转载请联系作者获得授权并注明出处。