Gleasy首席架构师薛珂：以开源为基础实现分布式框架及中间件

原文  http://www.csdn.net/article/2015-03-16/2824218

注：本文首发于CSDN，转载请标明出处。

【编者按】本文为在线办公平台 Gleasy 的联合创始人、技术团队掌门人薛珂所写，他给我们分享了Gleasy一路走来的技术实战。据悉，发布近三年的Gleasy，已经成功积攒50,000多家企业用户，在应对在海量存储以及高并发前提下的各种基本问题的解决方面深有心得。

与此同时，2015年3月18日，Gleasy将正式发布3.0版“约了”，并推出英文版、繁体版，以及启动互联网服务合作伙伴邀约计划。

以下为正文：

Gleasy作为云技术服务提供商，主要解决两大关键问题，其一是应用整合问题，即如何把需要专门开发的行业应用整合进Gleasy平台，使到这 些从用户层面来讲完全就是Gleasy的一部分，应用之间亦可以无缝地进行整合沟通。其二是技术框架问题，即如何通过标准框架和中间件来大大简化应用研发 复杂度，避免应用开发商在一些关键而且深入的技术问题上（比如分布式，大并发，海量存储，高性能，高可用等问题）的大量投入，从而缩短应用研发生命周期。

应用整合

Gleasy使用一种叫作在线应用间进程通信技术来解决应用的整合问题。Gleasy里面运行的一盘，一说，美图秀秀等等，全都是一款款的独立应 用。当用户使用Gleasy的时候，这些独立应用如何打开，资源如何加载，如何管理（比如关闭），如何监控，如何调用（比如用美图秀秀打开一盘文件）等 等，都是该技术解决的问题。

应用进程： 应用在Gleasy运行时的存在形态，它可以是一个URL（比如美图秀秀），也可以是JS的类和DOM（比如一盘）。当用户安装某个应用后，就会在在线应 用注册表中生成注册项，注册项包含了应用的URL或者用于启动的JS类（MAIN函数）。点击图标启动时，内核的进程管理器 (ProcessManager)会读取注册项，动态加载应用运行时所需的资源（JS等），运行MAIN函数生成应用进程(Process)实例。

进程间通信： 应用通过调用进程管理器提供的API来声明自己可以提供的服务。调用者通过调用进程管理器的API来调用服务。比如从项目管理中选择一盘文件这个调用，进 程管理器会寻找“一盘”这个应用进程，看是否存在，如果不存在，会尝试启动它，启动成功后把事件投递到该进程的消息队列中，一盘应用进程会定时消费在自己 消息队列中的消息。从而实现应用间通信。

基于进程通信技术，Gleasy声明了大量可以供全部应用调用的服务。应用通过调用这些服务，可以轻松地集成诸如单点登录，选择组织架构，打开/保存文件，发起邮件，发起工作流，发起日程，发起聊天等功能。

技术框架

云技术的挑战之一是如何应对在海量存储，高并发前提下的各种基本问题的解决。一些看似非常简单和基本的问题，一旦遇上海量存储和高并发，便变得复 杂起来，比如长链接保持和消息推送，文件存储，实时检索，定时任务等问题，如果不在架构阶段做好充分的规划，等系统成型时再去调整，将会是一场灾难。 Gleasy经过长时间摸索，在开源和自主研发方案之间适当不断平衡，最终以开源为基础，吸取多家之长，使用多种技术实现了一整套分布式框架及中间件，来 应对这些挑战。

分布式消息队列（CloudMQ）： 解决系统访问量瓶颈的利器，使用MQ可以轻松将一些热点场景变换为异步实现，从而根本性提高性能。参考了Apache的开源项目Kafka和淘宝开源项目 Meta。承继了分布式及高性能高吞吐量的特性，但抛弃了前两者的broker设计，从而令整个方案更轻量。基于JAVA打造，借助redis实现队列存 储，借助Zookeeper实现结点协调及生产消费调度。

分布式文件系统（Cloudfs）： 吸收了HDFS和FastDFS的经验，特别是借鉴了FastDFS关于分组的思想，但引入了诸如自动去重，文件极速复制，断点续传等更适合云OA类应用 的特征。基于JAVA NIO实现，借助CloudMQ实现结点了之间的文件实时同步，借助redis存储文件结点索引信息，实现了自动去重。

分布式即时通讯（CloudIm）： Openfire在长连接保持和消息推送方面做得非常优秀，XMPP协议的普适性令到多终端开发极为方便。但是Openfire并不支持分布式，另外基于 Mysql的存储技术在性能方面令人望而生畏。好在它提供了完善的plugin机制，从而给我们打造完全适合自己的分布式IM提供了便利。基于 plugin机制，将存储完全替换为redis，引入zookeeper进行结点之间协调，提供HTTP接口供后端系统集成。一款分布式的即时通讯中间件 就这样打造出来。

分布式检索平台（CloudIndex）： 数据检索，特别是大数据的检索，一不小心就会令整个系统陷入崩溃，CPU轻松上到100%，即使建了索引，插入和更新时也是噩梦。基于Lucene的 Solr，提供了丰富和便利的数据准实时检索方案。但是Solr的主从复制和Snapshot机制，经过我们长时间验证，发现在大数据下存有明显的问题， 一是延迟极为，二是出现多次崩溃（I/O狂升）。无奈之下进行改造，引入CloudMQ使用消息队列进行结点之间的数据同步，读写性能得到极大提升。

分布式任务调度(CloudJob)： 定时任务是许多功能必不可少的功能，比如日历提醒，生日提醒。Quartz在单机环境下表现还是可以的，但是一旦涉及N台机器的定时任务触发，就比较吃力 了，性能上不去，经常会收不到提醒。redis丰富的数据结构hashset为我们实现任务队列提供了极大便利，结合zookeeper的结点协调能力， 一款精致而强大的分布式任务调度便产生了。

Gleasy在整个技术服务提供商这条路上已经走了4个年头，也积累了大量的经验和教训。在分布式设计的过程中，由于功能特性及需求的不同，供选择的方案 可以千差万别。了解一种技术，最重要是了解技术背后的弱点的限制。就像上面所列举的一些自主研发的核心中间件，最初都是由开源开始，最终以自主研发或者二 次改造结束。但是如果没有开始时众多的开源产品，估计我们所走的弯路会更长更崎岖。技术选型中，应相信一点，没有最好的技术，只有最适合的技术。

作者介绍：薛珂，Gleasy联合创始人、技术团队掌门人，互联网资深架构师，当前主要负责主持Gleasy全部产品的研发及运维工作，研发团队的建设和管理，同时作为首席架构师，负责Gleasy平台底层架构相关设计工作。