论当前一种先进实用的IT系统架构设计修改版Word格式文档下载.docx
《论当前一种先进实用的IT系统架构设计修改版Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《论当前一种先进实用的IT系统架构设计修改版Word格式文档下载.docx（15页珍藏版）》请在冰豆网上搜索。
5G以上。
2.2运行环境要求：
硬件环境:
服务器端:
推荐配置为16G内存以上,CPU为2.8GHZ以上配置,硬盘容量为500G以上的服务器。
通信网络:
网络协议为HTTP、TCP/IP。
软件环境:
Ø
数据库服务器:
mysql5.6。
Web服务器：
tomcat7
服务器采用华硕服务器。
服务器操作系统：
linuxcentos6.5.
浏览器：
InternetExplore8.0、firefox17，360浏览器6及以上版本。
san存储,32T，RAID5，用于存储数据。
屏幕分辨率推荐为：
1024*768或以上。
2.3服务器架构平台：
1）Lvs+keepalived-1.2.8，2台集群做互联网访问的入口,或用array做入口，对HAPROXY进行负载均衡，中小型网站不需要这一层。
2）HAPROXY1.4+keepalived-1.2.8+Squid对squid服务器进行负载均衡，haproxy通过主备工作，万一主haproxy有故障，可以自动切换到备用机，提高可用性。
3）
squid+tomcat缓存集群进行负载均衡，Squid对tomcat服务器进行静态页面缓存，应用服务器主要提供静态资源，也可提供动态页面，但不缓存。
4）
Tomcat7服务器进行5台集群。
5）mysql数据库用2主多从，用haproxy对从数据库进行负载均衡。
大型项目可用oraclerac集群。
6）用3台redis3集群进行数据缓存。
7）用3台mongodb2.8集群存储图片、文档、视频、音乐等文件。
8）用1台solr5做搜索服务器。
9）用4台rocketMQ3集群传递消息，提供消息总线，确保消息不会丢失,可以简化为2台。
10）用1台ngios3.5监控服务器,发生异常时可发邮件和短信。
11）系统采用队列异步处理峰值高的请求，可以有效地处理高并发情况。
对于秒杀、摇红包等高并发情况，用有损服务、保证关键任务的思路，可以分步奏处理请求，先简单分析处理，然后把请求放入队列，异步完成队列的任务。
对请求数进行判断，如果超过峰值就拒绝请求，防止服务器崩溃。
应用功能加以分解并模块化，保证请求的完成，互相不影响。
腾讯就是用的这个办法削峰完成摇红包的每秒千万次访问的。
这个架构先进实用，实现了分布式集群，消除了数据库I/O瓶颈，大大提升了性能，而且支持服务器线性扩展，具有极强的伸缩性，适当扩展可以支持7X24每天数百万至数千万的访问量。
具体配置可以根据需要灵活处理。
在开发程序时要考虑分布式特点。
采用淘宝的dubbo可以实现服务的分布式，把具体的服务放在不同的服务器集群上，为web服务器提供服务，效率高，实用性极强。
2.4.架构逻辑设计
2.4.1KEEPLIVED+HAPROXY+squid集群
用LVS+KEEPLIVED双机通过一个VIP（vitual
IP）对haproxy+keeplived双机进行负载均衡，haproxy对应用服务器集群进行负载均衡调度。
请求首先在squid中查询，如果有数据，则返回页面，如果没有，则交给squid从tomcat中查询，并在squid中缓存页面。
可以对不同的应用系统采用多个集群，根据需要灵活处理。
LVS+KEEPLIVED对中小型系统不需要，对大型系统适合，相比于硬件负载均衡，性价比更高。
2.4.2squid+tomcat集群
Squid对tomcat服务器集群进行负载均衡调度，Squid缓存服务器对应用服务器的静态页面进行缓存，对动态页面没有意义，如果squid中没有缓存页面，则访问tomcat。
Haproxy用urlhash把应用服务器和squid缓存服务器对应起来。
2.4.3mysql集群
MySQL支持双主的设置，即两个MySQL节点互为主备，逻辑上仍按照主从的方式工作。
这样做之后，在出现故障后切换主备会变的很简单。
双主在设置时，只需将MySQL节点的配置文件复制一份，分别写入两个主数据库，但要修改相应的server-id，auto-increment-offset和master-host。
修改auto-increment-offset就是为了让双主同时在一张表中进行添加操作时不会出现id冲突，所以在两个节点上auto-increment-offset设置为不同的值就好。
在两个节点上都为对方创建用户。
Mysql用2主多从，提供高性能服务，主数据库提供对数据库的写操作，从数据库进行读操作，实现了读写分离和数据库备份。
从数据库可线性扩展。
用haproxy+keeplived双机对slave数据库进行负载均衡，提供对数据库的读操作。
程序建立读写两个datasource，通过VIPwrite进行写操作，通过VIPread进行读操作。
2.4.4mongodb图片服务器集群
mongodb集群保存图片、视频、文档、音乐等文件，可动态线性扩展，速度快，安全稳定，操作方便，可以存放海量数据，能承受高并发，可以使用廉价存储，服务器稳定性可以满足要求。
2.4.5RocketMQ服务器集群
通过RocketMQ方式建立消息集群，提供消息总线，支持负载均衡，同时又保证消息的可靠性。
采用消息集群可以在系统之间或系统内进行消息传递，实现分布式异步通讯。
采用pull方式更高效稳定。
2.4.6redis集群
Redis缓存基于内存，非常高效快速，还可保持到数据库，不会丢失。
在Redis集群版本中，节点有责任/义务保存数据和自身状态，这其中包括把数据（key）映射到正确的节点。
所有节点都应该自动探测集群中的其他节点，并且在发现故障节点之后把故障节点的从节点更改为主节点
Redis的集群是一个全网状的，通过TCP，每一个节点都与其他每个节点连接。
在N个节点的集群中，每个节点有N-1个对外TCP连接，和N-1的传入连接。
这些TCP连接一直保持着，不需要的时候才创建。
2.4.7solr搜索服务器
在
Solr
中，用户通过向部署在servlet容器中的
Web应用程序发送HTTP请求来启动索引和搜索。
接受请求，确定要使用的适当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.2lvs解析
LVS集群采用IP负载均衡技术和基于内容请求分发技术。
调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。
为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。
3.3keeplived解析
Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。
Layer3,4&
7工作在IP/TCP协议栈的IP层，TCP层，及应用层。
3.4haproxy解析
HAProxy提供高可用性、负载均衡、动静分离以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。
HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。
HAProxy运行在当前的硬件上，完全可以支持数以千万计的并发连接。
并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上。
HAProxy实现了一种事件驱动,
单一进程模型，此模型支持非常大的并发连接数。
实践证明，Haproxy比nginx性能更好。
3.5mysql解析
MySQL被广泛地应用在Internet上的中小型网站中。
由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。
MariaDB是mysql原开发团队的杰作，google公司已转为使用MariaDB。
Mysql成熟实用，稳定可靠，已在业界得到广泛的使用，mysql的性能比postgre优异，通过实际测试，可以看到mysql比postgre更强。
淘宝就采用mysql集群，并对mysql的源码进行了修改。
Mysql提供主从复制功能，主从服务器设置的稳健性得以提升，如果主服务器发生故障，可以把本来作为备份的从服务器提升为新的主服务器。
在主从服务器上分开处理用户的请求，读的话，可以直接读取备机数据，可获得更短的响应时间。
用从服务器做数据备份而不会占用主服务器的系统资源。
采用haproxy对从数据库进行负载均衡，提供高性能的读操作。
实践证明，mysql-proxy,amoeba，master-master-manage、mysqlcluster的性能不稳定，不建议使用。
一些网站或别的项目，可以采用mongodb代替mysql，性能更高，更稳定，更方便。
3.6redis解析
Redis3集群实现一个高性能、线性可扩展的1000节点的集群。
Redis集群没有最重要或者说中心节点，这个版本最主要的一个目标是设计一个线性可伸缩的功能。
Redis集群没有任何的数据合并动作。
写，直接是与主节点通信，但同步到slave也有一个时间窗口。
在可用性方面，除了master以及所有slave失效，不然一直可用。
Redis集群为了数据的一致性可能牺牲部分允许单点故障的功能，所以当网络故障和节点发生故障时这个系统会尽力去保证数据的一致性和有效性。
（这里我们认为节点故障是网络故障的一种特殊情况）
为了解决单点故障的问题，我们同时需要masters和slaves。
即使主节点（master）和从节点（slave）在功能上是一致的，甚至说他们部署在同一台服务器上，从节点也仅用以替代故障的主节点。
实际上应该说如果对从节点没有read-after-write（写并立即读取数据以免在数据同步过程中无法获取数据）的需求，那么从节点仅接受只读操作。
已实现的子集
Redis集群实现单一key在非分布式版本的Redis中的所有功能。
对于复合操作比如求并集求交集之类则只实现在单个节点的操作。
增加了hashtags的概念，主要用来强制把某些multi-key分配在一个节点。
但是在resharding中，这些multi-key可能找不到。
Redis集群版本将不再像独立版本一样支持多数据库，在集群版本中只有database0，并且SELECT命令是不可用的。
客户端与服务端在Redis集群版中的约定
所有节点都应该自动探测集群中的其他节点，并且在发现故障节点之后把故障节点的从节点更改为主节点。
集群节点使用TCPbus和二进制协议进行互联并对任务进行分派。
各节点使用gossip协议发送pingpackets给集群其他节点以确定其他节点是否正常工作。
Clusterbus也可以用来在节点间执行PUB/SUB命令。
当发现集群节点无应答的时候则会使用redirectionserrors-MOVEDand-ASK命令并且会重定向至可用节点。
理论上客户端可随意向集群中任意节点发送请求并获得重定向，也就是说客户端实际上并不用关心集群的状态。
然而，客户端也可以缓存数据对应的节点这样可以免去服务端进行重定向的工作，这在一定程度上可以提高效率。
安全写
Redis
cluster节点之间通过异步复制，这样总会存在丢数据的窗口。
但是client在连接master多的分区和少的分区的窗口是不一样的。
cluster在连接master多的分区的时候，尽量保证不丢写操作。
除了下面两种情况：
1）当一个写到达master，master已经回复client，但是master还没来的及复制到slave就宕机了，那么这个写操作就会丢失。
直到其中一个slave被提拔为master。
2）另外一种理论上可能丢失写操作的情况如下，
一个master因为partition不可到达
其中一个slave获取master失败
一会儿后master可以重新到达
一个client没用更新路由表，还在向旧的master写
实际上，这是不太可能发生，因为节点无法到达其他大多数master故障切换，不再接收写操作需要足够的时间，并当分区固定后，一段时间内写操作仍然是拒绝的，让其他节点通知有关配置更改。
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的值通常都非常大，这是经常可以看到的，列表或数百万元素的sortedset。
另外，数据类型在语义上是复杂的。
转移和合并这些类型的值，可能需要的应用程序端逻辑实现。
3.7squid解析
Squid作为网页服务器的前置cache服务器，可以代理用户向web服务器请求数据并进行缓存，也可以用在局域网中，使局域网用户通过代理上网。
Squid主要设计用于在Linux一类系统运行。
Squid是一个缓存internet数据的一个软件，可缓存html页面和图片等，它接收用户的下载申请，并自动处理所下载的数据。
也就是说，当一个用户想要下载一个主页时，它向Squid发出一个申请，要Squid替它下载，然后Squid连接所申请网站并请求该主页，接着把该主页传给用户同时保留一个备份，当别的用户申请同样的页面时，Squid把保存的备份立即传给用户，使用户觉得速度相当快。
使用springdataredis访问redis简单高效。
3.8solr解析
Solr是一个基于Lucene的Java搜索引擎服务器。
提供了层面搜索、命中醒目显示并且支持多种输出格式（包括XML/XSLT和JSON格式）。
它易于安装和配置，而且附带了一个基于HTTP的管理界面。
Solr已经在众多大型的网站中使用，较为成熟和稳定。
包装并扩展了Lucene，所以Solr的基本上沿用了Lucene的相关术语。
更重要的是，Solr
创建的索引与Lucene搜索引擎库完全兼容。
通过对Solr
进行适当的配置，某些情况下可能需要进行编码，Solr
可以阅读和使用构建到其他Lucene应用程序中的索引。
此外，很多Lucene工具（如Nutch、Luke）也可以使用Solr
创建的索引。
Solr对外提供标准的http接口来实现对数据的索引的增加、删除、修改、查询。
默认配置返回Solr
的标准XML响应，也可以配置Solr
的备用响应格式。
用ApacheSolr搜索引擎构建RESTful基础存储服务,性能更好。
3.9Nagios解析
Nagios是一款广泛采用开源的免费网络监视工具，能有效监控Windows、Linux和Unix的主机状态，交换机路由器等网络设置，打印机等。
在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。
3.10RocketMQ解析
阿里巴巴的RocketMQ是一款分布式、队列模型的消息中间件，是目前最优秀的消息中间件，具有以下特点：
1、支持严格的消息顺序；
2、支持Topic与Queue两种模式；
3、亿级消息堆积能力；
4、比较友好的分布式特性；
5、同时支持Push与Pull方式消费消息；
3.11Mongodb解析
MongoDB是目前IT行业最流行的数据库之一，XX、腾讯、360、京东等大型互联网公司已经将MongoDB投入实际的生产环境。
MongoDB实现用副本集完成集群，主从复制，每台机器都可以是主机，也可以是副机，都可以成为leader，自动故障转移，但负载均衡不够好。
MongoDB的事务管理比较强大，用两阶段提交实现事务。
使用springdatamongodb访问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的文档模型非常灵活，可以利用其支持异构数据的特性让你从各个数据源集中到一个库里，然后在已有数据上提取更多的价值，这是它非常擅长的地方。
另外一个像物联网，也是比较常用，物联网应用的特征就是并发率比较高，而Mongo
升级会员 