阿里云服务器是如何实现每台服务器都是公网IP的呢？

瞎回答的很多。实质上，并没有魔术。阿里云的ip就是买的，是一大段一大段ip范围买下的。

那些说类似专线独立ip的人，都是瞎掰，专线实质上是电信买下的ip范围里租一个给你用，电信那端通过调整路由表把对应的ip报文转发到你那根物理线路上。

阿里云的技术方式完全不一样。

首先阿里和电信一样，都是购买巨大的一段ip地址范围，它的地址范围不比电信小多少。ipv4的地址范围就是这些大佬买光的，国外aws，google，微软的ip范围更大。

其次，阿里云内部，不是简单的改路由器，而是当有bgp能力的核心路由把全网络里属于阿里云的ip报文导入数据中心后，通过服务器进行报文数据软交换，也就是常说的sdn（软件定义的网络）技术把ip分配给具体的虚拟机。这样确保虚拟机绑ip可轻松的自动绑定。当你在界面上点一下申请d性ip的时候，阿里云就从它的ip池里空余的ip中，分一个给你，注意，这个ip池比阿里的机器数量，甚至虚拟机数量要大很多。当你分配了d性ip后，如果要绑定d性ip到具体某个虚拟机时候，背地里，阿里云就简单的把这个ip和虚拟机的路由关系告诉它的软交换服务器集群，然后所有进入阿里云中的报文里，属于这个ip的报文被投递给这台虚拟机。

首先声明一下，我不太确定是不是黑阿里云的，但是基本国内的云计算从技术角度都差不多。阿里云这方面做的可能稍微好点，但是与腾讯，百度，青云，华为云等平台也是大同小异，可能阿里云因为淘宝，别人更愿意相信阿里云。

因此题主其实想知道的是云服务器和独立服务器的优缺点，不涉及特定的平台。

独立服务器和云服务器对比

1、从技术方面来讲：云服务器使用了云计算技术，而云计算技术，整合了计算、网络、存储等各种软件和硬件技术。独立服务器，就是独立的服务器功能技术，不会整合这些资源。

2、从安全性方面来讲：云服务器具有天然防ARP攻击和MAC欺骗，快照备份，数据永久不丢失。而独立服务器则不具有这方面的功能；

3、从可靠性来讲：云服务器是基于服务器集群的，因此硬件冗余度较高，故障率低；而独立服务器则相对来说硬件冗余较少，故障率较高；

4、从灵活性方面来讲：用户可以在线实时增加自己的配置，可扩展空间较大；而独立服务器则有这方面的局限性，如果有新的应用，只能再买一台了。

5、从性能的角度来看：云服务器是同等配置独立服务器计算能力的4倍，可满足高性能计算的要求；

6、从稳定性上看，云服务器可以故障自动迁移，意思是如果一台云服务器出现故障，其上面的应用就自动迁移到其他云服务器上了。独立服务器就不存在这功能了，宕了就宕了。

题外话

题主说的阿里云反馈半天没人理，其实是只是服务态度问题。其实有时候，独立服务器找机房处理其实也需要时间，碰上一般的IDC公司，可能速度更慢。

所以选择独立服务器还是云服务器，主要是取决于业务需要，比如企业要利用服务器做一个数据备份和存储服务器，在数据量大的情况下，明显是独立服务器有优势。如果是做一个网站或者OA，这样就是云服务器有优势。

如果觉得有用可以点个赞，如果有其他不同观点，可以留言互相讨论。

一台阿里云的ECS主机可以放置多个网站的，通过WEB服务器（NGINX\APACHE\IIS等）配置虚拟主机的形式，同时运行多个网站。

但一台阿里云主机可以放多少个网站，这个主要看你网站的占用的资源，以及服务器配置的性能的。（这个因为你没有给出具体的数据，所以没办法确定）

如果RabbitMQ集群只有一个broker节点，那么该节点的失效将导致整个服务临时性的不可用，并且可能会导致message的丢失（尤其是在非持久化message存储于非持久化queue中的时候）。可以将所有message都设置为持久化，并且使用持久化的queue，但是这样仍然无法避免由于缓存导致的问题：因为message在发送之后和被写入磁盘并执行fsync之间存在一个虽然短暂但是会产生问题的时间窗。通过publisher的confirm机制能够确保客户端知道哪些message已经存入磁盘，尽管如此，一般不希望遇到因单点故障导致服务不可用。

如果RabbitMQ集群是由多个broker节点构成的，那么从服务的整体可用性上来讲，该集群对于单点失效是有d性的，但是同时也需要注意：尽管exchange和binding能够在单点失效问题上幸免于难，但是queue和其上持有的message却不行，这是因为queue及其内容仅仅存储于单个节点之上，所以一个节点的失效表现为其对应的queue不可用。

为了提高程序的吞吐量，保持消息的可靠性，一台机器挂了后，RabbitMQ能够正常生产，消费消息。

rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式

Demo级别的，一般只是本机测试玩玩而已，生产环境下不会用的。

在多台机器上启动多个rabbitmq实例，每个机器启动一个。
但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据(存放含queue数据的真正实例位置)。消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。

示意图

这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。
普通集群的方式，确实达到了消息的高可用，但没办法保证可靠性，没做到分布式，简而言之，只是一个普通的集群。

这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

上图中每个节点有一个queue，生产者生产完毕数据后投递到指定交换机的队列，交换机的队列进行消息同步。

每个节点queue都有一个完整的rabbitmq节点，所以这种方式叫做镜像集群

好处： 任何一个节点宕机后，其它节点不受影响，正常使用

坏处：

确保机器中安装了Docker，若未安装，可看：云原生Docker入门 – 阿里云服务器Linux环境下安装Docker

查看拉取的镜像

成功运行

设置节点1

浏览器输入 您的ip地址:15673

再次测试即可成功~

File —> New —> Project —> Maven —> 直接Next 进入下一步创建普通的Maven工程即可

创建一个默认的Maven聚合工程，将src文件夹删除，该工程就是一个Maven聚合工程

引入依赖如下：

在项目内，新建一个Moudle，rabbitmq-order-producer 默认Maven工程，下一步即可

在项目内，新建一个Moudle，rabbitmq-order-cousumer 默认Maven工程，下一步即可

Maven聚合工程创建完成图

Maven依赖图

自行手写MainApplication即可

创建完成！

编写完成！

启动消费者

交换机

=

15674

15675

成功消费数据！

已成功同步消息~

如果是集群的话，我考虑需要流畅运行的话，2核4G配置是可以满足的。因为这个集群形式，用于适用于物联网、车联网、监控、安全风控、即时通讯、消息存储等行业场景，所以数据量是比较大的，所以配置太低了跑不动，会卡死的。
因为hadoop是海量数据的处理能力，所以服务器一定不能太小配置了，跑不动了就没实际用途了。最好使用4核8G内存及以上配置。
因为这方面内容较多，这里也写不开那么多内容，所以你可以留言或到我的博客上搜索相关内容，老魏有写过教程，还不止一篇，都挺详细的内容，可以帮助你入门。

---