分布式服务架构方案.docx

1、高并发分布式服务架构方案下图是一个非常全面的架构蓝图，针对不同的应用系统需要的模块各有不同。此架构方案主要包括以下几个方面的设计：数据存储和读取，基础服务，应用层（APP/业务/Proxy） ，日志监控等，下面对这些主要的问题提供具体的各项针对性技术方案。 数据的存储和读取分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性，采用不同的数据存储和读取方案，主要有以下几种可选方案：1) 内存型数据库。内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格，适合进行海量数据的存储和读取。例如开源 nosql 数据库 mongodb、redis 等。2) 关系型数据库。关系型

2、数据库在满足并发性能的同时，也需要满足事务性，可通过读写分离，分库分表来应对高并发大数据量的情况。例如 Oracle，Mysql 等。3) 分布式数据库。 对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案，但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库 HBase 有一套完善的解决方案，适用于高并发海量数据存取的要求。基础服务基

3、础服务主要是指数据层之上的数据路由，Cache，搜索等服务。1) 路由 Router。对于数据库切分方案中的分库分表问题，需要解决在请求对应的数据时定位需要访问的位置，可根据一致性 Hash，维护路由表至内存数据库等方案解决。2) Cache。对于高并发的系统来讲，使用 Cache 可以减轻对后端系统的压力，所有 Cache可承担大部分热数据的读操作。当前用的比较多的是 redis 和 memcache，redis 比memcache 有丰富的数据操作的 API，redis 对数据进行了持久化，而 memcache 没有这个功能，因此 memcache 更加适合在关系型数据库之上的数据的缓存。

4、3) 搜索。搜索可以支持应用系统的按照关键词的检索，搜索提示，搜索排序等功能。开源开源的企业级搜索引擎主要有 lucene, sphinx，选择搜索引擎主要考虑以下三个方面：a) 搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高可用性b) 索引的实时性c) 搜索引擎的性能Solr 是基于 Lucene 开发的高性能的全文搜索服务器，满足以上三个方面的考虑，而且目前在企业中应用非常广泛。应用层应用层主要包括面向用户的应用，网站、APP 等，还包括相关的业务处理的运算等。1) 负载均衡-反向代理。一个大型的平台包括很多个业务域，不同的业务域有不同的集群，可以用 DNS 做域

5、名解析的分发或轮询，DNS 方式实现简单。但是因存在 cache 而缺乏灵活性；一般基于商用的硬件 F5、NetScaler 或者开源的软负载 lvs 在做分发，当然会采用做冗余(比如 lvs+keepalived)的考虑，采取主备方式。Nginx 是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件，可用作反向代理的工具。2) 应用服务器部署。应用层运行在 jboss 或者 tomcat 容器中，代表独立的系统，如网站系统，基础服务 Solr 等。可以采用 servlet3.0,异步化 servlet,提高整个系统的吞吐量。http 请求经过 Nginx，通过负载

6、均衡算法分到到 App 的某一节点，当并发量变大时，可以很方便地通过增加应用服务器进行扩展。有些反向代理或者负载均衡不支持对 session sticky 支持不是很好或者对接入的可用性要求比较高(app 接入节点宕机，session 随之丢失)，这就需要考虑 session 的集中式存储，使得 App 接入层无状态化，同时系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的。3) 业务服务。业务层对外协议以 NIO 的 RPC 方式暴露，可以采用比较成熟的 NIO 通讯框架，如 netty、mina。为了提高模块服务的可用性，一个模块部署在多个节点做冗余，并自动进行负载转发和

7、失效转移。对于分布式系统的一致性，尽量满足可用性，一致性可以通过校对来达到最终一致的状态。4) HA（高可用性） 。传统实现 HA 的做法一般是采用虚拟 IP 漂移，结合Heartbeat、keepalived 等实现 HA。在分布式的集群中，可以用 zookeeper 做分布式的协调，实现集群的列表维护和失效通知，客户端可以选择 hash 算法或者 roudrobin实现负载均衡；对于 master-master 模式、master-slave 模式，可以通过 zookeeper分布式锁的机制来支持。日志监控等其他组件1) 日志系统。应用系统在运行时会产生大量的日志，这些日志需要收集到分布式

8、存储系统中存储起来，以便于集中式的查询和分析处理。日志系统需具备三个基本组件，分别为 agent（封装数据源，将数据源中的数据发送给 collector） ，collector（接收多个 agent 的数据，并进行汇总后导入后端的 store 中） ，store（中央存储系统，应该具有可扩展性和可靠性，应该支持当前非常流行的 HDFS） 。开源的日志收集系统业界使用的比较多的是 cloudera 的 Flume 和 facebook 的 Scribe，其中 Flume 目前的版本FlumeNG 对 Flume 从架构上做了较大的改动。2) 监控统计。大型分布式系统涉及各种设备，比如网络交换机，普通 PC 机，各种型号的网卡，硬盘，内存等等，还有应用业务层次的监控，数量非常多的时候，出现错误的概率也会变大，并且有些监控的时效性要求比较高，有些达到秒级别；在大量的数据流中需要过滤异常的数据，有时候也对数据会进行上下文相关的复杂计算，进而决定是否需要告警。因此监控平台的性能、吞吐量、已经可用性就比较重要，需要规划统一的一体化的监控平台对系统进行各个层次的监控。监控的 web 应用可以把监控的实时结果推送到浏览器中，也可以提供 API 供结果的展现和搜索。监控架构示意如下图所示：