当前位置:文档之家› 分布式服务架构方案

分布式服务架构方案

高并发分布式服务架构方案
下图是一个非常全面的架构蓝图,针对不同的应用系统需要的模块各有不同。

此架构方案主要包括以下几个方面的设计:数据存储和读取,基础服务,应用层(APP/业务/Proxy),日志监控等,下面对这些主要的问题提供具体的各项针对性技术方案。

数据的存储和读取
分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性,采用不同的数据存储和读取方案,主要有以下几种可选方案:
1)内存型数据库。

内存型的数据库,以高并发高性能为目标,在事务性方面没那么严格,
适合进行海量数据的存储和读取。

例如开源nosql数据库mongodb、redis等。

2)关系型数据库。

关系型数据库在满足并发性能的同时,也需要满足事务性,可通过
读写分离,分库分表来应对高并发大数据量的情况。

例如Oracle,Mysql等。

3)分布式数据库。

对于数据的高并发的访问,传统的关系型数据库提供读写分离的方案,
但是带来的确实数据的一致性问题提供的数据切分的方案;对于越来越多的海量数据,传统的数据库采用的是分库分表,实现起来比较复杂,后期要不断的进行迁移维护;对
于高可用和伸缩方面,传统数据采用的是主备、主从、多主的方案,但是本身扩展性比较差,增加节点和宕机需要进行数据的迁移。

对于以上提出的这些问题,分布式数据库HBase有一套完善的解决方案,适用于高并发海量数据存取的要求。

基础服务
基础服务主要是指数据层之上的数据路由,Cache,搜索等服务。

1)路由Router。

对于数据库切分方案中的分库分表问题,需要解决在请求对应的数据时
定位需要访问的位置,可根据一致性Hash,维护路由表至内存数据库等方案解决。

2)Cache。

对于高并发的系统来讲,使用Cache可以减轻对后端系统的压力,所有Cache
可承担大部分热数据的读操作。

当前用的比较多的是redis和memcache,redis比memcache有丰富的数据操作的API,redis对数据进行了持久化,而memcache没有这个功能,因此memcache更加适合在关系型数据库之上的数据的缓存。

3)搜索。

搜索可以支持应用系统的按照关键词的检索,搜索提示,搜索排序等功能。

开源
开源的企业级搜索引擎主要有lucene, sphinx,选择搜索引擎主要考虑以下三个方面:
a)搜索引擎是否支持分布式的索引和搜索,来应对海量的数据,支持读写分离,提高
可用性
b)索引的实时性
c)搜索引擎的性能
Solr是基于Lucene开发的高性能的全文搜索服务器,满足以上三个方面的考虑,而且目前在企业中应用非常广泛。

应用层
应用层主要包括面向用户的应用,网站、APP等,还包括相关的业务处理的运算等。

1)负载均衡-反向代理。

一个大型的平台包括很多个业务域,不同的业务域有不同的集群,
可以用DNS做域名解析的分发或轮询,DNS方式实现简单。

但是因存在cache而缺乏灵活性;一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在做分发,当然会采用做冗余(比如lvs+keepalived)的考虑,采取主备方式。

Nginx是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件,可用作反向代理的工具。

2)应用服务器部署。

应用层运行在jboss或者tomcat容器中,代表独立的系统,如网站
系统,基础服务Solr等。

可以采用,异步化servlet,提高整个系统的吞吐量。

http请求经过Nginx,通过负载均衡算法分到到App的某一节点,当并发量变大时,可以很方便地通过增加应用服务器进行扩展。

有些反向代理或者负载均衡不支持对session sticky支持不是很好或者对接入的可用性要求比较高(app接入节点宕机,session随之丢失),这就需要考虑session的集中式存储,使得App接入层无状态化,同时系统用户变多的时候,就可以通过增加更多的应用节点来达到水平扩展的目的。

3)业务服务。

业务层对外协议以NIO的RPC方式暴露,可以采用比较成熟的NIO通讯框架,
如netty、mina。

为了提高模块服务的可用性,一个模块部署在多个节点做冗余,并自动进行负载转发和失效转移。

对于分布式系统的一致性,尽量满足可用性,一致性可以通过校对来达到最终一致的状态。

4)HA(高可用性)。

传统实现HA的做法一般是采用虚拟IP漂移,结合Heartbeat、
keepalived等实现HA。

在分布式的集群中,可以用zookeeper做分布式的协调,实现集群的列表维护和失效通知,客户端可以选择hash算法或者roudrobin实现负载均衡;
对于master-master模式、master-slave模式,可以通过zookeeper分布式锁的机制来支持。

日志监控等其他组件
1)日志系统。

应用系统在运行时会产生大量的日志,这些日志需要收集到分布式存储系统
中存储起来,以便于集中式的查询和分析处理。

日志系统需具备三个基本组件,分别为agent(封装数据源,将数据源中的数据发送给collector),collector(接收多个agent 的数据,并进行汇总后导入后端的store中),store(中央存储系统,应该具有可扩展性和可靠性,应该支持当前非常流行的HDFS)。

开源的日志收集系统业界使用的比较多的是cloudera的Flume和facebook的Scribe,其中Flume目前的版本FlumeNG对Flume 从架构上做了较大的改动。

2)监控统计。

大型分布式系统涉及各种设备,比如网络交换机,普通PC机,各种型号的
网卡,硬盘,内存等等,还有应用业务层次的监控,数量非常多的时候,出现错误的概率也会变大,并且有些监控的时效性要求比较高,有些达到秒级别;在大量的数据流中需要过滤异常的数据,有时候也对数据会进行上下文相关的复杂计算,进而决定是否需
要告警。

因此监控平台的性能、吞吐量、已经可用性就比较重要,需要规划统一的一体化的监控平台对系统进行各个层次的监控。

监控的web应用可以把监控的实时结果推送到浏览器中,也可以提供API供结果的展现和搜索。

监控架构示意如下图所示:。

相关主题