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平臺底層架構相關設計工作。

（優惠票價期，速來）

這幾年，云計算成為了助力企業轉型的核心驅動力，不但讓企業的 IT 基礎架構管理煥然一新，還為企業帶來了更加智慧的運算方式。與此同時，云計算還引領著行業的變革，改變著人們的生活方式。雖然云計算處在快速的發展當中， 但從起步、研發、應用、推廣等各個環節上來說，在中國的發展時間都比較晚，其中存在的問題諸多，可謂是機遇與挑戰共存。為了推動云計算技術發展、更好的服 務行業參與者 ， CSDN云計算頻道 特在此面向 云服務提供商 、初創企業和個人等征集稿件，誠邀企業的實干家們來談談你們的技術實戰，以及進行案例分享， 也歡迎就某個熱點話題或技術來分享你的觀點 。