Java Web系统架构概览

大型网站系统架构的演进都是随着业务增加不断演进，全部的出发点都是为了知足业务需求。最初访问量下，功能简单时，单体软件能够解决全部问题；后来访问量逐渐增大，功能越发丰富，此时单体软件的架构逐渐成为开发和运维的瓶颈。因此微服务拆分，集群化部署，消息中间件，内存数据库，数据库中间件等解决方案逐渐走进视野。

下图为简略版的Web系统架构，本文围绕此图展开，简要介绍其中涉及组件的功能和应用场景。

 

回到最初，Web项目的源头几乎全来源于用户的请求(此处忽略运维相关的定时监控等任务)，当海量的请求并发量超过Tomcat服务器的峰值时，Tomcat的集群化应运而生，与之同时反向代理组件Ngnix走进视野。Ngnix自己做为入口，其稳定性是关键因素，因此利用keepalived实现高可用是正常思惟。

综上，能够看到集群化的目的在于解决单服务能力不足的问题，高可用的机器备份方案是为了实现系统的稳定运行。可是，在集群化时又引入了负载均衡，高可用时怎样实现异常故障自动切换等技术问题，这里均不深刻讨论，仅引入一个概念基础。另，每一种组件有不少相关的产品，这里仅针对图中列出的组件进行介绍。

 

拆分后的微服务部署在不一样的机器上，服务间如何通讯实现业务调用？先解释一个概念，调用有同步和异步两种，同步是在调用时发起方会阻塞线程等待调用结果返回后再往下执行，异步调用是调用方按约定将消息发送出去，不关注调用的执行结果，二者适用的场景不一样。对应到上图中同步调用的方案为Dubbox，消息中间件ActiveMQ为异步调用。

 

• Dubbox

Dubbox 是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，Dubbox 就是个服务框架，只有在分布式的时候，才有Dubbox 这样的分布式服务框架的需求，起本质上是个远程服务调用的分布式框架。

节点角色说明：

· Provider: 暴露服务的服务提供方。

· Consumer: 调用远程服务的服务消费方。

· Registry: 服务注册与发现的注册中心。

· Monitor: 统计服务的调用次调和调用时间的监控中心。

· Container: 服务运行容器。

调用关系说明：

1. 服务容器负责启动，加载，运行服务提供者。

2. 服务提供者在启动时，向注册中心注册本身提供的服务。

3. 服务消费者在启动时，向注册中心订阅本身所需的服务。

4. 注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者。

5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，再选另外一台调用。

6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

 

Dubbox推荐使用 zookeeper 注册中心。注册中心负责服务地址的注册与查找，至关于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。因此在服务集成时须要同步部署Zookeeper。

 

• ActiveMQ

消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通讯来进行分布式系统的集成。经过提供消息传递和消息排队模型，它能够在分布式环境下扩展进程间的通讯。对于消息中间件，常见的角色为Producer(生产者)、Consumer(消费者)。

ActiveMQ 是Apache的开源项目，是能力强劲的消息总线。ActiveMQ 是一个彻底支持JMS1.1和J2EE 1.4规范的JMS Provider实现。

    什么是JMS？

JMS（Java Messaging Service）是Java平台上有关面向消息中间件的技术规范，它便于消息系统中的Java应用程序进行消息交换,而且经过提供标准的产生、发送、接收消息的接口简化企业应用的开发。

JMS自己只定义了一系列的接口规范，是一种与厂商无关的 API，用来访问消息收发系统。它相似于 JDBC(java Database Connectivity)：这里，JDBC 是能够用来访问许多不一样关系数据库的 API，而 JMS 则提供一样与厂商无关的访问方法，以访问消息收发服务。许多厂商目前都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，这只是几个例子。 JMS 使您可以经过消息收发服务（有时称为消息中介程序或路由器）从一个 JMS 客户机向另外一个 JML 客户机发送消息。消息是 JMS 中的一种类型对象，由两部分组成：报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。

JMS规定的消息类型有两种：点对点(一对一)，发布/订阅模式(一对多)，咱们在使用消息中间件时只需听从JMS提供的操做接口进行开发。

 

ActiveMQ集群化有两种方式Master/Slave(ActiveMQ5.10开始支持使用Zookeeper搭建集群)，Broker Cluster。

• Master/Slave实现了主从复制，实现高可用；

• Broker Cluster实现了负载均衡。

能够将两种方式结合起来同时实现负载均衡和高可用。

 

为了进一步缓解服务集群的压力，能够将高频访问量大或者资源消耗严重的服务单独拆分出来，如图中的搜索和文件服务。

• SolrCloud

SolrCloud是Solr提供的分布式搜索方案，当你须要大规模，容错，分布式索引和检索能力时使用SolrCloud。当一个系统的索引数据量少的时候是不须要使用SolrCloud的，当索引量很大，搜索请求并发很高，这时须要使用SolrCloud 来知足这些需求。

SolrCloud 是基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用 Zookeeper做为集群的配置信息中心。

它有几个特点功能：

1）集中式的配置信息

2）自动容错

3）近实时搜索

4）查询时自动负载均衡

 

问题来了，何为Solr?

Apache Solr是一个流行的开源搜索服务器，它经过使用相似REST的HTTP API，构建搜索应用程序。它创建在Lucene(全文搜索引擎)之上。 Solr是企业级的，快速的和高度可扩展的。 使用Solr构建的应用程序很是复杂，可提供高性能。

Solr能够和Hadoop一块儿使用。因为Hadoop处理大量数据，Solr帮助咱们从大的源中找到所需的信息。不只限于搜索，Solr也能够用于存储目的。像其余NoSQL数据库同样，它是一种非关系数据存储和处理技术。

 

使用Solr时须要整合中文分析器，例如IK Analyzer。

IK Analyzer 是一个开源的，基亍 java 语言开发的轻量级的中文分词工具包。IK已发展为面向 Java 的公用分词组件，独立亍 Lucene 项目，同时提供了对 Lucene 的默认优化实现。在2012版本中，IK 实现了简单的分词歧义排除算法，标志着 IK 分词器从单纯的词典分词向模拟语义分词衍化。

 

Solr如何使用？

咱们能够利用Spring将Solr服务集成到项目中。Spring Data Sol就是为了方便Solr的开发所研制的一个框架，其底层是对SolrJ（官方API）的封装。搜索服务的功能开发参考Spring Data Solr相关接口。

 

• FastDFS

FastDFS 是用 c 语言编写的一款开源的分布式文件系统。FastDFS 为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用 FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

FastDFS 架构包括 Tracker server 和 Storage server。客户端请求 Tracker server 进行文件上传、下载，经过 Tracker server 调度最终由 Storage server 完成文件上传和下载。

Tracker server 做用是负载均衡和调度，经过 Tracker server 在文件上传时能够根据一些策略找到 Storage server 提供文件上传服务。能够将 tracker 称为追踪服务器或调度服务器。

Storage server 做用是文件存储，客户端上传的文件最终存储在 Storage 服务器上，Storage server 没有实现本身的文件系统而是利用操做系统 的文件系统来管理文件。能够将Storage称为存储服务器。

服务端两个角色：

Tracker：管理集群，tracker 也能够实现集群。每一个 tracker 节点地位平等。收集 Storage 集群的状态。

Storage：实际保存文件   Storage 分为多个组，每一个组之间保存的文件是不一样的。每一个组内部能够有多个成员，组成员内部保存的内容是同样的，组成员的地位是一致的，没有主从的概念。

 

由上图可知，FastDFS集群搭建完成后，咱们须要开发client端向服务器发起请求实现文件上传下载功能，相关开发接口在client的jar包中提供如：fastdfs_client_v1.20.jar。

 

最后，说说数据库在大型软件系统中的改变。

• Redis Cluster

为什么要搭建Redis集群。Redis是在内存中以Key-Value格式保存数据的，而电脑内存通常都不大，这也就意味着Redis不适合存储大数据，Redis更适合处理高并发。为了扩展设备的存储能力，搭建服务集群是正常思路。

Redis 3.0以后版本支持Redis-Cluster集群，它是Redis官方提出的解决方案，Redis-Cluster采用无中心结构，每一个节点保存数据和整个集群状态,每一个节点都和其余全部节点链接。其架构图以下：

客户端与 Redis 节点直连,不须要中间代理层。客户端不须要链接集群全部节点链接集群中任何一个可用节点便可。全部的 Redis 节点彼此互联(PING-PONG 机制)，内部使用二进制协议优化传输速度和带宽。

 

Redis-Cluster分布存储机制-槽

（1）Redis-Cluster 把全部的物理节点映射到[0-16383] slot上，cluster 负责维护node<->slot<->value。

（2）Redis-Cluster中内置了 16384 个哈希槽，当须要在 Redis 集群中放置一个 key-value 时，Redis 先对 key 使用 crc16 算法算出一个结果，而后把结果对 16384 求余数，这样每一个key 都会对应一个编号在 0-16383 之间的哈希槽，Redis 会根据节点数量大体均等的将哈希槽映射到不一样的节点。

Redis-Cluster容错机制-投票

（1）选举过程是集群中全部master参与,若是半数以上master节点与故障节点通讯超过(cluster-node-timeout),认为该节点故障，自动触发故障转移操做。故障节点对应的从节点自动升级为主节点。

（2）何时整个集群不可用(cluster_state:fail)?

若是集群任意master挂掉，且当前master没有slave。集群进入fail状态，也能够理解成集群的slot映射[0-16383]不完成时进入fail状态.。

 

为什么要使用Redis？

高频高并发的访问数据库会给数据库形成很大的访问压力，甚至是瘫痪。为了解决此问题，咱们可使用Redis将经常使用数据进行缓存，分流访问流量。

 

如何使用Redis？

相似Solr，Spring提供了Spring Data Redis框架，在Srping应用中经过简单的配置访问Redis服务。Spring Data Redis对Reids底层开发包(Jedis,  JRedis, and RJC)进行了高度封装，RedisTemplate提供了Redis各类操做、异常处理及序列化，支持发布订阅，并对Spring 3.1 cache进行了实现。

 

Spring Data Redis针对JRedis提供了以下功能：
1.链接池自动管理，提供了一个高度封装的“RedisTemplate”类。
2.针对jedis客户端中大量api进行了归类封装,将同一类型操做封装为operation接口。
ValueOperations：简单K-V操做
SetOperations：set类型数据操做
ZSetOperations：zset类型数据操做
HashOperations：针对map类型的数据操做
ListOperations：针对list类型的数据操做

 

• MyCat

MyCat是基于cobar(阿里开源产品)演变而来，对 cobar 的代码进行了完全的重构，使用 NIO 重构了网络模块，而且优化了 Buffer 内核，加强了聚合，Join 等基本特性，同时兼容绝大多数数据库成为通用的数据库中间件。

简单的说，MyCat就是：一个新颖的数据库中间件产品支持MySQL集群，或者mariadb cluster，提供高可用性数据分片集群。你能够像使用MySQL同样使用MyCat。对于开发人员来讲根本感受不到MyCat的存在。

MyCat分片

分片是指经过某种特定的条件，将咱们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面，以达到分散单台设备负载的效果。

数据的切分(Sharding)根据其切分规则的类型，能够分为两种切分模式。

   （1）一种是按照不一样的表(或者Schema)来切分到不一样的数据库(主机)之上，这种切分能够称之为数据的垂直(纵向)切分。

（2）另一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库(主机)上面，这种切分称之为数据的水平(横向)切分。

MyCat分片策略：

 

数据库的读写分离：

数据库读写分离对于大型系统或者访问量很高的互联网应用来讲，是必不可少的一个重要功能。对于MySQL来讲，标准的读写分离是主从模式，一个写节点Master后面跟着多个读节点，读节点的数量取决于系统的压力，一般是1-3个读节点的配置。

MyCat读写分离和自动切换机制，须要MySQL的主从复制机制配合。