Gleasy首席架構師薛珂:以開源為基礎實現分佈式框架及中間件

  【編者按】本文為在線辦公平台 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平台底層架構相關設計工作。


來源:CSDN

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

其他
   
聯系我們
 
支持平臺
 
微信公眾號
       

關於我們
媒體報道
開放平臺
安全保障
友情連接

電話:13365902095
廈門 | 杭州 | 廣州
廈門市思明區塔埔東路166號觀音山商務運營中心11號樓406室

window pc

關註,領取優惠

web
IOS
Android
 
2014 格子雲 浙ICP備12028668號   增值電信業務經營許可證浙B2-20130019