(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)

   传统的单体框架,已经不满足目前公司战略规划要求,近几年“微服务“ 这个字眼,出现的越来越频繁,虽然有过一年多微服务项目经验,也很难把微服务解释清楚,到底何为微服务?

   Martin Fowler曾在其blog上发表了”Microservices“的文章,正式提出了微服务架构,对于微服务的解释,他的定义为:微服务架构是一种架构模式,他 提倡将单一应用程序,划分为一个个独立的服务,服务之间相互协调,相互配合,为用户提供最终价值。

来一张图,感受一下微服务的魅力~ 将传统一个独立的应用程序(一个程序包),划分为一个个独立的微服务(多个程序包)。

每个服务可以单独部署,启动,停止等。

(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)_第1张图片

部署上述微服务常用到的组件有:zookeeper redis rabbitmq,市面上组件很多,为什么在选型上定了这几个组件呢,肯定是他们几个有过人之处吧~

下面简单概述这几个中间件,入门级别的介绍,来吧,开始展示~

一:关于Rabbitmq

rabbitmq 基本概念

MQ 全称为 Message Queue,即消息队列,RabbitMQ是一种消息中间件,用于处理来自客户端的异步消息。服务端将要发送的消息放入到队列池中。接收端可以根据RabbitMQ配置的转发机制接收服务端发来的消息。RabbitMQ依据指定的转发规则进行消息的转发、缓冲和持久化操作,主要用在多服务器间或单服务器的子系统间进行通信,是分布式系统标准的配置。mq 消息队列其主要作用是异步,削峰 解耦。

关于rabbitmq 优势,为什么会选择MQ?

1、使用简单,功能强大

2、基于 AMQP 协议

3、SpringBoot 默认已集成 RabbitMQ

4、网上资料全面,讨论活跃。

5、部署简单,运维简单,方便运维。

MQ的应用场景:异步,应用解耦,流量削峰

我们以系统注册功能,简单比对传统模式和使用消息队列mq有什么区别。以便我们更好的理解mq的异步,解耦,削峰。

异步:

系统注册功能需要投资人(后面就简称靓仔)在系统注册页面填写个人信息,注册成功后会给靓仔发短信,发邮件等操作。 如果注册10s 发短信10s 发邮件10s ,整个流程下来需要30s,如果某个时间段注册的人数较多,靓仔将等待更长时间。注册过程中,短信平台或者邮件平台服务器出现错误,会直接暴露给靓仔,会导致注册失败,影响体验。实际上,将注册信息写入数据库后,发送注册邮件,在发送注册短信,并不是必须的,它只是一个通知,而这种做法让靓仔等待没有必要的。缺点:浪费时间,页面卡死或报错直接暴露给用户(想想每年双十一抢单的我们,嘤嘤嘤 提交了十次好不容易提交成功了订单 却提示,超时,服务异常,无效。5555555)(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)_第2张图片

引入消息队列MQ后,把发送邮件,短信不是必要的业务逻辑异步处理,靓仔注册信息入库后,发送到消息队列服务器,那么调用链路也就可以到此结束,靓仔可以进行其他业务操作。不用等待发送短信,邮件通知。
短信,邮件平台出现错误,不会影响靓仔注册。mq监听到发送短信,邮件的信息后,以异步方式完成短信,邮件通知。异步处理的优势:将不必要同步处理,且耗时的操作有队列通知接收方进行异步处理,提高应用程序响应时间,提高用户体验

(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)_第3张图片

应用解耦(降低高耦合)

传统模式:双十一下单,前端系统直接调用后台服务。前端与后台存在高耦合,当后台出现故障时,订单将失败。

(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)_第4张图片

使用mq用户通过前端界面下单,前端系统完成持久化处理,将消息写入消息队列,返回前端下单成功。后台系统:读取订单的消息,获取下单信息,进行库操作。就算后台系统出现故障,消息列队也能保证消息的可靠投递,不会导致消息丢失。

(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)_第5张图片

流量削峰

  场景:以双十一秒杀抢购为例,一般会因为订单流量过大,导致应用挂掉,为了解决这个问题,在应用前端加入消息队列,起到缓冲作用可以控制活动人数,可以缓解短时间的高流量压垮应用。

(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)_第6张图片

简单消化上述知识之后,我们来浅浅了解一下,mq工作原理。

MQ工作原理:生产者、消费者和队列

发送方将消息发送到mq. 消费方监听这个mq. 一般两方都要规定一个key.

这样能保证我的消息不会被别的人消费,保证信息的私密性。

消费方监听到mq,马上处理这条消息,处理完消息删除。

(未完待续)浅谈微服务以及 常用中间件( zookeeper redis rabbitmq)_第7张图片

1.Channel(信道):启动应用程序后,会和mq之间创建一个TCP连接,并通过mq的ip,用户名,密码进行认证。连接成功之后,应用和mq之间就创建了一个channel(AMQP信道,我理解为信息管道),后面信息发布和消息传递都是通过channel信道完成。

2.Producer(消息的生产者):消息的创建者,负责创建和推送数据到消息服务器;
3.Consumer(消息的消费者):消息的接收方,用于处理数据和确认消息;
4.Message(消息):消息由消息头和消息体组成。消息体是不透明的,而消息头则由一系列的可选属性组成,这些属性包括routing-key(路由键)、priority(消息优先权)、delivery-mode(是否持久性存储)等。
5.Routing Key(路由键):消息头的一个属性,用于标记消息的路由规则,决定了交换机的转发路径。最大长度255 字节。
6.Queue(消息队列):存储消息的一种数据结构,用来保存消息,直到消息发送给消费者。它是消息的容器,也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面,等待消费者连接到这个队列将消息取走。需要注意,当多个消费者订阅同一个Queue,这时Queue中的消息会被平均分摊给多个消费者进行处理,而不是每个消费者都收到所有的消息并处理,每一条消息只能被一个订阅者接收。

7.Exchange(交换器|路由器):提供Producer到Queue之间的匹配,接收生产者发送的消息并将这些消息按照路由规则转发到消息队列。交换器用于转发消息,它不会存储消息 ,如果没有 Queue绑定到 Exchange 的话,它会直接丢弃掉 Producer 发送过来的消息。交换器有四种消息调度策略(下面会介绍),分别是fanout, direct, topic, headers。
8.Binding(绑定):用于建立Exchange和Queue之间的关联。一个绑定就是基于Binding Key将Exchange和Queue连接起来的路由规则,所以可以将交换器理解成一个由Binding构成的路由表。
9.Binding Key(绑定键):Exchange与Queue的绑定关系,用于匹配Routing Key。最大长度255 字节。
10.Broker:RabbitMQ Server,服务器实体。

二: 关于ZooKeeper介绍:

ZooKeeper 是 Apache 软件基金会的一个软件项目,它为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。

ZooKeeper 的架构通过冗余服务实现高可用性。

Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。

一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

在了解zk之前,我们先简单介绍 关于分布式应用

在传统单体架构的系统中,我们部署前台,后台应用,可能需要几个小时,如果遇到复杂问题,卡三天也是有的。(比如常见的各种配置错误,权限问题,人工误操作导致的各种异常),而分布式应用自动部署通过使用系统计算力,可以在几分钟内完成部署或升级。(同时部署一路或二十路,效率是一样的。)曾经部署过一家银行客户的大概30多台应用,也就用了半小时吧(傲娇)

redis。。。

太难了,---未完待续20200929

你可能感兴趣的:(微服务5.0)