Gleasy分布式架构体系介绍

声明
本文为Gleasy原创文章,转载请指明引自Gleasy团队博客

正文
Gleasy作为专业的云服务平台和一站式云办公平台,分布式技术为支撑平台正常运作关键性技术。从商业利润和运维成本角度出发,千方百计榨干服务器的每一分性能很大程度上影响着Gleasy的商业价值,因此对性能的追求,成为Gleasy分布式架构体系中极为重要的考量指标;从用户角度,特别是作为Gleasy主要收入来源的企业用户的角度出发,保证业务处理的正确性和服务不中断(高可用性)是支撑用户信心的重要来源。高性能,高可用,正确性成为Gleasy分布式架构体系的关键技术因素。

Gleasy一直奉行着“深耕细作”,“磨刀不误砍柴功”这种朴实的思路进行开拓发展。从公司成立之初就开始思考分布式架构体系的长远趋势,也参考了大量国内外比较有影响力的互联网公司公布的一些技术方案,比如Facebook,Twitter,新浪,淘宝,甚至有不少方案已经开源。当时Gleasy面临着艰难的选择,要么拥抱开源,要么自主研发;如果拥抱开源,则Gleasy的首个开发周期可能会缩短1/3左右,但付出的代价是要深入吃透这些开源方案为我所用,必要时还得修改源代码,这后面的代价很难估计,另外还存在一项风险就是万一选用的开源方案在将来才发现某一些特性不满足,就得推倒重来;如果自主研发,则项目的开发周期会相应延长,而且似乎有重复造轮子的嫌疑。Gleasy在艰难的选择下最终决定部分使用开源,部分自主研发,一个基本原则是凡是不对业务流程产生重大影响的工具类全部采用开源,决定业务流程及软件流程的中间件则以自主研发为主。一直走到今天,Gleasy选用的重要开源工具主要包括有Zookeeper,Solr(Gleasy在它基础上研发了分布式索引平台),Openfire(Gleasy在它基础上研发了分布式的扩展插件),Redis(在它基础上研发分布式NOSQL数据库集群),Nginx,Haproxy,Keepalived,MySQL(在它基础上研发的ShardDB);而自主研发的分布式中间件则包括分布式文件系统(Cloudfs),分布式即时通讯(CloudIm),分布式消息队列(CloudMQ),分布式任务调度(CloudJob),分布式检索平台(CloudIndex),分布式NOSQL数据库集群(CloudRedis)。本文接下来介绍一下Gleasy自主研发的中间件,它们共同构成了Gleasy的分布式架构体系。


分布式架构逻辑图.

分布式文件系统(Cloudfs):反复研究HDFS,TFS,Gridfs(Mongodb),FastDFS基础上研发出来的分布式文件系统。存储架构与FastDFS相似,包括数据结点(Node),数据组(Group),分区(Region)三级;数据结点(Node)为最终物理存储结点,相同数据组(Group)的不同结点会进行实时的数据同步,即同组的结点数据最终一致; 相同分区(Region)内的文件会自动去重,即相同内容的文件在同一个分区(Region)只会有一份。Cloudfs通过使用消息队列(CloudMQ)进行同组结点间的数据序列同步,从而保证最终一致性,这一点跟FastDFS的binlog双向同步最为相似。Cloudfs使用Zookeeper来监测存储结点状态维护和变更,使用CloudRedis存储文件索引信息,使用Nginx作为文件下载服务器。性能优秀,单台Server线上监测得到的数据,文件上传的IOPS可以达到1200,上传速率达到25MBps,复制文件TPS达到9000以上,创建和删除文件的TPS达到30000以上。支持存储结点的动态加入和退出,支持线上扩容,数据多备份,结点动态负载均衡,最大理论可支持文件数量达千亿以上,支持结点数3000以上。

分布式即时通讯(CloudIm):承载着Gleasy所有推送服务的平台级中间件。基于Openfire,但除了保留其基本的连接保持和结点间通讯能力外,几乎进行了全新的改造。CloudIm提供了方便的API给第三方应用,开发者可以使用CloudIm的API轻松地实现消息即时推送(从而实现例如即时通讯,协同办公,即时提醒等实时功能),而不用考虑长连接保持,线路故障,服务器负载,用户状态变更通知等繁复的要求。CloudIm性能优秀,其提供的全部API的TPS都介于15000-35000之间。单台服务器线上实测可保持连接数超过7万,消息延迟低于50MS,集群可支持上千结点。支持结点动态加入或退出,支持线上扩容。

分布式消息队列(CloudMQ):一种分布式的消息队列(MQ)实现方案,设计原理参考了Apache的开源项目Kafka及淘宝的开源项目MetaMorphosis,承继了分布式及高性能高吞吐量的特性。CloudMQ实现简单,无Broker设计,可保持消息顺序,采用纯PULL加通知机制几乎避免了消费延迟,采用多分区机制保证提高系统的吞吐量,最大消息数量为数十亿级别,另外还支持延迟消息(比如5分钟之内发生100次更改事件,只推送一次最终结果,大幅减少重复消息)。生产消息TPS介于35000-45000之间,消费消息的TPS为40000左右。

分布式任务调度(CloudJob):将任务按特定规则(负载均衡,地域原则等)分配到多个结点执行的调度框架。支持Crontab标准的任务重复和定时策略,支持海量定时任务(千万级),保证任务处理的实时性和顺序性,支持实时查询任务状态或中止任务。任务调度吞吐量可达2万每秒。

分布式检索平台(CloudIndex):海量实时检索系统,承载着Gleasy全部的分词检索任务。主要采用Solr和CloudMQ实现,使用CloudMQ保证更新性能以及保证集群结点获得相同的更新序列,使用Solr实现分词及实时检索。支持索引分片(分片规则包括HASH法及数字区间法),自定义分词,结点负载均衡。索引读写延迟小于200MS,单一索引的数据规模可以达到上亿级别。

分布式NOSQL数据库集群(CloudRedis):基于Redis研发的数据库集群,兼容Redis的全部数据结构及大部分的命令集合。由客户端使用一致性HASH算法将请求按照KEY的HASH请求到集群内不同结点执行,使用binlog操作序列同步方式来保证不同服务结点的数据最终一致性;当服务结点变更时,客户端主动发现结点变更,重新计算HASH,集群内其它服务结点获知结点变更,保证binlog已经消费完毕的情况下才继续提供更新服务,从而保证结点变更情况下的数据一致性。性能极为优秀,非批量操作读写命令可达到10万每秒以上处理速度,超越了原生Redis,可支持十亿级别或更高数据存储。

以上介绍的分布式中间件,共同构成了Gleasy分布式体系的基础,在这些基础之上,Gleasy研发出了各种各样分布式应用,支撑起在线办公平台各种复杂业务场景。

联系作者
对本文有兴趣,有想法的,不解不满等。。欢迎赐教交流。
邮箱:xueke@gleasy.net
qq:99103622

best online casino

此条目发表在 Java技术, 分布式技术, 数据库技术, 运维 分类目录。将固定链接加入收藏夹。

发表评论