IT系统架构设计

转载自http://blog.csdn.net/buddha17/article/details/35550895

             

             论当前一种先进实用的IT系统架构设计

                                                                 李万鸿                                                                             

       

0 引言

对 用JAVA开发的项目来说，根据“成熟稳定、先进科学、实用可靠“的原则，设计使用这样一种架构，采用多个分布式集群来保证系统的高性能、高可靠性、伸缩 性、可维护性和安全的需要，服务器可以线性扩展，使用开源免费软件和廉价服务器，提供极高的性价比。这个架构对java及其他语言如PHP、c#等开发的 各类网站具有指导意义。

1系统架构图

 

 

 

系统应用架构采用门户、应用系统、业务逻辑和基础资源4层。服务器架构通过7个集群和4个负载均衡完成项目的功能。

2架构设计

2.1项目开发环境

1.  开发语言、工具：JAVA 、eclipse。

2.  技术架构采用jquery+SPRING3+mybatis。

3.  采用测试工具进行严格测试，保证代码质量，如：junit、QTP、qc、ROBERT、LOADRUNNER等。

4.  软件环境：maven、SVN（git）、tomcat，JDK7。

5.  硬件环境：cpu：P3 3GHZ以上　Memory：5G以上。

2.2运行环境要求：

硬件环境:

服务器端: 推荐配置为16G内存以上,CPU为2.8GHZ以上配置,硬盘容量为500G以上的服务器。

通信网络: 网络协议为HTTP、TCP/IP。

软件环境:

服务器端:

     数据库服务器:mysql5.6。

     Web服务器：tomcat7

     服务器采用华硕服务器。

     服务器操作系统： linux centos6.5.

     浏览器：Internet Explore8.0、firefox17，360浏览器6及以上版本。

     san存储,32T，RAID5，用于存储数据。

屏幕分辨率推荐为：1024*768或以上。

2.3服务器架构平台：

1） Lvs+keepalived-1.2.8，2台集群做互联网访问的入口,或用array做入口，对tengine进行负载均衡，中小型网站不需要这一层。

 2）tengine对tomcat、squid服务器进行负载均衡，tengine通过主备工作，万一主tengine有故障，可以自动切换到备用机，提高可用性。

3）squid缓存集群对图片进行缓存。

4） Tomcat服务器进行5台集群。

5） mysql数据库用2主多从，用haproxy对从数据库进行负载均衡。大型项目可用oracle rac 集群。

6） 用3台redis3集群，或memcached进行数据缓存。

7） 用3台mongodb2.8集群存储图片、文档、视频、音乐等文件。

8） 用1台solr5做搜索服务器。

9） 用4台rocketMq3集群传递消息，提供消息总线，确保消息不会丢失,可以简化为1-2台。

10）ngios3.5监控服务器,发生异常时可发邮件和短信。

11） 系统采用队列异步处理峰值高的请求，可以有效地处理高并发情况。对于秒杀、摇红包等高并发情况，用有损服务、保证关键任务的思路，可以分步奏处理请求，先 简单分析处理，然后把请求放入队列，异步完成队列的任务。对请求数进行判断，如果超过峰值就拒绝请求，防止服务器崩溃。应用功能加以分解并模块化，保证请 求的完成，互相不影响。腾讯就是用的这个办法削峰完成摇红包的每秒千万次访问的。

对 业务分析，分解、分割、分层，设计SOA架构。这个架构先进实用，实现了分布式集群，消除了数据库I/O瓶颈，大大提升了性能，而且支持服务器线性扩展， 具有极强的伸缩性，适当扩展可以支持7X24每天数百万至数千万的访问量。具体配置可以根据需要灵活处理。在开发程序时要考虑分布式特点。采用淘宝的 dubbo可以实现服务的分布式，把具体的服务放在不同的服务器集群上，为web服务器提供服务，效率高，实用性极强。

12)可采用restful完成soa设计，还支持openapi。

2.4.架构逻辑设计

2.4.1 KEEPLIVED+tengine集群

用LVS+KEEPLIVED双机通过一个VIP（vitual  IP）对tengine+keeplived双机进行负载均衡，tengine对tomcat、squid集群进行负载均衡调度，tengine可以缓存页面，失效期可以指定，比如1天，还可以通过命令清除缓存页面。可以对不同的应用系统采用多个集群，根据需要灵活处理。LVS对中小型系统不需要，对大型系统适合，相比于硬件负载均衡，性价比更高。

2.4.2squid集群

squid集群缓存页面的图片等资源， squid层可以根据实际需要决定是否采用。图片存储在FastDFS，用户请求通过tengine传到tomcat，tomcat响应请求生成页面，把页面中的图片请求发到squid，squid把图片请求发送到FastDFS从而得到图片，如果是第一次图片请求，就加入到squid缓存再返回图片，如果已经缓存则直接把缓存中的图片返回tengine，tengine再把图片返回给tomcat，tomcat把图片放入页面然后返回给tengine，tengine再把结果页面返回用户。

 2.4.3 mysql集群

MySQL支持双主的设置，即两个MySQL节点互为主备，逻辑上仍按照主从的方式工作。这样做之后，在出现故障后切换主备会变的很简单。

  双主在设置时，只需将MySQL节点的配置文件复制一份，分别写入两个主数据库，但要修改相应的server-id，auto-increment- offset和master-host。修改auto-increment-offset就是为了让双主同时在一张表中进行添加操作时不会出现id冲突， 所以在两个节点上auto-increment-offset设置为不同的值就好。 在两个节点上都为对方创建用户。

Mysql用2主多从，提供高性能服务，主数据库提供对数据库的写操作，从数据库进行读操作，实现了读写分离和数据库备份。从数据库可线性扩展。

  用haproxy+keeplived双机对slave数据库进行负载均衡，提供对数据库的读操作。程序建立读写两个datasource，通过VIPread进行读操作。

2.44 mongodb图片服务器集群

 fastDFS或mongodb集群保存图片、视频、文档、音乐等文件，可动态线性扩展，速度快，安全稳定，操作方便，可以存放海量数据，能承受高并发，可以使用廉价存储，服务器稳定性可以满足要求。

2.4.5RocketMQ服务器集群

 

通过RocketMQ方式建立消息集群，提供消息总线，支持负载均衡，同时又保证消息的可靠性。采用消息集群可以在系统之间或系统内进行消息传递，实现分布式异步通讯。采用pull方式更高效稳定。

2.4.6 redis集群

 在Redis集群版本中，节点有责任/义务保存数据和自身状态，这其中包括把数据（key）映射到正确的节点。所有节点都应该自动探测集群中的其他节点，并且在发现故障节点之后把故障节点的从节点更改为主节点 Redis的集群是一个全网状的，通过TCP，每一个节点都与其他每个节点连接。在N个节点的集群中，每个节点有N-1个对外TCP连接，和N-1的传入连接。这些TCP连接一直保持着，不需要的时候才创建。

 

2.4.7solr搜索服务器

在 Solr 中，用户通过向部署在servlet容器中的 Solr Web应用程序发送 HTTP 请求来启动索引和搜索。Solr 接受请求，确定要使用的适当SolrRequestHandler，然后处理请求。通过 HTTP 以同样的方式返回响应。

3架构剖析

3.1负载均衡器解析

负载均衡器（调度器）是一种采用各种分配算法把网络请求分散到一个服务器集群中的可用服务器上去，通过管理进入的Web数据流量和增加有效的网络带宽，从而使网络访问者获得尽可能最佳的联网体验的硬件设备。

1、负载均衡器的工作层次：

1）工作于tcp/udp层实现底层协议的负载均衡,请求在内核中实现转发；

2）工作于应用层，支持特定的应用协议实现应用层的负载均衡，请求在用户空间中。

工作于tcp/udp层的性能要比工作于应用层的负载均衡器的好得多，若请求数量没超过应用层负载均衡器的容量，应使用应用层的负载均衡器，它能直接于前端更好的解决请求。

2、http/https协议层的负载均衡器

1）tcp/udp层：lvs，haproxy

2) 应用层：apache,nginx,haproxy,lighttpd,varnish,squid

3.2 lvs解析

LVS 集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从 而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考 虑系统的透明性、可伸缩性、高可用性和易管理性。

3.3 keeplived解析

Keepalived 的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除， 当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的 web服务器。Layer3,4&7工作在IP/TCP协议栈的IP层，TCP层，及应用层。

3.4 haproxy解析

HAProxy 提供高可用性、负载均衡、动静分离以及基于TCP和HTTP应用的代 理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。 HAProxy运行在当前的硬件上，完全可以支持数以千万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的 web服务器不被暴露到网络上。

HAProxy实现了一种事件驱动, 单一进程模型，此模型支持非常大的并发连接数。实践证明，Haproxy比nginx性能更好。

3.5 mysql解析

MySQL 被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有 成本而选择了MySQL作为网站数据库。MariaDB是mysql原开发团队的杰作，google公司已转为使用MariaDB。

Mysql成熟实用，稳定可靠，已在业界得到广泛的使用，mysql的性能比postgre优异，通过实际测试，可以看到mysql比postgre更强。淘宝就采用mysql集群，并对mysql的源码进行了修改。

Mysql 提供主从复制功能，主从服务器设置的稳健性得以提升，如果主服务器发生故障，可以把本来作为备份的从服务器提升为新的主服务器。在主从服务器上分开处理用 户的请求，读的话，可以直接读取备机数据，可获得更短的响应时间。用从服务器做数据备份而不会占用主服务器的系统资源。采用haproxy对从数据库进行 负载均衡，提供高性能的读操作。实践证明，mysql-proxy,amoeba，master-master-manage、mysql cluster的性能不稳定，不建议使用。

3.6 redis解析

redis集群实现一个高性能、线性可扩展的1000节点的集群。

Redis集群没有最重要或者说中心节点，这个版本最主要的一个目标是设计一个线性可伸缩的功能。

Redis集群没有任何的数据合并动作。写，直接是与主节点通信，但同步到slave也有一个时间窗口。在可用性方面，除了master以及所有slave失效，不然一直可用。

Redis集群为了数据的一致性可能牺牲部分允许单点故障的功能，所以当网络故障和节点发生故障时这个系统会尽力去保证数据的一致性和有效性。（这里我们认为节点故障是网络故障的一种特殊情况）

为了解决单点故障的问题，我们同时需要masters 和 slaves。 即使主节点(master)和从节点(slave)在功能上是一致的，甚至说他们部署在同一台服务器上，从节点也仅用以替代故障的主节点。 实际上应该说 如果对从节点没有read-after-write（写并立即读取数据 以免在数据同步过程中无法获取数据）的需求，那么从节点仅接受只读操作。

已实现的子集

Redis集群实现单一key在非分布式版本的Redis中的所有功能。对于复合操作比如求并集求交集之类则只实现在单个节点的操作。

增加了hash tags的概念，主要用来强制把某些multi-key分配在一个节点。但是在resharding中，这些multi-key可能找不到。

Redis集群版本将不再像独立版本一样支持多数据库，在集群版本中只有database 0，并且SELECT命令是不可用的。

客户端与服务端在Redis集群版中的约定

在Redis集群版本中，节点有责任/义务保存数据和自身状态，这其中包括把数据（key）映射到正确的节点。所有节点都应该自动探测集群中的其他节点，并且在发现故障节点之后把故障节点的从节点更改为主节点。

集群节点使用TCP bus和二进制协议进行互联并对任务进行分派。各节点使用gossip 协议发送ping packets给集群其他节点以确定其他节点是否正常工作。Cluster bus也可以用来在节点间执行PUB/SUB命令。

当 发现集群节点无应答的时候则会使用redirections errors -MOVED and -ASK命令并且会重定向至可用节点。理论上客户端可随意向集群中任意节点发送请求并获得重定向，也就是说客户端实际上并不用关心集群的状态。然而，客户 端也可以缓存数据对应的节点这样可以免去服务端进行重定向的工作，这在一定程度上可以提高效率。

安全写

Redis cluster节点之间通过异步复制，这样总会存在丢数据的窗口。但是client在连接master多的分区和少的分区的窗口是不一样的。

Redis cluster在连接master多的分区的时候，尽量保证不丢写操作。除了下面两种情况：

1）当一个写到达master，master已经回复client，但是master还没来的及复制到slave就宕机了，那么这个写操作就会丢失。直到其中一个slave被提拔为master。

2）另外一种理论上可能丢失写操作的情况如下，

一个master因为partition不可到达

其中一个slave获取master失败

一会儿后master可以重新到达

一个client没用更新路由表，还在向旧的master写

实际上，这是不太可能发生，因为节点无法到达其他大多数master故障切换，不再接收写操作需要足够的时间，并当分区固定后，一段时间内写操作仍然是拒绝的，让其他节点通知有关配置更改。

Redis cluster会丢失很多写操作，当一个或多个客户端连接到一个少master分区时。因为如果这些master不可以到达多master的分区，这些写操作就会丢失。

如果在NODE_TIMEOUT前不可到达，不会丢消息，如果在NODE_TIMEOUT后，会有消息丢失。（暂时不理解为啥不丢消息）。

可用性

少master分区是不开用的，假设多master分区至少有一个不开到达master的slave，那么在NODE_TIMEOUT后，slave就会被选举为相应的master。假设一个master有一个slave，那么可用性为1-(1/(2*n-1))。

性能

在Redis中不在通过代理命令来确定给定键的节点，而是它们将客户端重定向到服务密钥空间的给定部分的节点。

最终客户保存着集群和那个节点提供密钥的时间标识符，所以在正常操作期间，client直接联系合适的节点，以便发送给定的命令。

因为使用异步复制的，节点不等待写入的其他节点的确认。

此外，由于限制多个键执行操作命令的子集，如果不rsharding，数据从来不在节点之间移动。

所 以在单个Redis的实例下，正常操作处理可以完成的，在N个主节点Redis的集群，可以期望以单一的Redis实例相同的性能乘以N作为设计的线性扩 展。在同一时间，通常在单次往返执行查询，因为客户通常保持与节点持久连接，以便和单个独立的Redis节点延迟性也是一样的。

非常高的性能和弱（非CAP）的可扩展性，但合理的形式一致性和可用性是主要目标。

为什么避免合并操作

Redis 集群设计避免了版本冲突的相同键值在多个节点，因为在Redis的数据模型下，这并不总是可取的：在Redis的值通常都非常大，这是经常可以看到的，列 表或数百万元素的sorted set。另外，数据类型在语义上是复杂的。转移和合并这些类型的值，可能需要的应用程序端逻辑实现。使用spring data redis访问redis简单高效。

3.7 squid解析

Squid作为网页服务器的前置cache服务器，可以代理用户向web服务器请求数据并进行缓存，也可以用在局域网中，使局域网用户通过代理上网。Squid主要设计用于在Linux一类系统运行。

Squid 是一个缓存internet数据的一个软件，可缓存html页面和图片等，它接收用户的下载申请，并自动处理所下载的数据。也就是说，当一个用户想要下载 一个主页时，它向Squid发出一个申请，要Squid替它下载，然后Squid连接所申请网站并请求该主页，接着把该主页传给用户同时保留一个备份，当 别的用户申请同样的页面时，Squid把保存的备份立即传给用户，使用户觉得速度相当快。

3.8solr解析

Solr 是一个基于Lucene的Java搜索引擎服务器。Solr 提供了层面搜索、命中醒目显示并且支持多种输出格式（包括 XML/XSLT 和 JSON 格式）。它易于安装和配置，而且附带了一个基于 HTTP的管理界面。Solr已经在众多大型的网站中使用，较为成熟和稳定。Solr 包装并扩展了 Lucene，所以Solr的基本上沿用了Lucene的相关术语。更重要的是，Solr 创建的索引与Lucene搜索引擎库完全兼容。通过对 Solr 进行适当的配置，某些情况下可能需要进行编码，Solr 可以阅读和使用构建到其他Lucene应用程序中的索引。此外，很多Lucene工具 （如Nutch、 Luke）也可以使用Solr 创建的索引。Solr对外提供标准的http接口来实现对数据的索引的增加、删除、修改、查询。在 Solr 中，用户通 过向部署在servlet容器中的 Solr Web应用程序发送 HTTP 请求来启动索引和搜索。Solr 接受请求，确定要使用的适当SolrRequestHandler，然后处理请求。通过 HTTP以同样的方式返回响应。默认配置返回Solr 的标准 XML响应，也可以配置Solr 的备用响应格式。用Apache Solr搜索引擎构建 RESTful基础存储服务,性能更好。

 Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。

 

3.9Nagios解析

Nagios是一款广泛采用开源的免费网络监视工具，能有效监控Windows、Linux和Unix的主机状态，交换机路由器等网络设置，打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。zabbix也实用。

3.10RocketMQ解析

RocketMQ是一款分布式、队列模型的消息中间件，是目前最优秀的消息中间件，具有以下特点：

1、支持严格的消息顺序；

2、支持Topic与Queue两种模式；

3、亿级消息堆积能力；

4、比较友好的分布式特性；

5、同时支持Push与Pull方式消费消息；

3.11Mongodb解析

     MongoDB是目前IT行业最流行的数据库之一，百度、腾讯、360、京东等大型互联网公司已经将MongoDB投入实际的生产环境。MongoDB实现用副本集完成集群，主从复制，每台机器都可以是主机，也可以是副机，都可以成为leader，自动故障转移，但负载均衡不够好。MongoDB的事务管理比较强大，用两阶段提交实现事务。使用spring data mongodb访问MongoDB,简单高效。

MongoDB 数据库中操作单个文档总是原子性的，然而，涉及多个文档的操作，通常被作为一个“事务”，而不是原子性的。因为文档可以是相当复杂并且包含多个嵌套文档， 单文档的原子性对许多实际用例提供了支持。尽管单文档操作是原子性的，在某些情况下，需要多文档事务。在这些情况下，使用两阶段提交，提供这些类型的多文 档更新支持。因为文档可以表示为Pending数据和状态，可以使用一个两阶段提交确保数据是一致的，在一个错误的情况下，事务前的状态是可恢复的。

MongoDB是一个非常灵活的数据库。像mysql，sqlserver，oracle这些传统数据库，它们的模式非常固定，在开发之前设计好模式，一旦设计好模式以后修改很麻烦，这对敏捷式开发不是很方便。而MongoDB的模式非常灵活，它不要求你建模式，你的程序怎么样写都可以，所以它的灵活性是程序员很喜欢的。

MongoDB的文档模型。以前是关系模型，它跟文档模型最大的不同就是，关系模型要把所有东西分开到各个地方去放；而文档模型是把相关的东西放到一块，这样的话使用起来非常方便。

程序员是面向对象的思维方式，MongoDB是类似对象的结构，它是从对象到对象之间，没有思维转换，而不同于从对象到关系型转换，需要换一种思维去思考，比较复杂一点，这就是另外一点为什么程序员喜欢用MongoDB。

MongoDB用起来比较容易，接口非常方便，不像其他传统数据库要学习专门的SQL语言，MongoDB兼顾编程的接口。

MongoDB 与传统数据库的区别非常大的一点就是它的水平扩展性非常好。现在是大数据时代，大数据要求的性能非常高，因为它要求管理的数据量非常大。Mysql或其他 的关系型数据库一般是单机式的，也就是在一台机器上可以做的很好，但是一旦涉及到分布式内容，基本上没有很好的方案，而 MongoDB是一种分布式的数据库，它在设计的时候是分布在不同的机器上，同时并发进行，这样的话处理这个时代的大数据比较流行。

从 MongoDB的功能性、扩展性、高可用性上来讲，如果你需要这样的需求的话，MongoDB会非常适合，MongoDB分布式数据可以做的很好。 MongoDB地理空间能做的很好，目前移动应用非常流行，比如快的打车，他们就是以MongoDB作为核心技术，来找到附近几公里内的出租车司机，还有 其他一些手机应用，它会跟踪你的位置，需要知道你的位置，都可以用到MongoDB。

从 应用场景的角度来说的话，MongoDB还可以做分析型数据库，特别是需要把各种各样的数据源放到一起对已有数据做二次开发的时候，因为MongoDB的 文档模型非常灵活，可以利用其支持异构数据的特性让你从各个数据源集中到一个库里，然后在已有数据上提取更多的价值，这是它非常擅长的地方。

另外一个像物联网，也是比较常用，物联网应用的特征就是并发率比较高，而MongoDB通过水平扩展的集群可以实现几万到几十万OPS每秒的写入性能。

还有在内容管理方面，举个例子，MongoDB的文档模型可以存储各类数据，多媒体、有接口、无接口，他可以存各种结构的接口数据，所以对各种各样的内容、产品，比如新闻、视频、音频等，都非常方便。

产 品目录也是非常好的使用场景。比如京东就是用MongoDB，MongoDB文档模型非常灵活，它支持不同结构的数据，我们知道不同的产品它的属性有很大 的不同，在传统型数据库建模比较麻烦，像MongoDB的话，它可以把不一样结构的数据放到同一个集合，同一个表里面，由于它的这个特性，所以对电商的支 持也非常好。

3.12SOA解析

本架构对面向服务的体系架构（SOA）提供良好的支持，提供面向服务、松散耦合特性的架构服务，如采用dubbo、dubbox、restful等。

3.13大数据解析

本架构是一个分布式架构，可用于大数据计算，对hadoop、hbase、mongodb、spark的大数据的支持十分有力。

3.14 tengine解析

Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。Tengine已经被全球多个大型网站使用，成为最受欢迎的十大Web服务器软件之一，是ngnix的替代品。

功能特性介绍：

• 继承Nginx-1.6.2的所有特性，兼容Nginx的配置；

• 动态模块加载（DSO）支持。加入一个模块不再需要重新编译整个Tengine；

• 支持SO_REUSEPORT选项，建连性能提升为官方nginx的三倍；

• 支持SPDY v3协议，自动检测同一端口的SPDY请求和HTTP请求；

• 流式上传到HTTP后端服务器或FastCGI服务器，大量减少机器的I/O压力；

• 更加强大的负载均衡能力，包括一致性hash模块、会话保持模块，还可以对后端的服务器进行主动健康检查，根据服务器状态自动上线下线，以及动态解析upstream中出现的域名；

• 输入过滤器机制支持。通过使用这种机制Web应用防火墙的编写更为方便；

• 支持设置proxy、memcached、fastcgi、scgi、uwsgi在后端失败时的重试次数

• 动态脚本语言Lua支持。扩展功能非常高效简单；

• 支持管道（pipe）和syslog（本地和远端）形式的日志以及日志抽样；

• 支持按指定关键字(域名，url等)收集Tengine运行状态；

• 组合多个CSS、JavaScript文件的访问请求变成一个请求；

• 自动去除空白字符和注释从而减小页面的体积

• 自动根据CPU数目设置进程个数和绑定CPU亲缘性；

• 监控系统的负载和资源占用从而对系统进行保护；

• 显示对运维人员更友好的出错信息，便于定位出错机器；

• 更强大的防攻击（访问速度限制）模块；

• 更方便的命令行参数，如列出编译的模块列表、支持的指令等；

• 可以根据访问文件类型设置过期时间；

• ……

 3.15 FastDFS

   FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

FastDFS服务端有两个角色：跟踪器（tracker）和存储节点（storage）。跟踪器主要做调度工作，在访问上起负载均衡的作用。

存储节点存储文件，完成文件管理的所有功能：存储、同步和提 供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key valuepair）方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。

跟踪器和存储节点都可以由一台或多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。

为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。

在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。

当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。

FastDFS中的文件标识分为两个部分：卷名和文件名。

4.结束语

总之，这是一个先进实用的架构，采用了haproxy、Tengine、lvs、keeplived进行负载均衡，使用redis、squid进行缓存，使用mysql数据库主从方式，使用solr搜索，使用mongodb、fastDFS保持图片等，使用rocketMQ传递消息等技术，提供了HA、HP的服务性能，能满足大多数项目的实际需要，值得采纳。

本文借鉴了网上的文章和书籍，在此表示感谢，愿和大家一起在探索科学架构的征途上留下闪光的脚印！

参考文献：

【1】       李智慧大型网站技术架构核心原理与案例分析 2014

【2】       http://dev.mysql.com/doc/

【3】       中国SOA最佳应用及云计算融合实践  2012

【4】       耿渊、张卫滨 SPRING实战（第三版）2014

【5】       曾宪杰 大型网站系统与java中间件实践 2014 

本文转自 wdy198622 51CTO博客，原文链接:http://blog.51cto.com/weimouren/1747194