（未完待续）浅谈微服务以及 常用中间件（ zookeeper redis rabbitmq）_dzookeeper和mq的关系

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

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

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

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

部署上述微服务常用到的组件有：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）

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

应用解耦（降低高耦合）

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

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

流量削峰

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

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

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

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

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

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

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