开题报告OncePortal 集群解决方案设计和实现.docx

研究生学位论文开题报告报告题目 OncePortal 集群解决方案设计和实现 学生姓名何丽学号 201328015029026 指导教师钟华职称研究员 学位类别工学硕士 学科专业计算机软件与理论 研究方向网络分布计算与软件工程 培养单位软件研究所 填表日期2013 年 6 月 15 日 研究生院制填 表 说 明1.本表内容须真实、完整、准确。2.“学位类别”名称填写：哲学博士、教育学博士、理学博士、工学博士、农学 博士、医学博士、管理学博士，哲学硕士、经济学硕士、法学硕士、教育学 硕士、文学硕士、理学硕士、工学硕士、农学硕士、医学硕士、管理学硕士 等。3.“学科专业”名称填写： “二级学科”全称。111选题的背景及意义OncePortal 是软件研究所开发的企业信息门户中间件。 OncePortal 可以在网络环境下，将各种企业现有应用系统、数据资源和互联网 资源集成到通用门户之下，为企业提供统一工作平台。各种终端用户可通过一个 单一的信息入口，个性化的访问企业的数据信息和后台系统，从而实现信息的有 效集成、发布和协作。随着用户数量和用户请求的增加，服务器端的负载越来越重，必然存在一个 临界点致使服务器已经无法处理众多的请求，导致响应延迟越来越高，服务器的 负载成为一个瓶颈，使系统的整体性能下降。而且，由于只有一台应用服务器在 工作，一旦服务器出现故障，整个系统便会崩溃。所以 OncePortal 的单服务器 模式已经不能满足高并发的海量用户的数据访问、数据处理等请求，必须依靠一 个新的解决方案来支持海量用户访问和高可用性的系统需求。搭建服务器集群来协同工作提供服务是解决上述问题的一种流行技术，通过 将负载分摊到多台服务器上来提供伸缩性和负载均衡，并应用不同的协同合作策 略来实现高可用性和容错性。现在有很多不同的方案用以将单机版本的 Web 应用 移植到集群环境中，但就 OncePortal 信息门户中间件系统这一 Web 应用而言， 在集群移植时，需要考虑以下几个问题：第一， 它是一个用 Java 编写的成熟的门户中间件平台，已经被应用在很多 企业中，任何对代码进行大量修改的移植方案都会存在一定的成本和风险；第二， OncePortal 中的关键业务操作是以一个 portlet 实体对象为单位进 行的，portlet 自身的一些组织结构会给集群化带来一些棘手的问题，我们要保 证集群化以后对 portlet 的业务操作也能正常运行；第三， OncePortal 拥有自己的本地缓存，出于性能的考虑应当在集群中保 留，因此如何解决 OncePortal 集群之间本地缓存的数据同步至关重要。基于以上这些问题，现有的集群解决方案目前没有办法完全直接地应用到 OncePortal 上，因此如何以对原始代码侵入最小的代价来构建集群解决方案， 对于保证系统的正常运行、运营维护等有重要意义。2 国内外本学科领域的发展现状与趋势2.1 集群技术现状分析 计算机集群技术的出发点是为了提供具有更高可用性、可管理性、可伸缩性的计算机系统，根据集群的具体使用场景和应用目的可以分为两大类：高性能集 群和高可用性集群。前者通过负载均衡、并行处理、时间片处理等多种形式，让 多台普通性能的计算机协同工作，提供强大的处理能力，承担只有超级计算机才 能胜任的任务。后者确保数据和应用程序对最终用户的高可用性，它将服务器备 份到镜像系统或冗余节点中，当集群中的主节点出现故障的时候，冗余节点就自 动接替主节点的工作，继续提供服务，从而保证了系统运行的不间断。2.1.1组织结构一般来说，集群采用三层结构，由负载调度器、服务器池、共享存储三个主 要部分组成（如图）。共享存储一般建立在数据库或者存储服务器的文件系统之上，这种集中式的 存储结构有两个弊端：第一，应用服务器的每一次数据处理请求，都必须和存储 服务器进行交互，于是负载都集中在存储服务器上，当数据请求数量到达一定规 模，存储服务器将会成为性能的瓶颈；第二，一旦存储服务器出现故障（单点失 效），那么集群的存储系统将全部失效，整个集群也随之崩溃。为了降低存储服务器的负载，可以在每个应用服务器上建立一个缓存。应用 服务器对数据进行处理请求时，优先在自己的缓存中查找和处理，当在缓存中找 不到时再将请求发送到存储服务器（如图）。于是便引入了缓存之间的数据同步 问题。2.1.2分布式存储分布式存储是分布式集群的重要组成部分。分布式存储是作为对传统数据库 系统的替代物而出现的。传统的软件系统中，主要负载集中在 SQL 的运行上，也 就是说，整个软件系统的性能关键点就集中在数据库上。随着用户的爆发式增长， 数据库越来越成为性能的瓶颈。与集中式存储技术不同，分布式存储技术并不是将数据存储在某个或多个特 定的节点上，而是通过网络使用企业中每台机器上的磁盘空间，并将这些分散的 存储资源构成一个虚拟的存储设备，数据分散地存储在企业的各个角落。2000 年，Eric Brewer 教授在 ACM 分布式计算年会上指出了著名的 CAP 理论， 即：一个分布式系统不可能同时满足一致性（ Consistency ），可用性 （Availability）和分区容错性（Partition Tolerance）这三个需求，最多只 能同时满足两个。2002 年 MIT 的 Seth Gilbert 和 Nancy Lynch 两人证明了 CAP 理论的正确性。根据 CAP 理论，一致性(C)，可用性(A)，分区容错性(P)，三者 不可兼得，必须有所取舍。对于分布式存储系统而言，分区容错性(P)是基本需求，因此只有 CP 和 AP 两种选择。CP 模式保证分布在网络上不同节点数据的一致性，但对可用性支持 不足，这类系统主要有 BigTable，HBASE，Mongo DB，Redis，Memcached DB， Berkeley DB 等。AP 模式主要以实现“最终一致性（Eventual Consistency）” 来确保可用性和分区容错性，但弱化了数据一致性要求，典型系统包括 Dynamo，Tokyo Cabinet，Cassandra，CouchDB，SimpleDB 等。 在大型的分布式系统中，作为关系数据库替代物的分布式存储被越来越多地使用，这些系统不要求严格的一致性，或产生大量的不需要永久保存的中间结果， 如分布式缓存，同时提高了性能和可用性。2.2 集群的相关产品和解决方案2.2.1 Apache 集群Apache 的集群技术是面向 Tomcat 应用服务器的成熟解决方案，通过反向代 理的配置，自动保证集群内服务器的负载均衡，并且自动完成服务器之间的 session 数据同步。Apache 的 session 同步策略有两种：第一种是使用粘着性 session（sticky session），即同一个会话的请求都会发送到同一个 Tomcat 服 务器上去，于是便可以读取到相同的 session 数据；第二种是使用 session 复制， 即在每一个 Tomcat 服务器中都保存一份 session 数据，同样能保证 session 的 一致性。Apache 集群主要解决的是 Web 服务中 session 的同步问题，数据量相对较小， 而对于大数据在服务器之间的同步，比如分布式缓存的同步问题，Apache 就没 办法很好地支持，一个原因在于：Apache 进行数据复制的原理是用整个 session 来进行数据广播，这势必造成大量的内存、CPU 以及网络带宽的消耗。但是 Apache 集群对于负载均衡方面的支持是十分优秀和成熟的，支持按照 请求次数、按照流量或者按照机器的繁忙程度进行均衡，尽量使每台服务器都获 得相同的负载。2.2.2 Terracotta 集群Terracotta 是一个纯面向 Java 的开源的集群解决方案，通过在 JVM 级别上 对 Java 字节码进行了增强，自动插入了类似 AOP 的指令，用以监控类中字段的 变化，然后 Terracotta 只把变化的字段发送给 Terracotta 服务器。Terracotta 服务器记录着所有节点对共享数据的使用情况，并且把修改的字段只传输给需要 这些数据字段的节点上去。Terracotta 仅仅传输对象中被修改的字段，而不是 使用 Java 序列化去复制整个对象，并且只给需要数据的节点传输，避免了数据广播，这样使得数据的同步更有效率。有效使用 Terracotta 的用例包括：HTTP session 复制，分布式缓存，POJO 集群，协作、协调和事件。Terracotta 已经和 Ehcache 进行整合，可以提供高 性能的分布式缓存方案。并且，由于 Terracotta 是通过 Java 字节码增强的方式 注入集群行为，所以这是一个对原始代码更改非常少的集群解决方案。3课题主要研究内容、预期目标根据以上对集群技术和产品现状的分析，我们认为，将 OncePortal 的单机 版本移植到集群模式下，Terracotta 是目前较好的解决方案。首先，OncePortal 本身是用纯 Java 编写的，而 Terracotta 就是专门为 JVM 集群设计的；其次，要 将单机系统改造成集群系统，Terracotta 是目前来说对代码的侵入最小的方案， 只需要增加一些配置文件，不需要对原来的单机代码进行任何修改，就能部署到 集群中；同时，Terracotta 是一个开源的方案，我们可以很方便地对其进行二 次开发以更好地符合 OncePortal 的应用环境和业务逻辑。因此，OncePortal 的集群解决方案是：在 Terracotta 之上进行二次开发， 包括设计实现数据同步方案和分布式缓存方案，并且结合 Apache 集群以支持负 载均衡，最终实现 OncePortal 的集群支持。3.1 主要的研究内容研究如何搭建起一个基本可用的 OncePortal 集群系统，组装起基本的三层 集群架构，即：1、负载均衡器，使用 Apache 的负载均衡解决方案；2、服务器 池，使用若干台部署有 Terracotta 客户端的 OncePortal 服务器；3、共享存储， 即 Terracotta 服务器端。其中，设计 OncePortal 集群解决方案的关键技术点包括：1. 在 Terracotta 上进行二次开发，并提出一种支持粗粒度数据的变化监控 方案。Terracotta 对于数据的变化监控是基于 Java 类的域字段（field） 的，这样的监控粒度对于 OncePortal 来说太细了，过于细的粒度会导致 Terracotta 客户端频繁地将数据的变化报告给 Terracotta 服务器，产 生不必要的 CPU 操作和网络流量。OncePortal 中的业务操作是以 portlet实体为单位的，因此以 portlet 实体为粒度来进行数据的变化监控符合 OncePortal 的业务逻辑，同时不牺牲性能。2. OncePortal 中应用服务器上的 session 数据可以由 Apache 集群自动进 行同步，但是 OncePortal 的一个页面是由若干个 portlet 组成，这些 portlet 拥有自己的 session，这些 session 的数据同步是 Apache 无法 直接支持的（如下图），一个原因是：portlet 是由用户自己设计编写的， 其 session 中可能存放了不可序列化的对象。为了实现集群中整个 OncePortal 的 session 同步，必须要解决 portlet 中 session 的同步问 题。3. 解决“循环引用”的对象的序列化问题。在 OncePortal 中，存在着不少 循环引用的对象（如下图），这样的对象如果直接序列化传送时，在目标 机器上就会出现不符合业务逻辑的结构，如图中，在服务器 2 中总共维 护了 4 个对象，与原逻辑不符。为了保证 OncePortal 集群中对象引用逻 辑的一致性，必须解决这些“循环引用”的对象的序列化问题。综上，我们搭建和部署一个完整的 OncePortal 集群，并测试可用性和伸缩 性。3.2 预期目标1. 实现支持粗粒度数据的 Terracotta 变 化监控方案，将该定制化的 Terracotta 客户端部署到 OncePortal 服务器上，可以对数据的变化进 行监控，并把修改过的数据报告给 Terracotta 服务器，由后者来对每个 节点的数据进行同步和更新。2. 实现应用服务器之间的 session 同步，尤其是 portlet 中的 session 同 步。3. 解决“循环引用”的对象序列化问题，使得对象之间的引用关系符合业 务逻辑。4. 最终搭建起一个可用的 OncePortal 集群系统，由 3 层架构支撑，包括： Apache 的负载均衡器，部署有 Terracotta 客户端的 OncePortal 应用服 务器，以及 Terracotta 服务器端。集群系统支持高可用性，即使一台 OncePortal 应用服务器出现故障，别的服务器也能够提供正确的服务， 保证整个集群的正常工作。集群系统支持伸缩性，能够保证多台 OncePortal 服务器的同时协同工作，且性能不低于 OncePortal 的单机 版本。4拟采用的研究方法、技术路线、实验方案及其可行性分析采用的研究方法主要包括：调研并了解当今流行的集群架构模式；研究 Terracotta 并进行二次开发，建立支持粗粒度数据的变化监控方案；将 Apache 的负载均衡和定制化的 Terracotta 组合起来，搭建适合 OncePortal 的集群解决 方案，并且试验该集群的可用性和伸缩性。技术路线及其可行性分析：1. Terracotta 是开源的集群解决方案，通过只把变化的数据复制给需要的 节点，可以监控集群服务器之间的数据变化并实现自动同步，并且对 Java 代码的修改很小。Terracotta 中的变化监控粒度过细，这会导致过 于频繁的同步开销。可以进行二次开发，提出并建立一种粗粒度的、更 符合 OncePortal 的变化监控机制和分布式缓存机制。2. Apache 的 LoadBalancer 是一种相当成熟的负载均衡解决方案，通过配置可以很方便地建立起基于不同均衡策略的负载均衡器，并且在前端用 户看来，根本不会意识到多台服务器的存在，提供服务的就像是只有一 台超级服务器。5已有科研基础与所需的科研条件OncePortal 是软件研究所软件工程技术研究开发中心研发的门 户中间件产品，它提供了企业门户的基本运行框架及必需的支撑服务。我们将根 据 OncePortal 中 portlet 实体的使用场景加大 Terracotta 的监控粒度，建立新 的监控方案，设计定制化的分布式缓存方案，尽量减少对原 OncePortal 单机版 代码的侵入，达到构建 OncePortal 集群的目的。6研究工作计划与进度安排2013年4 月至 2013 年 7 月：调研流行的集群架构和分布式基础知识，重点 包括 Terracotta 的结构、原理和使用场景，以及 Apache 集群的相关资料。2013年8 月至 2013 年 12 月：Terracotta 的研究和分析，提出并实现新的 变化监控模型，实现 OncePortal 集群的 session 同步，将 Terracotta 和 Apache 负载均衡解决方案与 OncePortal 集成，搭建可用的集群环境，并测试可用性和 伸缩性。2013年1 月至 2013 年 2 月：代码的整理。2013年3 月至 2013 年 5 月：论文的撰写。7参考文献1 Seth Gilbert,Nancy Lynch.Brewers conjecture and the feasibility of consistent,available,partition-tolerantweb services.ACM SIGACT News,2002,Volume 33 Issue 2:51-592 EricBrewer.BrewersCAPTheorem.SymposiumonPrinciplesof Distributed Computing (PODC),20003 中科院软