基本组件：
 
    Zookeeper：
 
        分布式协作框架
 
            节点数目：
 
                测试集群：3个
 
                生产集群：(7个差不多)
 
                    小型集群：3个或者5个
 
                    中型集群：5个或者7个
 
                    大型集群：更多，奇数个
 
    HDFS：
 
        存储海量数据
 
    YARN：
 
        集群资源管理
 
        资源调度
 
    MapReduce：
 
        并行计算框架
 
            思想：
 
                分而治之
 
 
 
集群大小：双十一模拟，峰值，宕机处理一类，11月9号
 
    测试集群：
 
        机器数量：(测试数据，每秒读取数据一类)
 
            5台 - 10台
 
        机器配置：
 
            内存：24G/32G以上
 
                8G-12G
 
                NameNode:2G 每台内存越多越好 MR内存来自于NN
 
                DataNode:6G-8G
 
                RS:4G
 
            硬盘：4T / 10T  以上
 
            CPU核：6核以上(i5,i7) 一个map任务默认1G 100万个文件
 
            网卡/网线：(数据传输读写)万兆，十万，百万
 
 
 
生产集群：(十几二十几就可以，内存128G,硬盘15T，浪潮，16核，网卡10万兆)
 
    小型集群：
 
        20台以下。
 
    中型集群：
 
        50台以下。
 
    大型集群：
 
        50台以上。
 
 
 
Hadoop发行版本：
 
    Apache
 
    CDH：服务收钱，开源免费 (Cloudera's Distribution Hadoop)
 
        Cloudera公司：发布版本，只支持64位操作系统
 
            安装：tar包：http://archive.cloudera.com/cdh5/cdh/5
 
                  rmp包：http://archive.cloudera.com/cdh5/redhat(lunix发行版本)/6/x86_64/cdh 京东等，自己编译rmp包
 
                  parcels包(压缩包，生态系统所有压缩在里面，最好的)：cdh 4.1.2 以后才有的 13年 官方推荐的方式 Cloudera Manager进行安装
 
    HDP：(Hortonworks Data Platform)
 
        Hortonworks
 
公司版本：
 
    apache -> cdh | hdp
 
面试题：
 
    apache和cdh比较，为什么选择了cdh？
 
    CDH省时省力，自动探测host，选择版本，配置简单，几乎是傻瓜式一键安装。MapR方便程度就稍微差一些，但是仍然比Apache要方便很多。但是MapR版本有一个致命的缺点，它用的不是Hadoop的HDFS而是他们自己实现的MapRFS。导致了Hadoop生态系统中所有涉及到文件系统操作的系统都需要使用MapR的发行版。为了兼容MapRFS,源码都被改过。可以到MapR的github账户上看到。Apache的话就真心需要专职运维人员去管理了。需要使用一些集群管理配置工具了。手动绝对累死。你所说的CDH没有对yarn的开发力度不大我觉得这个倒不用太担心。CDH会定期根据Apache开源的最新稳定版本发布相应的CDH版本，所以不存在版本落后最新版很多的情况。而且我记得CDH现在加入了parcel管理，可以非常简单方便地切换hadoop版本而不需要重新安装集群。这个功能诱惑力太大了。另外CDH对于超过50个节点的集群就要开始收费了。这个是需要考虑的问题。5.0后50个节点限制取消。
 
    CDH对Hadoop版本的划分非常清晰，只有两个系列的版本，分别是CDH3和CDH4，分别对应Hadoop 1.0和Hadoop 2.0。相比而言，Apache版本则混乱得多。
 
    CDH比Apache在兼容性，安全性，稳定性上有增强。
 
    CDH3版本是基于Apache  Hadoop  0.20.2改进的，并融入了最新的patch，CDH4版本是基于Apache Hadoop 2.X改进的,CDH总是并应用了最新Bug修复或者Feature的Patch，并比Apache hadoop同功能版本提早发布，更新速度比Apache官方快。
 
    CDH支持Kerberos安全认证，Apache则使用简陋的用户名匹配认证.
 
    CDH文档清晰，很多采用Apache版本的用户都会阅读CDH提供的文档，包括安装文档、升级文档等。
 
    CDH支持Yum/Apt包，Tar包，RPM包，Cloudera Manager四种方式安装，Apache 只支持Tar包安装。
 
    CDH使用推荐的Yum/Apt包安装时，有以下几个好处：
 
        1、联网安装、升级，非常方便
 
        2、自动下载依赖软件包
 
        3、Hadoop生态系统包自动匹配，不需要你寻找与当前Hadoop匹配的Hbase，Flume，Hive等软件，Yum/Apt会根据当前安装Hadoop版本自动寻找匹配版本的软件包，并保证兼容性。
 
        4、自动创建相关目录并软链到合适的地方（如conf和logs等目录）；自动创建hdfs, mapred用户，hdfs用户是HDFS的最高权限用户，mapred用户则负责mapreduce执行过程中相关目录的权限。
 
 
 
 
 
集群环境准备：
 
    机器：
 
        磁盘阵列：
 
            RADI0 RADI1 JBOD
 
            RADI1:两块磁盘映射为一块磁盘使用。装了CentOs 6.4版本，其中一块磁盘损坏，不会影响系统，因为相互映射备份 0+1更保险
 
            JBOD：磁盘柜。DataNode存储数据推荐的方式。调优。读取快。
 
                  datanode存储位置可以配置，挂载一个磁盘，通常：/dfs/data01 /dfs/data02 /dfs/data03
 
        装系统：redhat 5/6 推荐6、CentOs 6.x 64位 6.4版本、sles 11ur版本
 
            clouder文档：查看适应哪个版本
 
        系统：
 
            IP地址：尽可能在同一网段，尽量在一个交换机上(机架Rack，默认机架/default)。
 
            设置主机名：bigdata-cdh01.ibeifeng.com、bigdata-cdh02.ibeifeng.com、bigdata-cdh03.ibeifeng.com(主机名里面不能有_下划线)
 
                修改主机名：
 
                    hostname
 
                    vi /etc/sysconfig/network
 
                    例：
 
                        hostname bigdata-cdh02.ibeifeng.com
 
                        vi /etc/sysconfig/network
 
                            HOSTNAME=bigdata-cdh02.ibeifeng.com
 
            IP和主机名映射(所有机器)：
 
                禁用IPv6(所有机器)：
 
                    sudo echo "alia net-pf-10 off" >> /etc/modprobe.d/dist.conf
 
                    sudo echo "alia ipv6 off" >> /etc/modprobe.d/dist.conf
 
                    tail -f /etc/modprobe.d/dist.conf
 
                vi /etc/hosts
 
                ## BigData CDH 5.x
 
                172.16.200.11 bigdata-cdh01.ibeifeng.com bigdata-cdh01
 
                172.16.200.12 bigdata-cdh02.ibeifeng.com bigdata-cdh02
 
                172.16.200.13 bigdata-cdh03.ibeifeng.com bigdata-cdh03
 
                windows下：
 
                    C:/Windows/System32/drivers/etc/hosts
 
                    172.16.200.11 bigdata-cdh01.ibeifeng.com bigdata-cdh01
 
                    172.16.200.12 bigdata-cdh02.ibeifeng.com bigdata-cdh02
 
                    172.16.200.13 bigdata-cdh03.ibeifeng.com bigdata-cdh03
 
            普通用户(所有机器):所有集群中普通用户名字一定要一致
 
                用于安装软件：
 
                    adduser beifeng
 
                    passwd 123456
 
                    su - beifeng 切换用户
 
                    su
 
                    sudo 切换方便
 
            配置普通用户的sudo权限(所有)：
 
                su             
 
                写权限：chmod 777 /etc/sudoers/chmod u+w /etc/sudoers
 
                添加：vi /etc/sudoers
 
                    beifeng ALL=(root)NOPASSWD:ALL
 
                收回权限：chmod 777 /etc/sudoers/chmod u-w /etc/sudoers
 
            关闭防火墙(所有，不同机器，关键字不同)；
 
                sudo service iptables stop
 
                永久关闭：sudo chkconfig iptables off
 
                查看防火墙是否关闭：sudo chkconfig --list|grep iptables
 
                            iptables 0:off  1:off   2:off   3:off   4:off   5:off   6:off  全部关闭
 
                more /etc/inittab：默认运行级别5，节省内存3
 
            Selinux(所有):
 
                禁用：因为麻烦，没有专业运维，运用少，系统服务和驱动程序不兼容，涉及安全
 
                    sudo vi /etc/sysconfig/selinux
 
                    SELINUX=disabled
 
            卸载JDK：
 
                查看版本：sudo rpm -qa|grep java
 
                卸载，参数强制性，因为有些是有关联的：sudo rpm -e --nodeps xxx
 
            设置文件打开数量和用户最大进程数(所有)：
 
                文件打开数量：
 
                    ulimit -a
 
                用户最大进程数：
 
                    ulimit -u
 
                设置：
 
                    sudo vi /etc/security/limits.conf
 
                    内容：
 
                        *(任何参数用户) soft nofile 65535
 
                        * hard nofile 65535
 
                        * soft nproc 32000
 
                        * hard nproc 32000
 
文档：www.cloudera.com/content/www/en-us/documentation/enterprise/5-3-x.html                  
 
        软件：
 
            集群时间同步：
 
                CentOS配置时间同步NTP，为什么要使用ntpd而不是ntpdate？
 
                    原因很简单，ntpd是步进式的逐渐调整时间，而ntpdate是断点更新，比如现在服务器时间是9.18分，而标准时间是9.28分，ntpd会在一段时间内逐渐的把时间校准到与标准时间相同，而ntpdate会立刻把时间调整到9.28分，如果你往数据库内写入内容或在其他对时间有严格要求的生产环境下，产生的后果会是很严重的。（注：当本地时间与标准时间相差30分钟以上是ntpd会停止工作）
 
                找集群一台机器作为【时间服务器】：bigdata-cdh01.ibeifeng.com
 
                sudo rpm -qa|grep ntp
 
                sudo vim /etc/
 
                    restrict (ifconfig:inet6 addr) mask 255.255.255.0 nomodify notrap
 
                    #server 0.centos.pool.ntp.org
 
                    #server 1.centos.pool.ntp.org
 
                    #server 2.centos.pool.ntp.org
 
                    server 127.127.1.0 # local clock
 
                    fudge 127.127.1.0 stratum 10
 
                sudo vi /etc/sysconfig/ntpd
 
                    SYNC_HWCLOCK=yes
 
                sudo service ntpd status
 
                sudo service ntpd start
 
                sudo chkconfig ntpd on
 
                sudo chkconfig --list|grep ntpf
 
            客户端同步(剩余其他台机器)：zookeeper依赖性特别高
 
                定时任务:
 
                    Linux Crontab
 
                        su
 
                        crontab -l：查看定时器任务
 
                        crontab -e：创建定时器任务
 
                            ## sync cluster time
 
                            0-59/10 * * * * /usr/sbin/ntpdade bigdata-cdh01.ibeifeng.com
 
sudo reboot

背景
 中国移动一级业务支撑系统是整个中国移动的集中管理和一点对外的门户，包括网状网、BBOSS、一级营销、内容计费、一级客服、VGOP、电渠等多个业务支撑系统，各系统呈烟囱化建设。在小型机时代由于主机集成度高、性能稳定因此数量较少，多项目集群建设、运维尚能保持平稳。但随着系统X86化逐步推进，多项目集群中分别管理的主机、网络、存储等资源数量成几何级数增长，对项目建设、运维开发等各个流程都带来颠覆性挑战，现分析各类挑战如下：

 
在资源层面，各个项目的资源分散散布在各个数据中心和私有云里，不能统一管理，每个项目都有独立的资源，分布在不同的机房，特别是网状网和内容计费分布在31个省，对跨数据中心的资源和系统统一管理难度较大。
在网络层面，每个项目都跨多个网络域，如核心域、DMZ域和互联网域，之间有多层防火墙隔离，不同系统的安全等级要求不同，不同域的数据访问对安全控制的要求也各不相同。
在技术层面，缺乏统一的技术和平台实现业务能力的快速扩展，尤其是无法满足互联网业务发展带来的剧烈业务波动业务快速上线和弹性伸缩能力差。各项目采用的技术和框架各异。有的适合容器化，有的适合直接在小机上运行。底层无法直接进行技术复用和共享，需要针对具体情况进行分析和提出解决方案。
 

 鉴于在以上多种复杂环境下，业务支撑中心要实现对多系统、多资源、多网络、多数据中心、多技术架构的统一管理，必须构建中国移动业务支撑云平台来进行进一步的能力提升，实现对多项目下多集群的统一管理。

 
多集群管理整体技术方案
 多集群统一管理是基于中国移动业务支撑云平台的基础上构建的，以Docker、Kubernetes、Mesos、Ansible为核心支撑技术框架来实现，中国移动业务支撑云平台整体架构视图如下所示：

 

 
 

 该架构方案既满足了适用于容器化应用的服务统一管理、又满足了不适于容器化的Hadoop等服务和基于小机类的应用服务的统一访问和统一管理，是根据当前中国移业务支撑系统现状量身定制，既适合当前业务支撑系统发展的实际需求，又具有支撑未来业务高速发展的技术先进性。

 

 在中国移动业务支撑云平台多集群管理的实践中，我们一直在思考怎样的多集群管理模式最适合移动总部的系统，是大一统的集中PaaS集群管理平台还是采用松耦合的联邦式集群管理模式。移动总部一级业务支撑系统都是大型项目，每个项目业务特点和技术构架都不一样，都有大量主机，分布在业支机房和资源池，每个系统均跨多个网络域包含多个集群，像网状网和内容计费项目集群还跨31个省。既能保持各个项目的灵活性，构架不受冲击，又能实现集中式的资源和应用管理是PaaS多集群管理平台的设计原则。

 

 因此我们最终采用了Cluster Federation（集群联盟）的模式对各项目的多集群进行统一管理。采用此方式对各个项目的影响最小，系统不用做任何改动，同时可以实现资源集中管理和统一服务调度，集中的管理包含镜像管理、应用管理、配置管理、资源管理、监控管理等。多集群统一管理架构设计如下图所示：

 

 
 

 结合Kubernetes容器集群管理的优秀技术，通过自主研发的多集群管理软件。实现了Mesos+Kubernetes多集群的统一管理，涵盖以下典型应用场景：

 
在同一数据中心的多个项目共享资源统一管理
 在kubernetets集群管理平台中为每个项目建立独立的租户，安全隔离不同租户的资源和访问权限。通过分区和分集群的方式即保持各项目的独立性又保持资源的共享。为大的项目建立独立的clutser，小的项目通过分区实现安全隔离。共享资源统一管理多个项目如下图所示：

 

 
 

 
在同一数据中心对含有多个网络域项目的统一管理
 对于DMZ域和互联网域部署的一般都是WEB类应用和Proxy应用，比较轻量但弹性扩展需求强，适合部署Kubernetets+Docker。

 

 对于核心域包含大量的计算类、服务类、分析类应用，适合部署Mesos+Kubernetes+Docker。

 

 跨多网络域项目的多集群统一管理如下图所示：

 

 
 

 
跨IP承载网的多数据中心统一管理
 中国移动业务支撑系统跨多个数据中心，可以对多数据中心实现统一的应用镜像管理、统一的应用部署和服务的调度，以及应用的快速容灾调度。跨IP承载网的多数据中心统一管理如下图所示：

 

 
 

 
多集群管理中的重点和难点
 对于一个多集群的PaaS管理平台，我们从以下方面进行了详细的方案分析和设计实现。

 

 
 

 主要包含安全集中控制、资源统一管理、镜像统一管理、应用统一管理、配置统一管理和统一的监控管理。在多集群的模式下，每一个功能都会变得非常复杂。下面就每个功能实现做详细的描述。

 
安全集中控制
 联合多集群模式下安全管控是要考虑的一个非常复杂的因素，需要考虑平台管理员，集群管理员，普通用户等多个角色。权限分配也很复杂：

 
怎么定义租户，怎么控制租户和集群资源的关系，怎么映射租户和项目的关系。
每一个租户对于自己的集群资源怎么进一步划分分区，分配权限给开发，部署和运维人员。
每个用户怎么管理自己的应用和监控应用的健康情况。
 

 考虑以上问题，我们在多集群PaaS管理平台中，通过租户、集群、用户三级安全管理，实现统一PaaS平台多集群管理的安全集中管控。如下图所示：

 

 
 

 
首先要控制对集群的安全访问，每个集群都采用安全模式启动，采用证书方式访问，没有证书不允许访问任何一个集群。
在多集群管理中，租户为一个虚拟的单位概念，每个项目可定义为一个租户，如网状网项目即为一个租户，每个租户下可建立多个集群，租户拥有一个或者多个集群的访问证书，租户实现对自己名下的资源的管理和分配。
租户再通过用户组绑定不同集群和分区资源，用户属于该用户组就可以获得对资源的访问权限。
用户本身只能部署和监控自己的应用，用户并不能查看互相的应用，保证应用的独立性和安全性。
 

 
资源统一纳管
 对于统一PaaS平台来说，最主要的功能就是对资源的统一的管控，包含有多少个集群，每个集群多少台机器，都分布在哪个机房，机器配置情况如何，目前的可用率怎么样，怎么去集群间调配资源。因此，统一PaaS资源管理平台实现了以下的资源统一管理功能：

 
经过证书认证之后，通过Kubernetes API Server对集群进行那管，把集群的Node的数量，配置等信息导入，同时补充机房，机架等信息。
将纳入集群和租户进行绑定，把集群分配给指定租户。
租户可以继续对集群资源进行分区，比如分成WEB区、DB区等，便于部署不同的应用，并且可以实现不同配置的主机的共存。设计方案和系统实现如下图所示：
 
  

   
  
 
 

 
镜像统一管理
 镜像的统一管理是多集群模式下的一个非常重要的功能。统一PaaS平台需要对镜像做集中的管控，但是又要考虑镜像部署的效率。因此，在统一PaaS平台中采用了两级镜像的构架：

 
在总部实现镜像的统一生命周期的管理，镜像的入库，出库和版本更新都在总部统一镜像库集中管理。这样未来可以和DevOps整合在一起，进行统一的开发，运营管理。
每个集群都有一个子库或者几个集群共享一个子库。子库可以设定同步规则，只同步一部分镜像到子库，并实现镜像的跨地域、跨IP承载网同步和更新，支持全量同步和增量同步。这样每个项目可以只同步自己的镜像到自己的集群中，提高集群应用部署的效率。
 

 设计方案和系统实现如下图所示：

 

 
 

 
应用统一部署
 多集群情况下的应用部署需要考虑的情况会比较复杂：

 
应用需要能支持跨广域网，跨集群统一部署；
应用需要能支持部署到不同集群的不同的分区上；
应用需要能支持跨集群灰度发布和滚动升级。
 

 针对这些要求，统一PaaS平台对应用部署功能进行了改进：

 
用户定义完应用之后，点击部署，这时候会出现一个用户具有权限的集群和分区的列表，用户可以选择在哪个集群的哪个分区上部署应用。这样用户就能一键式的把应用同步部署到多个集群上。
对于应用的在线灰度发布和升级是企业应用必备的功能。大型的应用都会部署在多个集群或者分区，提高应用的高可用性，并且在升级的时候用户可以选择按集群和分区进行滚动升级。保证上线业务系统不中断，提高用户满意度。设计方案和系统实现如下图所示： 
  

   
  
 
 

 
配置统一管理
 对于支撑多系统多应用共存的PaaS平台。必须实现配置和应用程序分离，因为每个应用的配置数据格式和需求都不一样，但是如果要求应用只是因为配置问题就修改程序结构，那么PaaS平台适应性太差，无法满足大规模的应用的部署。

 

 Kubernetes ConfigMap的功能正好能满足多应用的复杂的环境下的配置管理，在统一PAAS管理平台中，我们进行了配置管理的封装：

 
用户可以事先上传或者直接拷贝多个任意格式的配置文件（XML、Properties、TXT等）到不同的集群中创建配置库，形成一个绑定在不同的集群中的统一名字的配置库。
用户在应用部署的时候，选择该名字的配置库，就可以实现应用在不同集群部署的时候，自动绑定自己集群的配置数据，实现不同环境，不同集群的统一的应用和配置数据的绑定。
 

 设计方案和系统实现如下图所示：

 

 
 

 
统一监控
 在多集群多租户模式下，每个租户会关心自己的资源和服务的运行情况。因此统一PaaS平台通过统一监控管理实现对所有租户、集群、资源、应用的集中数据采集和展示，又能分租户展示不同的集群和Service的运行情况。并能在发生故障时及时获取告警信息，快速进行故障恢复和隔离。

 

 设计方案和系统实现如下图所示：

 

 
 

 
应用效果
 
通过Kubernetes多集群统一管理，实现了对一级业务支撑系统中多项目集群、跨多个网络域、跨多个数据中心的复杂集群环境下进行集中资源管理，应用和配置数据的多集群统一部署和管理，提高了业务支撑中心对各分散系统的管理和监控力度。
目前试点的三个项目，共有35个集群，约5000个容器分布在全国多个机房。提供了针对多个集群的资源统一管理和调度、镜像集中管理、应用集中部署、配置统一管理和容器统一监控，同时可以定义在每个集群部署服务的容器实例的比例。
在未采用多集群管理之前，如：网状网系统上线一个新的版本，包含总部集群、容灾集群和31个省集群，需要至少5个人部署一天；使用Kubenetes多集群统一管理平台之后，通过多集群统一部署,只需要一个人10分钟即可完成33个集群的版本升级。
通过使用Kubernetes多集群统一管理中的“克隆”功能、能够非常快速地实现服务的发布。极大提高大规模应用快速部署的灵活性和系统快捷的水平扩展能力。
通过使用Kubernetes多集群统一管理，可以方便灵活地从业务视图、集群视图、租户视图等全方位监控各集群的资源整体利用率，实现动态监控和动态快速调整业务的容器数量。
 

 
下一步计划
 统一PaaS平台经过三个系统的集群的试点，目前运行稳定，逐步积累了很多的运维和管理经验，在此基础上计划做进一步的研究和推广。

 
推广到更多的项目，形成容器话应用的开发设计规范，镜像打包规范，PAAS平台运维规范等多个规范性文件，为未来的推广提供标准化和规范化支持。
与Mesos的集成。目前已经实现了Kubernetes和Mesos的深度集成，Kubernetes可以作为一个Framework运行在Mesos之上。下一步准备迁移Hadoop/Spark到Mesos，并且实现Kubernetes和Hadoop/Spark应用的资源共享。
与DevOps工具集的集成。目前我们正在实现针对PaaS平台的DevOps理念的实现。包含工具，流程和监控。未来实现整个从开发 -> 代码质量分析 -> 打包镜像 -> 测试 -> 部署的自动化支撑，并且通过Dashboard展现每个项目，每个微服务的所有环节的状态，从而提高移动对于整个开发测试过程的管理力度。
 

 
作者：中国移动业务支撑系统部业务支撑中心 谢军、初瑞、夏敬侃

 分布式是指将一个业务拆分不同的子业务，分布在不同的机器上执行，集群是指多台服务器集中在一起，实现同一业务，可以视为一台计算机，一个云计算平台，就是通过一套软件系统把分布式部署的资源集中调度使用。要应对大并发，要实现高可用，既需要分布式，也离不开集群。
 
 分布式和集群区别？
 
 分布式
 
 分布式：是指将一个业务拆分不同的子业务，分布在不同的机器上执行。
 
 常用的分布式就是在负载均衡服务器后加一堆web服务器，然后在上面搞一个缓存服务器来保存临时状态，后面共享一个数据库，
 
 如图所示:
 
 
 
 这种环境下真正进行分布式的只是web server而已，并且web server之间没有任何联系，所以结构和实现都非常简单。
 
 集群
 
 集群：是指多台服务器集中在一起，实现同一业务，可以视为一台计算机。
 
 多台服务器组成的一组计算机，作为一个整体存在，向用户提供一组网络资源，这些单个的服务器就是集群的节点。
 
 两个特点
 
 可扩展性：集群中的服务节点，可以动态的添加机器，从而增加集群的处理能力。
 
 高可用性：如果集群某个节点发生故障，这台节点上面运行的服务，可以被其他服务节点接管，从而增强集群的高可用性。
 
 集群分类
 
 常用的集群分类
 
 1.高可用集群(High Availability Cluster)
 
 高可用集群,普通两节点双机热备，多节点HA集群。
 
 2.负载均衡集群(Load Balance Cluster)
 
 常用的有 Nginx 把请求分发给后端的不同web服务器，还有就是数据库集群，负载均衡就是，为了保证服务器的高可用，高并发。
 
 3.科学计算集群(High Performance Computing Cluster)
 
 简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。
 
 两大能力
 
 负载均衡：负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。
 
 集群容错：当我们的系统中用到集群环境,因为各种原因在集群调用失败时，集群容错起到关键性的作用。
 
 例如 Dubbo 的集群容错：
 
 Failover Cluster
 
 失败自动切换，当出现失败，重试其它服务器，通常用于读操作，但重试会带来更长延迟。
 
 Failfast Cluster
 
 快速失败，只发起一次调用，失败立即报错，通常用于非幂等性的写操作，比如新增记录。
 
 Failback Cluster
 
 失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作。
 
 Forking Cluster
 
 并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
 
 简单总结
 
 分布式，从狭义上理解，也与集群差不多，但是它的组织比较松散，不像集群，有一定组织性，一台服务器宕了，其他的服务器可以顶上来。
 
 分布式的每一个节点，都完成不同的业务，一个节点宕了，这个业务就不可访问了。
 
 1. 分布式是指将一个业务拆分不同的子业务，分布在不同的机器上执行。
 
 2. 集群是指多台服务器集中在一起，实现同一业务，可以视为一台计算机。
 
 分布式的每一个节点，都可以用来做集群。而集群不一定就是分布式了。
 
 什么是云计算平台？
 
 一个云计算平台，就是通过一套软件系统把分布式部署的资源集中调度使用。要应对大并发，要实现高可用，既需要分布式，也离不开集群。
 
 比如负载均衡，如果只是一台服务器，这台宕机了就完蛋了。
 
 分布式的难点，就是很多机器做存在依赖关系的不同活儿，这些活儿需要的资源、时间区别可能很大，某些机器还可能罢工，要怎么样才能协调好，做到效率最高，消耗最少，不出错。
 
 分布式的应用场景？
 
 平时接触到的分布式系统有很多种，比如分布式文件系统，分布式数据库，分布式WebService，分布式计算等等，面向的情景不同，但分布式的思路是否是一样的呢?
 
 1.简单的例子
 
 假设我们有一台服务器，它可以承担1百万/秒的请求，这个请求可以的是通过http访问网页，通过tcp下载文件，jdbc执行sql，RPC调用接口…，现在我们有一条数据的请求是2百万/秒，很显然服务器hold不住了，会各种拒绝访问，甚至崩溃，宕机，怎么办呢。
 
 一台机器解决不了的问题，那就两台。所以我们加一台机器，每台承担1百万。如果请求继续增加呢，两台解决不了的问题，那就三台呗。
 
 这种方式我们称之为水平扩展。如何实现请求的平均分配便是负载均衡了。
 
 另一个栗子，我们现在有两个数据请求，数据1 90万，数据2 80万，上面那台机器也hold不住，我们加一台机器来负载均衡一下，每台机器处理45万数据1和40万数据2，但是平分太麻烦，不如一台处理数据1，一台处理数据2，同样能解决问题，这种方式我们称之为垂直拆分。
 
 水平扩展和垂直拆分是分布式架构的两种思路，但并不是一个二选一的问题，更多的是兼并合用。下面介绍一个实际的场景。这也是许多互联网的公司架构思路。
 
 2.实际的例子
 
 我此时所在的公司的计算机系统很庞大，自然是一个整的分布式系统，为了方便组织管理，公司将整个技术部按业务和平台拆分为部门，订单的，会员的，商家的等等，每个部门有自己的web服务器集群，数据库服务器集群，通过同一个网站访问的链接可能来自于不同的服务器和数据库，对网站及底层对数据库的访问被分配到了不同的服务器集群,这个便是典型的按业务做的垂直拆分，每个部门的服务器在hold不住时，会有弹性的扩展，这便是水平扩展。
 
 在数据库层，有些表非常大，数据量在亿级，如果只是纯粹的水平的扩展并不一定最好，如果对表进行拆分，比如可以按用户id进行水平拆表，通过对id取模的方式，将用户划分到多张表中，同时这些表也可以处在不同的服务器。按业务的垂直拆库和按用户水平拆表是分布式数据库中通用的解决方案。
 
 比如 Mycat 开源分布式数据库中间件 http://www.mycat.io/
 
 3.分布式一致性
 
 分布式系统中，解决了负载均衡的问题后，另外一个问题就是数据的一致性了，这个就需要通过同步来保障。根据不同的场景和需求，同步的方式也是有选择的。
 
 在分布式文件系统中，比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。
 
 但银行中的分布式数据库就不一样了，一丁点不同步就是无法接受的，甚至可以通过加锁等牺牲性能的方式来保障完全的一致。
 
 在一致性算法中paxos算法是公认的最好的算法，Chubby、ZooKeeper 中Paxos是它保证一致性的核心。这个算法比较难懂，我目前也没弄懂，这里就不深入了。
 
 Contact
 
作者：鹏磊
出处：http://www.ymq.io/2018/01/23/Distributed-cluster/
Email：admin@souyunku.com
版权归作者所有，转载请注明出处
 
Wechat：关注公众号，“搜云库”，专注于开发技术的研究与知识分享
阅读原文 
 
http://click.aliyun.com/m/40944/

Hadoop常用于离线的复杂的大数据处理，Spark常用于离线的快速(轻量级)的大数据处理， Storm常用于在线的实时的大数据处理；这句话一定程度上反应了三套大数据平台的鲜明特征。Storm是一套实时、在线、分布式的大数据处理平台。
 
1）Nimbus和Supervisor
 
Storm集群中包含两类节点：主控节点（Master Node）和工作节点（Work Node），角色定位如下：
 
主控节点（MasterNode）上运行一个被称为Nimbus的后台程序，它负责在Storm集群内分发代码，分配任务给工作机器，并且负责监控集群运行状态。Nimbus的作用类似于Hadoop中JobTracker的角色。
 
每个工作节点（WorkNode）上运行一个被称为Supervisor的后台程序。Supervisor负责监听从Nimbus分配给它执行的任务，据此启动或停止执行任务的工作进程。每一个工作进程执行一个Topology的子集；一个运行中的Topology由分布在不同工作节点上的多个工作进程组成。
 

 
 
 
Nimbus和Supervisor节点之间所有的协调工作是通过Zookeeper集群来实现的。此外，Nimbus和Supervisor进程都是快速失败（fail-fast)和无状态（stateless）的；Storm集群所有的状态要么在Zookeeper集群中，要么存储在本地磁盘上。这意味着你可以用kill -9来杀死Nimbus和Supervisor进程，它们在重启后可以继续工作。这个设计使得Storm集群拥有不可思议的稳定性。
 
2）Topology
 一个topology是spouts和bolts组成的图， 通过streamgroupings将图中的spouts和bolts连接起来，如下图：

 

 
 
 
一个topology会一直运行直到你手动kill掉，Storm自动重新分配执行失败的任务， 并且Storm可以保证你不会有数据丢失（如果开启了高可靠性的话）。如果一些机器意外停机它上面的所有任务会被转移到其他机器上。
 
运行一个topology很简单。首先，把你所有的代码以及所依赖的jar打进一个jar包。然后运行类似下面的这个命令：
 
storm jarall-my-code.jar backtype.storm.MyTopology arg1 arg2
 
这个命令会运行主类: backtype.strom.MyTopology, 参数是arg1, arg2。这个类的main函数定义这个topology并且把它提交给Nimbus。storm jar负责连接到Nimbus并且上传jar包。Topology的定义是一个Thrift结构，并且Nimbus就是一个Thrift服务，可以提交由任何语言创建的topology。
 
3）Stream
 
消息流stream是storm里的关键抽象。一个消息流是一个没有边界的tuple序列， 而这些tuple序列会以一种分布式的方式并行地创建和处理。通过对stream中tuple序列中每个字段命名来定义stream。在默认的情况下，tuple的字段类型可以是：integer，long，short， byte，string，double，float，boolean和bytearray。你也可以自定义类型（只要实现相应的序列化器）。
 
每个消息流在定义的时候会被分配给一个id，因为单向消息流使用的相当普遍， OutputFieldsDeclarer定义了一些方法让你可以定义一个stream而不用指定这个id。在这种情况下这个stream会分配个值为‘default’默认的id 。
 
Storm提供的最基本的处理stream的原语是spout和bolt。你可以实现spout和bolt提供的接口来处理你的业务逻辑。
 
4）Spouts
 
消息源spout是Storm里面一个topology里面的消息生产者。一般来说消息源会从一个外部源读取数据并且向topology里面发出消息：tuple。Spout可以是可靠的也可以是不可靠的。如果这个tuple没有被storm成功处理，可靠的消息源spouts可以重新发射一个tuple， 但是不可靠的消息源spouts一旦发出一个tuple就不能重发了。
 
消息源可以发射多条消息流stream。使用OutputFieldsDeclarer.declareStream来定义多个stream，然后使用SpoutOutputCollector来发射指定的stream。
 
Spout类里面最重要的方法是nextTuple。要么发射一个新的tuple到topology里面或者简单的返回如果已经没有新的tuple。要注意的是nextTuple方法不能阻塞，因为storm在同一个线程上面调用所有消息源spout的方法。
 
另外两个比较重要的spout方法是ack和fail。storm在检测到一个tuple被整个topology成功处理的时候调用ack，否则调用fail。storm只对可靠的spout调用ack和fail。
 
5）Bolts
 
所有的消息处理逻辑被封装在bolts里面。Bolts可以做很多事情：过滤，聚合，查询数据库等等。
 
Bolts可以简单的做消息流的传递。复杂的消息流处理往往需要很多步骤，从而也就需要经过很多bolts。比如算出一堆图片里面被转发最多的图片就至少需要两步：第一步算出每个图片的转发数量。第二步找出转发最多的前10个图片。（如果要把这个过程做得更具有扩展性那么可能需要更多的步骤）。
 
Bolts可以发射多条消息流， 使用OutputFieldsDeclarer.declareStream定义stream，使用OutputCollector.emit来选择要发射的stream。
 
Bolts的主要方法是execute,它以一个tuple作为输入，bolts使用OutputCollector来发射tuple，bolts必须要为它处理的每一个tuple调用OutputCollector的ack方法，以通知Storm这个tuple被处理完成了，从而通知这个tuple的发射者spouts。 一般的流程是： bolts处理一个输入tuple,  发射0个或者多个tuple, 然后调用ack通知storm自己已经处理过这个tuple了。storm提供了一个IBasicBolt会自动调用ack。
 
6）Stream groupings
 
义一个topology的其中一步是定义每个bolt接收什么样的流作为输入。stream grouping就是用来定义一个stream应该如何分配数据给bolts上面的多个tasks。
 
Storm里面有7种类型的stream grouping
 
ü   ShuffleGrouping: 随机分组，随机派发stream里面的tuple，保证每个bolt接收到的tuple数目大致相同。
 
ü   FieldsGrouping：按字段分组，比如按userid来分组， 具有同样userid的tuple会被分到相同的Bolts里的一个task， 而不同的userid则会被分配到不同的bolts里的task。
 
ü   All Grouping：广播发送，对于每一个tuple，所有的bolts都会收到。
 
ü   GlobalGrouping：全局分组，这个tuple被分配到storm中的一个bolt的其中一个task。再具体一点就是分配给id值最低的那个task。
 
ü   Non Grouping：不分组，这个分组的意思是说stream不关心到底谁会收到它的tuple。目前这种分组和Shuffle grouping是一样的效果， 有一点不同的是storm会把这个bolt放到这个bolt的订阅者同一个线程里面去执行。
 
ü   DirectGrouping： 直接分组，这是一种比较特别的分组方法，用这种分组意味着消息的发送者指定由消息接收者的哪个task处理这个消息。 只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发射。消息处理者可以通过TopologyContext来获取处理它的消息的task的id （OutputCollector.emit方法也会返回task的id）。
 
ü   Local orshuffle grouping：如果目标bolt有一个或者多个task在同一个工作进程中，tuple将会被随机发生给这些tasks。否则，和普通的Shuffle Grouping行为一致。
 
7）Tasks和Workers
 
每一个spout和bolt会被当作很多task在整个集群里执行。每一个executor对应到一个线程，在这个线程上运行多个task，而stream grouping则是定义怎么从一堆task发射tuple到另外一堆task。你可以调用TopologyBuilder类的setSpout和setBolt来设置并行度（也就是有多少个task）。
 
一个topology可能会在一个或者多个worker（工作进程）里面执行，每个worker是一个物理JVM并且执行整个topology的一部分。比如，对于并行度是300的topology来说，如果我们使用50个工作进程来执行，那么每个工作进程会处理其中的6个tasks。Storm会尽量均匀的工作分配给所有的worker。
 
8）Configuration
 Storm里面有一堆参数可以配置来调整Nimbus, Supervisor以及正在运行的topology的行为，一些配置是系统级别的，一些配置是topology级别的。default.yaml里面有所有的默认配置。你可以通过定义个storm.yaml在你的classpath里来覆盖这些默认配置。并且你也可以在代码里面设置一些topology相关的配置信息（使用StormSubmitter）。