分布式文件服务器搭建

1. 如何部署hadoop分布式文件系统

一、实战环境
系统版本：CentOS 5.8x86_64
java版本：JDK-1.7.0_25
Hadoop版本：hadoop-2.2.0
192.168.149.128namenode （充当namenode、secondary namenode和ResourceManager角色）
192.168.149.129datanode1 （充当datanode、nodemanager角色）
192.168.149.130datanode2 （充当datanode、nodemanager角色）

二、系统准备

1、Hadoop可以从Apache官方网站直接下载最新版本Hadoop2.2。官方目前是提供了linux32位系统可执行文件，所以如果需要在64位系统上部署则需要单独下载src 源码自行编译。（如果是真实线上环境，请下载64位hadoop版本，这样可以避免很多问题，这里我实验采用的是32位版本）
1234 Hadoop
Java

2、我们这里采用三台CnetOS服务器来搭建Hadoop集群，分别的角色如上已经注明。
第一步：我们需要在三台服务器的/etc/hosts里面设置对应的主机名如下（真实环境可以使用内网DNS解析）
[root@node1 hadoop]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1localhost.localdomain localhost
192.168.149.128node1
192.168.149.129node2
192.168.149.130node3

（注* 我们需要在namenode、datanode三台服务器上都配置hosts解析）
第二步：从namenode上无密码登陆各台datanode服务器，需要做如下配置:
在namenode 128上执行ssh-keygen，一路Enter回车即可。
然后把公钥/root/.ssh/id_rsa.pub拷贝到datanode服务器即可，拷贝方法如下：
ssh--id -i .ssh/id_rsa.pub [email protected]
ssh--id -i .ssh/id_rsa.pub [email protected]

三、Java安装配置
tar -xvzf jdk-7u25-linux-x64.tar.gz &&mkdir -p /usr/java/ ; mv /jdk1.7.0_25 /usr/java/ 即可。
安装完毕并配置java环境变量，在/etc/profile末尾添加如下代码：
export JAVA_HOME=/usr/java/jdk1.7.0_25/
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=$JAVE_HOME/lib/dt.jar:$JAVE_HOME/lib/tools.jar:./

保存退出即可，然后执行source /etc/profile 生效。在命令行执行java -version 如下代表JAVA安装成功。
[root@node1 ~]# java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

（注* 我们需要在namenode、datanode三台服务器上都安装Java JDK版本）
四、Hadoop版本安装
官方下载的hadoop2.2.0版本，不用编译直接解压安装就可以使用了，如下：
第一步解压:
tar -xzvf hadoop-2.2.0.tar.gz &&mv hadoop-2.2.0/data/hadoop/
（注* 先在namenode服务器上都安装hadoop版本即可，datanode先不用安装，待会修改完配置后统一安装datanode）

第二步配置变量：
在/etc/profile末尾继续添加如下代码，并执行source /etc/profile生效。
export HADOOP_HOME=/data/hadoop/
export PATH=$PATH:$HADOOP_HOME/bin/
export JAVA_LIBRARY_PATH=/data/hadoop/lib/native/
（注* 我们需要在namenode、datanode三台服务器上都配置Hadoop相关变量）

五、配置Hadoop
在namenode上配置，我们需要修改如下几个地方：
1、修改vi /data/hadoop/etc/hadoop/core-site.xml 内容为如下：
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl"href=\'#\'" Put site-specific property overrides inthisfile. -->
<configuration>
<property>
<name>fs.default.name</name>
<value>hdfs://192.168.149.128:9000</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/tmp/hadoop-${user.name}</value>
<description>A base forother temporary directories.</description>
</property>
</configuration>

2、修改vi /data/hadoop/etc/hadoop/mapred-site.xml内容为如下：
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl"href=\'#\'" Put site-specific property overrides inthisfile. -->
<configuration>
<property>
<name>mapred.job.tracker</name>
<value>192.168.149.128:9001</value>
</property>
</configuration>

3、修改vi /data/hadoop/etc/hadoop/hdfs-site.xml内容为如下：
<?xml version="1.0"encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl"href=\'#\'" /name>
<value>/data/hadoop/data_name1,/data/hadoop/data_name2</value>
</property>
<property>
<name>dfs.data.dir</name>
<value>/data/hadoop/data_1,/data/hadoop/data_2</value>
</property>
<property>
<name>dfs.replication</name>
<value>2</value>
</property>
</configuration>

4、在/data/hadoop/etc/hadoop/hadoop-env.sh文件末尾追加JAV_HOME变量：
echo "export JAVA_HOME=/usr/java/jdk1.7.0_25/">> /data/hadoop/etc/hadoop/hadoop-env.sh

5、修改 vi /data/hadoop/etc/hadoop/masters文件内容为如下：
192.168.149.128

6、修改vi /data/hadoop/etc/hadoop/slaves文件内容为如下：
192.168.149.129
192.168.149.130

如上配置完毕，以上的配置具体含义在这里就不做过多的解释了，搭建的时候不明白，可以查看一下相关的官方文档。
如上namenode就基本搭建完毕，接下来我们需要部署datanode，部署datanode相对简单，执行如下操作即可。
1 fori in`seq 129130` ; doscp -r /data/hadoop/ [email protected].$i:/data/ ; done

自此整个集群基本搭建完毕，接下来就是启动hadoop集群了。

2. C++实现分布式文件解析系统

整个分布式文件解析系统一共有四个角色：任务分配服务器、文件解析服务器、工作站和管理平台。在一个大型的网络中，有若干个用户（即“工作站”）随机地通过“任务分配服务器”向若干个“文件解析服务器”提交文本文件。“文件解析服务器”将收到的文件解析后写入log文件中。“管理平台”负责以可视化的界面观察所有连接到的“任务分配服务器”和“工作站”的ip及工作状态。

任务分配服务器的作用是轮流地将来自“工作站”的文件传送请求转发到每个在线的“文件解析服务器”上，从而避免某个特定的“文件解析服务器”工作负载太重。“任务分配服务器”轮流给所有在线的“文件解析服务器”分配任务。轮流的原则是按每工作站每批轮流，不考虑每批文件的数量多少。当有“工作站”准备传送一批文件时，首先连接任务分配服务器，通知任务分配服务器有一批文件待传。任务分配服务器则把该工作站的IP和端口告诉选定的“文件解析服务器”，以便让“文件分析服务器”能主动和“工作站”连接，并完成该批文件传输。

ps：主动的含义是文件分析服务器主动通过 connect 连接工作站。“任务分配服务器”本身不接收或转发文件。工作站每次都是按批提交文件，一批文件的数量不等。

“文件解析服务器”每收到用户的一批文件后，就自动对该批文件进行“文件解析”。“文件解析”的功能是：

管理平台的作用是采用图形化的方式展示目前在线的工作站，文件分析服务器的工作状态。能展示工作站的IP，工作状态（传文件中或没有传文件）。能展示文件分析服务器的IP，工作状态（接收文件中，文件分析中，没有传文件，没有文件被分析）。当一个工作站或文件分析服务器宕机，能实时更新状态。

整个系统的工作流程如下图所示：

该项目源码在 https://github.com/toMyLord/DistributedFileParsingSystem

src目录下包含 Server 类、 Client 类、 SpecificTime 类。 Server 类用于服务器初始化，监听 socket_fd ，接受来自客户端的连接请求，接收或发送信息，关闭套接字。 Client 类用于客户端初始化，连接服务器，与服务器进行全双工通信，关闭连接。 SpecificTime 类用于获取当前系统的时间，并以规定的格式返回一个 std::string 类型的字符串。上述三个类会被用于所有角色，因此以一个目录的形式单独放在所有角色所属目录外，通过CmakeLists.txt将这些文件的编译相关性联系在一起，从而生成可执行文件。

该目录下为编译 TaskDistribution 所需要的专属文件。在当前目录下的src目录内，定义了 DistributionServer 类，该类内组合了DistributedFileParsingSystem/src目录下的 Server 类。实现 DistributionServer 类的目的是为了使用该类监听特定端口的所有网络连接，并将所有连接的客户端信息都存储在一个 std::vector 容器内。 DistributionServer 类的定义如下：

在 ClientNode 结构体内嵌套的 ClientInfo 结构体声明和定义在DistributedFileParsingSystem/src/server.h文件内， ClientInfo 结构体保存了连接到 server 的客户端的 sockaddr_in 、 socket_fd 以及ip信息。 ClientNode 结构体扩展了一个新的字段 client_state ，该字段用来描述客户端的传输状态。

通过 std::vector<ClientNode> 将所有连接的客户端信息都保存下来。每当有新的客户端连接，就使用 client_node.push_back() 将信息保存在内存中。如果有已连接的客户端断开连接，需要用 find_if() 函数配合 lambda 表达式找到在 vector 中的迭代器，然后断开连接并删除 client_node 中对应的数据。具体过程如下：

TaskDistribution_main.cpp是任务分配服务器可执行文件编译所需的主函数。在该文件内声明了两个 DistributionServer 类的实例 workstation_server 和 parsing_server ，一个 Server 类的实例 manager_server ，分别用来处理来自工作站、文件解析服务器、管理平台的连接。因为任务分配服务器只允许一个管理平台连接，因此管理平台选择 Server 类，因为可能会有大量工作站和文件解析服务器连接至任务分配服务器，因此选择 DistributionServer 来分别监听工作站和文件解析服务器的连接端口。

在主函数中，我选择使用 epoll ——IO多路复用技术来监听工作站、文件解析服务器和管理平台的连接请求，从而实现在单进程中对三个端口进行监听。

当有管理平台连接至任务分配服务器后，任务分配服务器就不再处理来自管理平台的连接请求，直到当前管理平台退出。

当有文件解析服务器连接至任务分配服务器后，任务分配服务器会将文件解析添加至就绪队列，等待来自工作站的请求。每当有工作站发出文件传输请求，就将处于就绪队列顶端的文件解析服务器出队列，并分配给当前工作站用来处理解析任务。处理完文件解析任务后，任务分配服务器会将文件解析服务器重新加入队列。

当工作站连接至任务分配服务器后，任务分配服务器会建立一个新的线程用来处理工作站发出的请求。当工作站发出文件解析请求后，该线程会将就绪队列顶端的文件解析服务器分配给工作站，并一直监控整个解析过程，直到解析完成，将文件解析服务器重新入队列。完成后此线程会重新监听来自工作站的解析请求，直到工作站断开连接，该线程就会消亡。如果工作站发出解析请求后，没有任务文件解析服务器就绪，那么任务分配服务器会每过1s检测一次是否有就绪的文件解析服务器（此处可以改进，将每秒轮询的方式改为等待时长者优先策略）。

该目录下为编译 TaskDistribution 所需要的专属文件。在当前目录下的src目录内，主要实现两个功能： 使用单例模式实现日志文件记录 、 使用状态模式实现文件解析服务器在等待状态和解析状态之间的切换 。

使用单例模式来实现日志记录的 RecordingLog 类的实例只会创建一次，从而避免创建多个日志类实例，造成写入混乱的情况。 RecordingLog 类会将特定信息以 filesteam 的方式写入文件中，具体被记录在日志文件中的信息包括接收来自工作站文件的时间、日期、工作站ip、工作站端口、文件名、文件前8个字节内容、文件总长度。该类的声明情况如下所示：

在本系统的FileParsing程序中，使用状态模式用来处理文件解析服务器的状态转换。文件解析服务器主要有两种状态——等待任务分配服务器发送解析文件请求状态和接受来自工作站的文件并完成解析，写入日志文件的状态。

在第一种状态下，文件解析服务器收到来自任务分配服务器的解析请求后，会将需要主动连接的工作站的ip及端口保存下来，并切换到第二种状态。

在第二种状态下，文件解析服务器根据保存的ip和端口主动连接工作站，连接完成后接收来自工作站的文件信息，解析后通过 RecordingLog 类中的 getLogInstance() 函数将解析后的结果写入日志文件，完成后会将解析完成情况回传给任务分配服务器，在任务分配服务器中，将该文件解析服务器重新添加到就绪队列。之后会主动切换到第一种状态，再次等待任务请求。

这部分程序使用了状态模式，使得文件解析服务器在等待分配任务状态及解析文件状态自动切换，从而保证了两种状态上的逻辑分离，具有非常好的封装性，并体现了开闭原则和单一职责原则：每个状态都是一个子类，如果需要增加状态就只需要增加子类，如果需要修改状态，就只需要修改一个子类即可完成，具有很高的扩展性。

该目录下为编译 WorkStation 所需要的专属文件。在当前目录下的src目录内，定义了 SendDirectory 类。通过该类，可以实现根据输入的一个目录，自动发送该目录下的所有文件。注意，该目录下不可再包含目录。

该目录下为编译 Managerplatform 所需要的专属文件。此目录可以使用QtCreater打开，但是编译还是需要根据DistributedFileParsingSystem/CMakeLists.txt文件通过cmake编译。

该目录下的 ClientThread 类通过继承 QThread 类，实现在Qt中使用线程。在该部分程序运行时，就会创建一个 ClientThread 线程，用于与任务分配服务器建立连接，并不断接受来自任务分配服务发送的有关工作站及文件解析服务器的在线状态以及传输状态。每当有新的信息后，就通过Qt的槽机制，发送给 QDialog ，显示在界面中。

编译完成后会生成四个可执行文件：TaskDistribution、FileParsing、WorkStation、ManagerPlatform。

运行过程如下所示：
首先分别运行每个可执行程序，其中运行两个FileParsing程序（上线两个文件解析服务器）：

在WorkStation程序下输入需要发送的文件目录：

可以在任务分配服务器的log中看到有新上线的文件解析服务器，同时在管理平台也可以看到对应的文件解析服务器。我们通过工作站连续发送三次文件。

实现了整个分布式任务解析服务器框架，整个项目可以正常实现需求功能。
缺陷：任务分配服务器存在不能正常处理所有连接的正常close。

在任务分配服务器处新增了心跳包机制——任务分配服务器会每隔5s向所有连接在线的文件解析服务器和工作站发送心跳包，文件解析服务器和工作站在收到心跳包后，也会主动回应心跳。通过心跳包机制可以很好的处理来自其他连接的断开情况。同时新增了在管理平台退出后，任务分配服务器可以重新接受来自管理平台的连接。

3. GlusterFS分布式文件系统的安装配置教程

GlusterFS主要应用在集群系统中，具有很好的可扩展性。软件的结构设计良好，易于扩展和配置，通过各个模块的灵活搭配以得到针对性的解决方案。可解决以下问题：网络存储，联合存储(融合多个节点上的存储空间)，冗余备份，大文件的负载均衡(分块)。
由于缺乏一些关键特性，可靠性也未经过长时间考验，还不适合应用于需要提供 24 小时不间断服务的产品环境。目前适合应用于大数据量的离线应用，下面一起来看GlusterFS分布式文件系统的安装配置
GlusterFS是一个开源的分布式文件系统，用户可以使用多台服务器，并通过以太网或者Infiniband RDMA互联从而组成一个GlusterFS的集群
。
GlusterFS集群对外提供NFS，CIFS和Gluster Native(通过FUSE进行挂载)的接口以便用户访问GlusterFS的存储池。
GlusterFS使用了弹性哈希算法来定位文件存储的位置。 由于使用了弹性哈希算法，GlusterFS不需要专门的Meta-Data Server来保存元数据，因此可以避免因为元数据服务器宕机导致的整个集群不可用。
也正是因为不需要元数据服务器，所以GlusterFS在多个挂载点同时进行数据读写的时候，其整体性能很突出。
fuse-2.9.3.tar.gz #依赖于fuse
glusterfs-3.6.0.tar.gz #本文用的版本
准备2台机器，系统为centos6.5 64位。
IP地址 主机名
192.168.0.107 g1
192.168.0.136 g2
首先关闭iptables和selinux。
修改主机名，并添加hosts映射：
g1:
[root@localhost ~]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=g1
[root@localhost ~]# hostname
g1
[root@localhost ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.0.107 g1
192.168.0.136 g2
g2:
[root@localhost ~]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=g2
[root@localhost ~]# hostname
g2
[root@localhost ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.0.107 g1
192.168.0.136 g2
安装预编译环境：
[root@localhost ~]# yum install -y gcc gcc-c++ flex flex-devel bison bison-devel openssl openssl-devel libxml2 libxml2-devel
安装fuse：
[root@localhost ~]# cd fuse-2.9.3
[root@localhost fuse-2.9.3]# ./configure make make install
[root@localhost fuse-2.9.3]# cd
安装gluster：
[root@localhost ~]# cd glusterfs-3.6.0
[root@localhost glusterfs-3.6.0]# ./configure --prefix=/usr/local/glusterfs make make install
g1和g2均执行上面操作。
g1和g2启动gluster：
[root@localhost ~]# service glusterd start
添加集群：
[root@localhost ~]# ln -s /usr/local/glusterfs/sbin/gluster /usr/bin/gluster #做一个软链接方便执行命令
[root@localhost ~]# gluster peer probe g2 #在g1中将g2加入到gluster集群中，本机(g1)不需要加入。
peer probe: success. Probe on localhost not needed
查看集群信息：
[root@localhost ~]# gluster peer status
Number of Peers: 1
Hostname: g2
Uuid: c7aa664a-3161-4716-9f81-2dc4b4718fa1
State: Peer in Cluster (Connected) #已连接
剔除机器：
[root@localhost ~]# gluster peer detach g2
peer detach: success
创建卷：
[root@localhost ~]# gluster volume create test-volume replica 2 transport tcp g1:/data g2:/data force
volume create: test-volume: success: please start the volume to access data
test-volume 卷名 replica 副本数 transport 传输协议 g1:/data 服务器名及存储路径
启动卷：
[root@localhost ~]# gluster volume start test-volume
volume start: test-volume: success
查看卷：
[root@localhost ~]# gluster volume info
Volume Name: test-volume
Type: Replicate
Volume ID: 104d73c5-17f5-4150-a40d-b97cd78dd6bb
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: g1:/data
Brick2: g2:/data
客户端1挂载(同样安装fuse和glusterfs才能支持glusterfs文件系统)：
[root@localhost ~]# mkdir /mnt/gfs
[root@localhost ~]# mount -t glusterfs g1:test-volume /mnt/gfs/
[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 77G 3.7G 70G 6% /
tmpfs 499M 0 499M 0% /dev/shm
g1:test-volume 77G 3.8G 70G 6% /mnt/gfs
客户端2挂载：
[root@localhost ~]# mkdir /mnt/gfs
[root@localhost ~]# mount -t glusterfs g2:test-volume /mnt/gfs
[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 77G 3.8G 70G 6% /
tmpfs 499M 0 499M 0% /dev/shm
g2:test-volume 77G 3.8G 70G 6% /mnt/gfs
可以看到g1和g2都支持挂载。
gluster支持的参
[root@localhost ~]# gluster help #查看参数
安装配置完成。

4. 如何用java 建立一个分布式系统

分布式架构的演进

系统架构演化历程-初始阶段架构

初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

特征：
应用程序、数据库、文件等所有的资源都在一台服务器上。

描述：
通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用Mysql，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

系统架构演化历程-应用服务和数据服务分离

好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver

特征：
应用程序、数据库、文件分别部署在独立的资源上。

描述：
数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。

系统架构演化历程-使用缓存改善性能

特征：
数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。

描述：
系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。
缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。

系统架构演化历程-使用应用服务器集群

在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢

特征：
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。
系统架构演化历程-数据库读写分离

享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢

特征：
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，使得服务器的负载压力不在成为整个系统的瓶颈。
系统架构演化历程-反向代理和CDN加速

特征：
采用CDN和反向代理加快系统的 访问速度。

描述：
为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
系统架构演化历程-分布式文件系统和分布式数据库

随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作

特征：
数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：
任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
系统架构演化历程-使用NoSQL和搜索引擎

特征：
系统引入NoSQL数据库及搜索引擎。

描述：
随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
系统架构演化历程-业务拆分

特征：
系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：
为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：
将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统

纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务

横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

系统架构演化历程-分布式服务

特征：
公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。

描述：
随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

Q：分布式服务应用会面临哪些问题？

A：
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
(5) 一个服务有多个业务消费者，如何确保服务质量？
(6) 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？

Java分布式应用技术基础

分布式服务下的关键技术：消息队列架构

消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息
分布式服务下的关键技术：消息队列原理

分布式服务下的关键技术：服务框架架构

服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务框架是一个点对点模型
服务框架面向同构系统
适合：移动应用、互联网应用、外部系统

分布式服务下的关键技术：服务框架原理

分布式服务下的关键技术：服务总线架构

服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务总线是一个总线式的模型
服务总线面向同构、异构系统
适合：内部系统

分布式服务下的关键技术：服务总线原理

分布式架构下系统间交互的5种通信模式

request/response模式（同步模式）：客户端发起请求一直阻塞到服务端返回请求为止。

Callback（异步模式）：客户端发送一个RPC请求给服务器，服务端处理后再发送一个消息给消息发送端提供的callback端点，此类情况非常合适以下场景：A组件发送RPC请求给B，B处理完成后，需要通知A组件做后续处理。

Future模式：客户端发送完请求后，继续做自己的事情，返回一个包含消息结果的Future对象。客户端需要使用返回结果时，使用Future对象的.get(),如果此时没有结果返回的话，会一直阻塞到有结果返回为止。

Oneway模式：客户端调用完继续执行，不管接收端是否成功。

Reliable模式：为保证通信可靠，将借助于消息中心来实现消息的可靠送达，请求将做持久化存储，在接收方在线时做送达，并由消息中心保证异常重试。
五种通信模式的实现方式-同步点对点服务模式

五种通信模式的实现方式-异步点对点消息模式1

五种通信模式的实现方式-异步点对点消息模式2

五种通信模式的实现方式-异步广播消息模式

分布式架构下的服务治理

服务治理是服务框架/服务总线的核心功能。所谓服务治理，是指服务的提供方和消费方达成一致的约定，保证服务的高质量。服务治理功能可以解决将某些特定流量引入某一批机器，以及限制某些非法消费者的恶意访问，并在提供者处理量达到一定程度是，拒绝接受新的访问。

基于服务框架Dubbo的服务治理-服务管理

可以知道你的系统，对外提供了多少服务，可以对服务进行升级、降级、停用、权重调整等操作
可以知道你提供的服务，谁在使用，因业务需求，可以对该消费者实施屏蔽、停用等操作

基于服务框架Dubbo的服务治理-服务监控
可以统计服务的每秒请求数、平均响应时间、调用量、峰值时间等，作为服务集群规划、性能调优的参考指标。

基于服务框架Dubbo的服务治理-服务路由

基于服务框架Dubbo的服务治理-服务保护

基于服务总线OSB的服务治理-功能介绍

基于服务总线OSB的服务治理

Q：Dubbo到底是神马？
A：
淘宝开源的高性能和透明化的RPC远程调用服务框架
SOA服务治理方案
Q：Dubbo原理是？
A：

-结束-

5. 如何搭建分布式服务器

如何搭建分布式网站服务器，比如我有3台服务器ABC，需要搭建分布式服务。也就需要建立IIS 还由DNS WIN 服务器的 还有更改主机名 很麻烦的,这个需要专业的IT人员来操作的。

以下资料作为参考：
DNS轮循
首先介绍一个DNS系统:传统的DNS解析都是一个域名对应一个IP地址,但是通过DNS轮循技术(负载平衡技术)可以做到一个域名对应到多个IP 上. 这样大家难免就会问,这个技术有什么用呢?

DNS轮循是指将相同的域名解释到不同的IP，随机使用其中某台主机的技术,该项技术可以智能的调整网站的访问量到不同服务器上，减轻网站服务器的压力，实现负载匀衡;如果您感觉到单一的主机已经不堪负载你网站日益增长的访问，那么建议您采用我们的DNS轮循技术。

DNS轮循系统可以根据您的需求设置N台主机作为WEB服务器。目前已有越来多大型的WEB服务器使用DNS轮循来实现负载均衡，服务的分布规划更便捷，扩展性更好，从而提高了网站的稳定性和访问效率，那些大量数据文件请求的客户也得到了更快的响应。

DNS轮循还将给您的网站提供这样的改进，诸如您的网站的数据使用量一直处于不断的增长当中，当达到服务器资源运行瓶颈的情况
下，由于采用了DNS轮循技术，您只需要增加服务器数量就可以平滑升级，而且偶然故障或其他意外情况造成的损失得以避免，7×24小时可靠性的持续的运行
成为可能。

如果您真的希望自己的网站能够一直稳定的在线运行，尽量的减少宕机的比率，那么除了采用比较好的网站空间技术支持之外，还可以采用时代互联域名的DNS轮循功能来实现网站的永久在线负载平衡
负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其
他服务器的辅助。通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。均衡负载
能够平均分配客户请求到服务器列阵，籍此提供快速获取重要数据，解决大量并发访问服务问题。这种群集技术可以用最少的投资获得接近于大型主机的性能。

网络负载均衡的优点

第一，网络负载均衡能将传入的请求传播到多达32台服务器上，即可以使用最多32台服务器共同分担对外的网络请求服务。网络负载均衡技术保证即使是在负载很重的情况下，服务器也能做出快速响应;

第二，网络负载均衡对外只需提供一个IP地址(或域名);

第三，当网络负载均衡中的一台或几台服务器不可用时，服务不会中断。网络负载均衡自动检测到服务器不可用时，能够迅速在剩余的
服务器中重新指派客户机通讯。这项保护措施能够帮助你为关键的业务程序提供不中断的服务，并可以根据网络访问量的增加来相应地增加网络负载均衡服务器的数
量;

第四，网络负载均衡可在普通的计算机上实现。

网络负载均衡的实现过程

在Windows Server 2003中，网络负载均衡的应用程序包括Internet信息服务(IIS)、ISA
Server 2000防火墙与代理服务器、VPN虚拟专用网、终端服务器、Windows Media
Services(Windows视频点播、视频广播)等服务。同时，网络负载均衡有助于改善服务器的性能和可伸缩性，以满足不断增长的基于
Internet客户端的需求。

网络负载均衡可以让客户端用一个逻辑Internet名称和虚拟IP地址(又称群集IP地址)访问群集，同时保留每台计算机各自的名称。下面，我们将在两台安装Windows Server 2003的普通计算机上，介绍网络负载均衡的实现及应用。

这两台计算机中，一台计算机名称为A，IP地址为192.168.0.7;另一台名为B，IP地址为192.168.0.8。
规划网络负载均衡专用虚拟IP地址为192.168.0.9。当正式应用时，客户机只需要使用IP地址192.168.0.9来访问服务器，网络服务均衡
会根据每台服务器的负载情况自动选择192.168.0.7或者192.168.0.8对外提供服务。具体实现过程如下：

在实现网络负载均衡的每一台计算机上，只能安装TCP/IP协议，不要安装任何其他的协议(如IPX协议或者NetBEUI协议)，这可以从“网络连接属性”中查看。

第一步，分别以管理员身份登录A机和B机，打开两台机的“本地连接”属性界面，勾选“此连接使用下列项目”中的“负载均衡”项并进入“属性”对话框，将IP地址都设为192.168.0.9(即负载均衡专用IP)，将子网掩码设置为255.255.255.0;

第二步，分别进入A机和B机的“Internet协议(TCP/IP)”属性设置界面，点击“高级”按钮后，在弹出的“高级TCP/IP设置”界面中添加IP地址192.168.0.9和子网掩码设置为255.255.255.0。

第三步，退出两台计算机的“本地连接属性”窗口，耐心等一会儿让系统完成设置。
以后，如果这两台服务器不能满足需求，可以按以上步骤添加第三台、第四台计算机到网络负载均衡系统中以满足要求。

6. 基于mogileFS搭建分布式文件系统--海量小文件的存储利器

1.简介

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样。

当下我们处在一个互联网飞速发展的信息 社会 ，在海量并发连接的驱动下每天所产生的数据量必然以几何方式增长，随着信息连接方式日益多样化，数据存储的结构也随着发生了变化。在这样的压力下使得人们不得不重新审视大量数据的存储所带来的挑战，例如：数据采集、数据存储、数据搜索、数据共享、数据传输、数据分析、数据可视化等一系列问题。

传统存储在面对海量数据存储表现出的力不从心已经是不争的事实，例如：纵向扩展受阵列空间限制、横向扩展受交换设备限制、节点受文件系统限制。

然而分布式存储的出现在一定程度上有效的缓解了这一问题，之所以称之为缓解是因为分布式存储在面对海量数据存储时也并非十全十美毫无压力，依然存在的难点与挑战例如：节点间通信、数据存储、数据空间平衡、容错、文件系统支持等一系列问题仍处在不断摸索和完善中。

2.分布式文件系统的一些解决方案

Google Filesystem适合存储海量大个文件，元数据存储与内存中

HDFS（Hadoop Filesystem）GFS的山寨版，适合存储大量大个文件

TFS（Taobao Filesystem）淘宝的文件系统，在名称节点上将元数据存储与关系数据库中，文件数量不在受限于名称节点的内容空间，可以存储海量小文件LustreOracle开发的企业级分布式系统，较重量级MooseFS基于FUSE的格式，可以进行挂载使用MogileFS

擅长存储海量的小数据，元数据存储与关系型数据库中

1.简介

MogileFS是一个开源的分布式文件系统，用于组建分布式文件集群，由LiveJournal旗下DangaInteractive公司开发，Danga团队开发了包括 Memcached、MogileFS、Perlbal等不错的开源项目：(注：Perlbal是一个强大的Perl写的反向代理服务器)。MogileFS是一个开源的分布式文件系统。

目前使用 MogileFS 的公司非常多,比如国外的一些公司,日本前几名的公司基本都在使用这个.

国内所知道的使用 MogileFS 的公司有图片托管网站 yupoo又拍,digg, 薯仔, 豆瓣,1 号店, 大众点评,搜狗,安居客等等网站.基本很多网站容量，图片都超过 30T 以上。

2.MogileFS特性

1) 应用层提供服务，不需要使用核心组件

2）无单点失败，主要有三个组件组成，分为tracker（跟踪节点）、mogstore（存储节点）、database（数据库节点）

3）自动复制文件，复制文件的最小单位不是文件，而是class

4）传输中立，无特殊协议，可以通过NFS或HTTP实现通信

5）简单的命名空间：没有目录，直接存在与存储空间上，通过域来实现

6）不用共享任何数据

3.MogileFS的组成

1）Tracker--跟踪器，调度器

MogileFS的核心，是一个调度器，mogilefsd进程就是trackers进程程序,trackers的主要职责有：删除数据、复制数据、监控、查询等等.这个是基于事件的( event-based ) 父进程/消息总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到多个"query workers"中,然后让 mogilefs的子进程去处理.

mogadm,mogtool的所有操作都要跟trackers打交道,Client的一些操作也需要定义好trackers,因此最好同时运行多个trackers来做负载均衡.trackers也可以只运行在一台机器上，使用负载均衡时可以使用搞一些简单的负载均衡解决方案，如haproxy，lvs，nginx等，

tarcker的配置文件为/etc/mogilefs/mogilefsd.conf，监听在TCP的7001端口

2）Database--数据库部分

主要用来存储mogilefs的元数据，所有的元数据都存储在数据库中，因此，这个数据相当重要，如果数据库挂掉，所有的数据都不能用于访问，因此，建议应该对数据库做高可用

3）mogstored--存储节点

数据存储的位置，通常是一个HTTP（webDAV）服务器，用来做数据的创建、删除、获取，任何 WebDAV 服务器都可以, 不过推荐使用 mogstored . mogilefsd可以配置到两个机器上使用不同端口… mogstored 来进行所有的 DAV 操作和流量,IO监测, 并且你自己选择的HTTP服务器(默认为 perlbal)用来做 GET 操作给客户端提供文件.

典型的应用是一个挂载点有一个大容量的SATA磁盘. 只要配置完配置文件后mogstored程序的启动将会使本机成为一个存储节点.当然还需要mogadm这个工具增加这台机器到Cluster中.

配置文件为/etc/mogilefs/mogstored.conf，监听在TCP的7500端口

4.基本工作流程

应用程序请求打开一个文件 (通过RPC 通知到 tracker, 找到一个可用的机器). 做一个 “create_open” 请求.

tracker 做一些负载均衡(load balancing)处理，决定应该去哪儿，然后给应用程序一些可能用的位置。

应用程序写到其中的一个位置去 (如果写失败，他会重新尝试并写到另外一个位置去）.

应用程序 (client) 通过”create_close” 告诉tracker文件写到哪里去了.

tracker 将该名称和域命的名空间关联 (通过数据库来做的)

tracker, 在后台, 开始复制文件，知道他满足该文件类别设定的复制规则

然后,应用程序通过 “get_paths” 请求 domain+key (key == “filename”) 文件, tracker基于每一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的一些抉择处理), 该文件可用的完整 URLs地址列表.

应用程序然后按顺序尝试这些URL地址. (tracker’持续监测主机和设备的状态，因此不会返回死连接,默认情况下他对返回列表中的第一个元素做双重检查，除非你不要他这么做..)

1.拓扑图

说明：1.用户通过URL访问前端的nginx

2.nginx根据特定的挑选算法，挑选出后端一台tracker来响应nginx请求

3.tracker通过查找database数据库，获取到要访问的URL的值，并返回给nginx

4.nginx通过返回的值及某种挑选算法挑选一台mogstored发起请求

5.mogstored将结果返回给nginx

6.nginx构建响应报文返回给客户端

2.ip规划

角色运行软件ip地址反向代理nginx192.168.1.201存储节点与调度节点1

mogilefs192.168.1.202存储节点与调度节点2

mogilefs192.168.1.203数据库节点

MariaDB192.168.1.204

3.数据库的安装操作并为授权

关于数据库的编译安装，请参照本人相关博文http://wangfeng7399.blog.51cto.com/3518031/1393146，本处将不再累赘，本处使用的为yum源的安装方式安装mysql

4.安装mogilefs. 安装mogilefs，可以使用yum安装，也可以使用编译安装，本处通过yum安装

5.初始化数据库

可以看到在数据库中创建了一些表

6.修改配置文件，启动服务

7.配置mogilefs

添加存储主机

添加存储设备

添加域

添加class

8.配置192.168.1.203的mogilefs 。切记不要初始化数据库，配置应该与192.168.1.202一样

9.尝试上传数据，获取数据，客户端读取数据

上传数据，在任何一个节点上传都可以

获取数据

客户端查看数据

我们可以通过任何一个节点查看到数据

要想nginx能够实现对后端trucker的反向代理，必须结合第三方模块来实现

1.编译安装nginx

2.准备启动脚本

3.nginx与mofilefs互联

查看效果

5.配置后端truckers的集群

查看效果

大功告成了，后续思路，前段的nginx和数据库都存在单点故障，可以实现高可用集群