一、云计算的前世今生
所有的新事物都不是突然冒出来的，都有前世和今生。云计算也是IT技术不断发展的产物。 要理解云计算，需要对IT系统架构的发展过程有所认识。 请看下
IT系统架构的发展到目前为止大致可以分为3个阶段：
1、 物理机架构 这一阶段，应用部署和运行在物理机上。 比如企业要上一个ERP系统，如果规模不大，可以找3台物理机，分别部署Web服务器、应用服务器和数据库服务器。 如果规模大一点，各种服务器可以采用集群架构，但每个集群成员也还是直接部署在物理机上。 我见过的客户早期都是这种架构，一套应用一套服务器，通常系统的资源使用率都很低，达到20%的都是好的。
2、虚拟化架构 决定了物理服务器的计算能力越来越强，虚拟化技术的发展大大提高了物理服务器的资源使用率。 这个阶段，物理机上运行若干虚拟机，应用系统直接部署到虚拟机上。 虚拟化的好处还体现在减少了需要管理的物理机数量，同时节省了维护成本。
3、云计算架构 虚拟化提高了单台物理机的资源使用率，随着虚拟化技术的应用，IT环境中有越来越多的虚拟机，这时新的需求产生了： 如何对IT环境中的虚拟机进行统一和高效的管理。 有需求就有供给，云计算登上了历史舞台。
二、OpenStack 简介
1、什么是云计算：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问， 进入可配置的计算资源共享池（资源包括网络，服务器，存储，应用软件，服务）
2、云计算所包含的几个层次服务：
•SaaS（ Software as a Service）： 把在线软件作为一种服务。
•Paas（ Platform as a Service）： 把平台作为一种服务。
•Iaas（ Infrastructure as a Service）：把硬件设备作为一种服务。
3、OpenStack：是由Rackspace和NASA共同开发的云计算平台， 是一个开源的 IaaS（基础设施及服务）云计算平台，让任何人都可以自行建立和提供云端运算服务，每半年发布一次，用Python语言编写
4、Opens tack历史
5、OpenStack社区与链接
社区： www.openstack.org, wiki.openstack.org
邮件列表： http://wiki.openstack.org/MailingLists#General_List http://wiki.openstack.org/MailingLists#Development_List http://wiki.openstack.org/MailingLists#Operators
如何贡献代码： http://wiki.openstack.org/HowToContribute
源代码管理 ：http://wiki.openstack.org/GerritWorkflow
文档 ：http://docs.openstack.org
三、openstack架构及优势
OpenStack为私有云和公有云提供可扩展的弹性的云计算服务，这种服务云必须是简单部署并且扩展性强。
1、模块松耦合
2、组件配置较为灵活
3、二次开发容易
四、openstack构成组件
OpenStack共享服务组件：
数据库服务（ Database Service ）：MairaDB 及 MongoDB
消息传输（Message Queues）：RabbitMQ
缓存（cache）： Memcached 时间（time sync）：NTP
存储（storge provider）：ceph、GFS、LVM、ISICI等
高可用及负载均衡：pacemaker、HAproxy、keepalive、lvs等
OpenStack核心组件：
身份服务（ Identity Service ）：Keystone
计算（ Compute ）： Nova
镜像服务（ Image Service ）： Glance
网络 & 地址管理（ Network ）： Neutron
对象存储（ Object Storage ）： Swift
块存储 (Block Storage) ： Cinder
UI 界面 (Dashboard) ： Horizon
测量 (Metering) ： Ceilometer
部署编排 (Orchestration) ： Heat
一、MQ 全称为 Message Queue, 消息队列（ MQ ）
是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。
消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。
排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。
二、AMQP 即 Advanced Message Queuing Protocol
高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。
AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布 / 订阅）、可靠性、安全。
三、 Rabbitmq概念：
属于一个流行的开源消息队列系统。属于AMQP( 高级消息队列协议 ) 标准的一个 实现。是应用层协议的一个开放标准，为面向消息的中间件设计。用于在分布式系统中存储转发消息，在 易用性、扩展性、高可用性等方面表现不俗。
RabbitMQ特点：
使用Erlang编写
支持持久化
支持HA
提供C# , erlang，java，perl，python，ruby等的client开发端
四、什么是耦合、解耦合
一、耦合
1、耦合是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。
2、在软件工程中，对象之间的耦合度就是对象之间的依赖性。对象之间的耦合越高，维护成本越高，因此对象的设计应使类和构件之间的耦合最小。
3、分类：有软硬件之间的耦合，还有软件各模块之间的耦合。耦合性是程序结构中各个模块之间相互关联的度量。它取决于各个模块之间的接口的复杂程度、调用模块的方式以及哪些信息通过接口。
二、解耦
1、解耦，字面意思就是解除耦合关系。
2、在软件工程中，降低耦合度即可以理解为解耦，模块间有依赖关系必然存在耦合，理论上的绝对零耦合是做不到的，但可以通过一些现有的方法将耦合度降至最低。
3、设计的核心思想：尽可能减少代码耦合，如果发现代码耦合，就要采取解耦技术。让数据模型，业务逻辑和视图显示三层之间彼此降低耦合，把关联依赖降到最低，而不至于牵一发而动全身。原则就是A功能的代码不要写在B的功能代码中，如果两者之间需要交互，可以通过接口，通过消息，甚至可以引入框架，但总之就是不要直接交叉写。
为什么选择RabbitMQ
现在的市面上有很多MQ可以选择，比如ActiveMQ、ZeroMQ、Appche Qpid，那问题来了为什么要选择RabbitMQ？
- 除了Qpid，RabbitMQ是唯一一个实现了AMQP标准的消息服务器；
- 可靠性，RabbitMQ的持久化支持，保证了消息的稳定性；
- 高并发，RabbitMQ使用了Erlang开发语言，Erlang是为电话交换机开发的语言，天生自带高并发光环，和高可用特性；
- 集群部署简单，正是应为Erlang使得RabbitMQ集群部署变的超级简单；
- 社区活跃度高，根据网上资料来看，RabbitMQ也是首选；
五、RabbitMQ中的概念名词
Broker：简单来说就是消息队列服务器实体。
Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
Queue：消息队列载体，用于存储生产者的消息，每个消息都会被投入到一个或多个队列。
RoutingKey（路由键）：用于把生成者的数据分配到交换器上；
BindingKey（绑定键）：用于把交换器的消息绑定到队列上；
vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。
producer：消息生产者，就是投递消息的程序。
consumer：消息消费者，就是接受消息的程序。
channel：消息通道，在客户端的每个连接里，可建立多个channel，每个 channel代表一个会话任务。
六、RabbitMQ工作理
MQ 是消费 - 生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取或者订阅队列中的消息。 MQ 则是遵循了 AMQP协议的具体实现和产品。在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。
（ 1）客户端连接到消息队列服务器，打开一个channel。
（ 2）客户端声明一个exchange，并设置相关属性。
（ 3）客户端声明一个queue，并设置相关属性。
（ 4）客户端使用routing key，在exchange和queue之间建立好绑定关系。
（ 5）客户端投递消息到exchange。
（ 6） exchange接收到消息后，就根据消息的key和已经设置的binding，进 行消息路由，将消息投递到一个或多个队列里
通信过程
假设P1和C1注册了相同的Broker，Exchange和Queue。P1发送的消息最终会被C1消费。基本的通信流程大概如下所示：
- P1生产消息，发送给服务器端的Exchange
- Exchange收到消息，根据ROUTINKEY，将消息转发给匹配的Queue1
- Queue1收到消息，将消息发送给订阅者C1
- C1收到消息，发送ACK给队列确认收到消息
- Queue1收到ACK，删除队列中缓存的此条消息
七、Rabbitmq 的 metadata（元数据）
元数据可以持久化在 RAM 或 Disc. 从这个角度可以把 RabbitMQ 集群中的节点分成两种 :RAM Node和 Disk Node.
RAM Node 只会将元数据存放在RAM
Disk node 会将元数据持久化到磁盘。
单节点系统就没有什么选择了 , 只允许 disk node, 否则由于没有数据冗余一旦重启就会丢掉所有的配置信息 . 但在集群环境中可以选择哪些节点是 RAM node.在集群中声明(declare) 创建 exchange queue binding, 这类操作要等到所有的节点都完成创建才会返回 :
如果是内存节点就要修改内存数据 ,
如果是 disk node 就要等待写磁盘 , 节点过多这里的速度就会被大大的拖慢 .
有些场景 exchang queue 相当固定 , 变动很少 ,那即使全都是 disc node, 也没有什么影响 . 如果使用 Rabbitmq 做 RPC（ RPC :Remote Procedure Call—远程过程调用）, RPC 或者类似 RPC 的场景这个问题就严重了 , 频繁创建销毁临时队列 , 磁盘读写能力就很快成为性能瓶颈了。所以 , 大多数情况下 , 我们尽量把 Node 创建为RAM Node. 这里就有一个问题了 , 要想集群重启后元数据可以恢复就需要把集群元数据持久化到磁盘 , 那需要规划 RabbitMQ 集群中的 RAM Node 和 Disc Node 。
只要有一个节点是 Disc Node 就能提供条件把集群元数据写到磁盘 ,RabbitMQ 的确也是这样要求的 : 集群中只要有一个 disk node 就可以 , 其它的都可以是 RAM node. 节点加入或退出集群一定至少要通知集群中的一个 disk node 。
如果集群中 disk node 都宕掉 , 就不要变动集群的元数据 . 声明 exchange queue 修改用户权限 , 添加用户等等这些变动在节点重启之后无法恢复 。
有一种情况要求所有的 disk node 都要在线情况在才能操作 , 那就是增加或者移除节点 .RAM node 启动的时候会连接到预设的 disk node 下载最新的集群元数据 . 如果你有两个 disk node(d1 d2), 一个 RAM node 加入的时候你只告诉 d1, 而恰好这个 RAM node 重启的时候 d1 并没有启动 , 重启就会失败 . 所以加入 RAM 节点的时候 , 把所有的disk node 信息都告诉它 ,RAM node 会把 disk node 的信息持久化到磁盘以便后续启动可以按图索骥 .
持久化工作原理
Rabbit会将你的持久化消息写入磁盘上的持久化日志文件，等消息被消费之后，Rabbit会把这条消息标识为等待垃圾回收。
持久化的缺点
消息持久化的优点显而易见，但缺点也很明显，那就是性能，因为要写入硬盘要比写入内存性能较低很多，从而降低了服务器的吞吐量，尽管使用SSD硬盘可以使事情得到缓解，但他仍然吸干了Rabbit的性能，当消息成千上万条要写入磁盘的时候，性能是很低的。
八、Rabbitmq 集群部署
192.168.253.135 bb 192.168.253.171 aa 192.168.253.153 cc
yum install -y erlang rabbitmq-server.noarch systemctl enable rabbitmq-server.service systemctl start rabbitmq-server.service systemctl status rabbitmq-server.service
rabbitmqctl change_password guest admin #更改密码为admin，用户名不能数字开头
node1： rabbitmqctl add_user mama admin rabbitmqctl set_permissions mama ".*" ".*" ".*" rabbitmqctl set_user_tags mama administrator #设为管理员才可以登陆
改密码：
rabbitmqctl change_password 用户 密码
RABBITMQ_NODE_PORT=5672 ulimit -S -n 4096 RABBITMQ_SERVER_ERL_ARGS="+K true +A30 +P 1048576 -kernel inet_default_connect_options [{nodelay,true},{raw,6,18,<<5000:64/native>>}] -kernel inet_default_listen_options [{raw,6,18,<<5000:64/native>>}]" RABBITMQ_NODE_IP_ADDRESS=192.168.253.135
scp /etc/rabbitmq/rabbitmq-env.conf aa:/etc/rabbitmq/
scp /etc/rabbitmq/rabbitmq-env.conf cc:/etc/rabbitmq/
/usr/lib/rabbitmq/bin/rabbitmq-plugins list
rabbitmq-plugins enable rabbitmq_management
scp /var/lib/rabbitmq/.erlang.cookie aa:/var/lib/rabbitmq/.erlang.cookie scp /var/lib/rabbitmq/.erlang.cookie cc:/var/lib/rabbitmq/.erlang.cookie
systemctl restart rabbitmq-server.service rabbitmqctl stop_app rabbitmqctl join_cluster --ram rabbit@bb rabbitmqctl start_app
如果节点启动什么的报错大概率因为cookie传送错误，删除从节点的mnesia再次发送
或者是因为没有重启服务
rabbitmqctl stop_app
rabbitmqctl change_cluster_node_type disc (ram)
Turning rabbit@cc into a ram node ...
Error: Mnesia is still running on node rabbit@cc.
Please stop the node with rabbitmqctl stop_app first. #可以看到需要先停止应用
停止后再次执行
[root@cc rabbitmq]# rabbitmqctl change_cluster_node_type ram
Turning rabbit@cc into a ram node ...
rabbitmqctl start_app
rabbitmqctl stop_app
rabbitmqctl reset
----》 Resetting node rabbit@cc ...
[root@cc rabbitmq]# rabbitmqctl cluster_status #查看状态发现节点cc脱离了集群
Cluster status of node rabbit@cc ...
[{nodes,[{disc,[rabbit@cc]}]}, #脱离集群后的节点自动会变成disc的方式，原因在下方 1
{running_nodes,[rabbit@cc]},
{cluster_name,<<"rabbit@cc">>}, #并没有其他节点的名称说明不在集群内了
{partitions,[]},
{alarms,[{rabbit@cc,[]}]}]
rabbitmqctl forget_cluster_node rabbit@node3
rabbitmqctl reset
rabbitmqctl start_app
rabbitmqctl cluster_status
