消息中间件、分布式、集群、负载均衡简要分析
之间上过云计算和大数据相关的课程，那时候就集群、分布式傻傻分不清，最近在慕课网学习消息中间件，就想好好整理一下他们之间的关系，以及使用的情景。
本篇文章主要参考自分布式、中间件和消息队列、集群和分布式与集群的区别是什么？
一、单机结构
相信大家最常见的就是单机结构的系统了，比如大学里的大作业，虽然不一定部署到服务器上，但所有的业务功能全部放在一起，一台机器解决所有问题，这就是所谓的单机结构。
如果业务全部部署到一个服务器，访问的人数一多，或者业务功能继续增长，就容易导致服务器响应的时间越来越长，甚至阻塞，简单来说，
一个超市就是一个服务器，一个人是一个请求，某天超市大优惠，无数人想挤进来，然而只有一个门，许多人只能挤在门口，半天进不去。
此时，很容易就想到，多开几个门 另外开几个超市，然后集群就出现了。（本来想用多开几个门做比喻的，但好像是多开几个超市比较合适？？）
二、集群
集群：同一个业务，部署在多台服务器上，这个就叫做集群。
实际上就是将单机结构上的业务，拷贝到多台服务器上，这样每个服务器被称为 “ 节点 ” ，这样就能允许更多人向服务器发送请求，允许的最大值是一台服务器的好几倍，（有几台服务器就有多少倍）。
当然，如果等一台服务器满了才将请求转移到另一台服务器，这样会让第一台总是承担最大压力，会导致业务处理速度效率很低，因此我们单独需要一台服务器进行负载均衡，也就是把请求均匀的分摊到不同的服务器中，减轻服务器压力，提高服务器的处理速度，而且这样做以后，哪怕一台服务器挂了，负载均衡服务器就会将请求转发到别的服务器来接受请求，不会使得整个系统瘫痪，
现在常用的负载均衡服务器是Nginx，
如果随着系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用分布式了。
三、分布式
分布式：一个业务被拆成多个子业务，部署在多台服务器上
当集群无法满足业务需求时，业务耦合度高，需要降低各功能模块的耦合度，因此就对一个大系统进行拆分成小系统，单独部署，易于维护，这就产生了分布式。
分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”，这些子系统能够独立运行在web容器中。分布式结构其实也是微服务的一种。
分布式里面，每一台服务器实现的功能是有差别的，分布式每台服务器功能加起来，才是完整的业务。
举个例子：
一个电商网站有订单模块，浏览模块，个人资料模块，商品模块这几个模块，我们可以将这些模块分离开来，每个模块在不同的服务器上，这样当需要对某个模块进行维护时，单独维护一个模块就行了，不需要对别的模块进行修改，只需要注意他们之间传递消息不变即可。
分布式架构优势：
1，单个服务宕机不影响别的服务正常运行！
2，单个节点所有的负载分布均衡到了多台服务器上！
3，各服务之间相互透明，实现解耦！
对于开发的新的系统，推荐使用分布式架构，这样能降低后期维护的成本，而对于一些老系统来说，实现分布式架构就要对旧代码进行大量的修改，所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，这需要深思熟虑、权衡投入产出比。
注意：
分布之后问题来了，以前的单一系统，所有服务都在同一个机器，在同一个内存里面，直接调用即可；
但现在分布在不同的jvm中，怎么调用呢？或者说数据怎么传输？ –消息中间件应运而生！
四、消息中间件
中间件：将具体业务和底层逻辑解耦的软件，解决的就是分布式系统之间消息传递的问题。
一个消息需要有一个生产者生产消息，一个消费者接收处理消息，由生产者来指定消费者，保证消息能到达消费者处。
消息中间件，顾名思义，就是处于消息传输的过程中的一个节点。生产者将消息发送到消息中间件，消息中间件进行落库处理（中间件会把消息当作队列保存下来），消费者开启消息监听，以此从消息中间件中获取传给自己的消息。
例子：
我是做网上商城的，有一个短信系统，当客户下了一个订单之后，通知客户你下单成功。
当订单量比较小的时候，只需要调用发送短信的接口就可以了。
但是如果订单量大了之后呢，并且短信发送晚个一两分钟也没有什么问题，那么就可以使用消息中间件：把待发送的短信发送到消息队列里面，短信系统从消息队列中取出短信进行发送就可以了。
而且还有一个好处：如果短信系统挂掉了，短信消息保存在消息中间件里面不会丢失，等短信系统恢复了之后，继续短信发送即可。
现在常用的消息中间件由：ActiveMQ，RabbitMQ，Kafka
上一张我自己想象的图：
每个模块都有一个集群，这几个集群又通过消息中间件组合成分布式，最后用户通过负载均衡发送请求到系统中。
以上是我个人理解画出来的，如果错误欢迎指出