力可科技總經理馮彥文(圖右)帶領開發團隊,打造出爆紅的Cubie Messenger,3個月就有2百萬人次下載,風行東南亞,在泰國、新加坡和馬來西亞都曾登上蘋果App Store不分類App排名冠軍。

你若走到曼谷街頭,不少泰國智慧手機用戶手機中的即時通訊App,不是老牌的WhatsApp、也不是在臺灣狂打廣告的Line,而是一個以綠色貓頭鷹為Logo的Cubie Messenger。在短短幾個月內,這個App光是在泰國就有超過70萬人下載,還成為泰國App Store不分類免費App熱門排行榜的冠軍,超越任何其他App,像是大家熟知的憤怒鳥。而且不只泰國,Cubie Messenger在新加坡、馬來西亞也都曾是免費App的排行榜冠軍,而在臺灣和香港,則曾登上App Store社交類App的冠軍。

Cubie Messenger在今年3月推出後,35天就達到1百萬次下載量的佳績,3個月後更是累計達到2百萬人次的下載量,不論在iPhone平臺或是Android平臺上,都約各有1百萬人次。每天活躍用戶近百萬人,Cubie Messenger的後臺伺服器,每天要傳遞4百萬則簡訊。

打造出這個冠軍App的正是臺灣少數專職開發社群遊戲的軟體公司力可科技,這個規模只有15人的公司,2年前就打造出4百多萬用戶的Facebook遊戲平臺嘎姆擂台(Gamelet),不過,這兩年社群遊戲的成長趨緩,Gamelet的用戶數成長腳步也變慢,力可科技總經理馮彥文想要尋找新的機會,作為力可科技的下一個戰場,最後他選擇了手機上的即時通訊軟體。

馮彥文的目標是未來市場規模大的產品,他評估,像Line這類聊天App,現在有幾千萬用戶,未來可以成長到幾億用戶,就算不是第一名的App,也有機會發展成數千萬名用戶規模的產品市場。

另一方面在桌面系統的即時通訊軟體就已經是分眾市場,而且不同族群、國家或地區會使用不同的即時通訊軟體,這是一個可以有區隔的市場,不像社交平臺只會有一個Facebook。「只要是大眾市場就會分群,就像汽車,而即時通訊軟體也是。」馮彥文說。

所以,去年8月開始,他帶領著旗下4名開發人員和1名美術設計人員組成開發團隊,開始打造一個具有病毒式串聯功能(Viral)的手機即時通訊App,也就是Cubie Messenger。

Cubie Messenger(簡稱Cubie)是一個社交型的即時通訊軟體,也就是聊天軟體,但結合了繪畫功能,讓使用者不只可以傳遞文字或照片,還可以自己用手指頭畫一張圖傳給朋友。Cubie後臺系統每天傳送的簡訊中,有近1成的訊息會傳送使用者自己畫給朋友的圖。

Cubie在取得使用者同意後,還能夠自動發送訊息邀請用戶手機通訊錄上的每一個朋友加入,如此循環,還可以繼續透過這個朋友邀請更多的朋友,就像病毒感染一樣,只要環境允許就可以快速擴張,這就是病毒式軟體的擴張特性。

打造千萬用戶等級的系統架構

力可科技資深軟體架構師陳彥任表示,Cubie後端系統採Java語言開發,包括了3個子系統,分別是負責傳遞訊息的Message Server,第二是用來保存暫存記錄和帳號資料的資料庫系統,第三則是處理外部發簡訊的服務,這項服務用來處理手機簡訊認證帳號的工作。

一開始,馮彥文就打定主意要做一個上千萬用戶使用的服務,所以在系統架構上,陳彥任也採用了水平擴充(Horizontal Scale)的架構設計,而且是非集權式架構,不會有一臺中控式的主機,而是像P2P服務那樣,每一臺伺服器都是主控,彼此是對等關係,陳彥任解釋,這麼做的好處是可避免任何單點故障的情況,而且可以任意擴張。

選擇NoSQL資料庫,跨資料中心建立即時備份

這樣的設計也是用戶數突然暴增時,Cubie能快速增加新伺服器來分擔流量的關鍵,避免中斷服務的關鍵。

所以,在資料庫系統上,也就選擇採用了分散式的NoSQL資料庫Cassandra。但原本力可科技在遊戲平臺上使用的Message Server是集權式架構的ActiveMQ,所以,陳彥任改用Java平臺用來開發分散式應用的Akka 框架和和Java NIO開發框架Netty ,重新來打造一個P2P架構的Message Server。

力可科技在Amazon EC2上部署Cubie Messenger的後臺系統,目前已在Amazon東京資料中心租用了12臺虛擬機器組成4個叢集來部署Cassandra資料庫,以及9臺虛擬機器部署Messenger Server。另外為了避免發生先前EC2北美資料中心整間資料中心當機的情況,因為Cassandra能自動跨資料中心同步,力可科技還租用了新加坡機房來作為資料庫叢集的即時備份。

不過,服務剛開始上線時,力可科技只建置了3臺Messenger Server,陳彥任表示,因為沿用在傳統Java開發習慣,也用同步操作(Synchronous Operation)的方式來設計Messenger Server遠端連線中訊息傳遞的方式,結果一臺伺服器只能承載二、三千人,系統效能就會因為程式中被Block的Method而大受影響。

後來,改用非同步操作來設計訊息傳送,讓下一個動作的程式不用等待前一個動作完成,而是可以各自進行,再透過訊息通知機制來告知前一個動作完成的結果。如此一來,一臺Messenger Server的承載量,就可以增加到了10萬人。

但是,到了10萬人的等級,Cubie服務再度凍結,這次的問題發生在Cassandra資料庫的存取效能,陳彥任表示,因為用戶成長速度太快,短短一個月就達到百萬人次,相當於1個禮拜就增加了20、30萬人,但是,當時來不及進行資料庫最佳化,幸好一開始就採取水平擴充架構,所以,當時就緊急增加更多Cassandra伺服器,以空間換取時間的方式來爭取到1周調校系統的時間。

用戶繼續成長,下載量在4月底達到了百萬人次,東南亞用戶也越來越多。在Messenger Server上的JVM Heap記憶體用量越來越多,系統執行記憶體垃圾回收(Garbage Collect,GC) 的次數非常頻繁。

陳彥任發現,因為 Android版的Client程式為了持續保持連線狀態,平均每一臺裝置每隔10分鐘就會重新連線一次,甚至手機螢幕關閉時,就有可能斷線需要重新連線,但是每次重新連線都要重新進行SSL加密計算,負責加密運算的Java SSLEngine占用了龐大的記憶體,一個連結的加密處理就要耗用32KB,而且加密動作也拖累了處理器的運算效能。

後來,另一位團隊成員力可科技資深工程師林康司,找到了減少重連次數的做法,讓頻率變成每小時1次。同時間,陳彥任繼續增加更多Message Server來處理大量的重連運算。後來採用新做法後,一臺部署在EC2 Large型虛擬機器上的Message Server最後可以承載5萬名用戶連線。

陳彥任表示,用戶數越高,越難找出系統效能的瓶頸,例如他也曾遇過JVM的Full GC Stop 問題,導致服務會挺擺30秒,只得詳細研究JVM設定參數,找出優化設定來改善,另外也遇到像是用來開發Messenger Server的Akka開發框架的連線問題,只好想辦法繞過這項機制,改用自己寫的程式取代。

採取Fat Client設計,讓App更聰明來減少後端複雜性

除了後端採取水平式擴充架構的設計,另一個讓Cubie容易擴充的關鍵是在用戶端App採取了Fat Client的設計。陳彥任選擇簡化Message Server的工作,只負責接收、發送以及保存沒有發送成功的離線訊息,但是許多訊息的判斷和過濾或是例外處理,則通通由Cubie Messenger的App來負責。

例如某一個用戶的裝置因為網路斷線,重複發送了2次訊息,Message Server就會照樣傳遞兩次,但是接收端的Cubie Messenger App則會判斷,這兩則訊息其實是同一則,就會自動過濾。或者是訊息是否送出成功,是否要重送,或是網路斷線時產生的錯誤資訊或例外判斷,通通由App來判斷。

由App選擇可用伺服器來分攤流量

另外像是伺服器端的負載平衡也是透過App來進行。所有的Message Server彼此會互相溝通,產生一份所有伺服器可用程度的優先順序清單,Cubie Messenger App會定期下載這份清單,再與可用程度最高的Message Server伺服器連線,若無法連線,App則切換到第二優先的伺服器,若不行再依序切換其他伺服器,幾次無法連線,則會自動更新這份清單,取得最新的伺服器可用狀況。透過這個做法,就不用在伺服器端部署負載平衡機制。

陳彥任解釋,Fat Client設計的優點是簡化伺服器端的複雜性,方便快速擴充更多伺服器,但是缺點是,因為iOS和Android的程式無法共用,同樣的Fac Client程式邏輯,就必須撰寫兩份程式碼,因此,Cubie團隊也分別有兩組開發人員,分別負責開發iOS版本和Android版本。

採用雙人搭配開發,共享開發知識

這兩組開發人員,還採用了少見的Pair Programming方法。這是XP(eXtreme Programming)開發方法論中的一種雙人搭檔的開發方法。比如說,陳彥任和林康司就是負責開發Cubie Messenger的iOS版本和後端系統的Pair。Pair Programming開發時,兩個人共用一臺電腦,使用一個鍵盤和兩個螢幕,一位擔任Driver角色,負責拿鍵盤寫程式碼,另一位擔任Navigator的角色,坐在一旁,負責檢視Driver寫的程式碼。

陳彥任表示,通常是Driver專注於他當下正在寫的那一行程式碼,而Navigator則要思考下一步,或前後幾行程式碼的關聯和發展。而且更重要的是,兩個人彼此要對話,例如Navigator看不懂時就要發問,或發現有錯誤時,也要提醒Driver,而Driver也要主動詢問Navigator的看法。

另外一個重點是,兩個人必須定期輪流更換角色,陳彥任和林康司的經驗是,大約是寫完一個小功能,或是每個小時,彼此的角色會對換一次。

林康司表示,Pair Programming的目的是分享,這個做法可以讓兩個人彼此都了解所有的程式碼,可以相互代理工作,萬一其中一個人有事,另一個人也能立即接手所有工作。

雙人搭配的效率其實比單人開發更高

這個作法看似負責寫的Driver要比自己開發時,花更多時間和對方溝通,但其實「雙人搭配的效率反而很高。」林康司表示,一個人寫程式往往要花很多時間來確定自己是否犯錯,而不是真正可以產出程式碼,兩個人搭配可以減少開發盲點,Driver也可以因為獲得Navigator的認可而放心,能夠繼續進行下一段程式碼的撰寫,不用因為一個問題而卡住很久。另一個好處是,兩個人搭配時,因為要顧及另一人,就不容易分心從事其它工作,反而是可以專注地進行數小時的開發。

不過,陳彥任表示,剛開始進行Pair Programming開發的人,老手容易搶鍵盤,忘記由另一個人接手開發程式,而新手也因為經驗不足而不敢發問質疑,他認為,至少要能交換鍵盤,輪流撰寫,而且要能有出聲,就算吵架也沒關係,萬一爭執不下淪為意氣之爭時,則需要另外一個人負責仲裁。久而久之,形成一種討論的文化,彼此就不會覺得爭執是尷尬的。

讓開發知識分享,避免負擔集中少數人

其實不只Cubie開發團隊採用Pair Programming的方法,馮彥文早在力可科技開發遊戲平臺時,只要人力足夠,就會使用這個作法,他表示,這樣的作法比較制度化,能夠維持固定目標持續產出程式碼,而且可以讓所有人都共享開發知識,人人都了解這個系統,而不是由特定人把持程式碼,也才不會造成知識的不平均,因為「能寫越多程式碼的人若越寫越多,到後來,就會變成只有少數人能寫,其他人無法參與。」馮彥文說。

截至今年6月,Cubie Messenger雖然已經過了暴衝期,但仍舊是臺灣iOS社交類排行榜Top 10之一,馮彥文評估,未來有機會挑戰千萬名用戶的規模。但他也坦言,自己還不曉得為何能快速成長的關鍵。他觀察到玩家喜歡好玩的App,而Cubie的塗鴉效果類似遊戲,很多人因此而覺得Cubie好玩而願意下載,但是力可科技沒有採取特別的行銷方式,只是提供了一個病毒式產品,目前都是透過用戶自行推薦給朋友而擴散的成果。

馮彥文表示,目前的大方向是要吸引更多人使用,以及確保已經使用的人不會流失,新功能的開發都需要滿足這兩個條件之一。

在Cubie上線初期,力可科技的團隊會透過A/B Test的做法來判斷用戶喜歡甚麼樣的功能。這個作法是先挑選出受測使用者,在這群人使用的App版本中提供不一樣的功能,例如在App第一頁是否要列出推薦朋友列表,力可科技會抽取一成使用者作為受測者,他們的App會列出這項功能,但其他人就不會。後來發現,會使用的人就算不列在第一頁,還是會自己去找出增加朋友的方法,不會加人的用戶,就算在第一頁推薦還是不會加人,所以這項功能就取消了。

如何找出對的功能,這也是馮彥文認為自己還在摸索的方向,而且還有更多的問題有待了解,他稍微比較掌握的是已經使用Cubie的用戶,但是對於還未使用的人,他則是有更多的問號。

儘管未來的發展還未明朗,但馮彥文表示:「創業就是這樣,勇往前進後又會發現更多問題,但我們已經習慣了,至少力可科技做了別人沒有做的選擇,目前看起來,這是一個正確的方向。」

Cubie Messenger不只是聊天軟體,還可以傳送手繪圖案給朋友,就像遊戲一樣好玩,因而獲得不少用戶的青睞。

力可科技採用Pair Programming的開發方法,兩個人共用一臺電腦,使用一個鍵盤和兩個螢幕,一名擔任Driver角色(圖左),負責拿鍵盤寫程式碼,另一位擔任Navigator的角色(圖右),坐在一旁,負責檢視Driver寫的程式碼。

為了打造能承載千萬用戶規模的服務,力可科技資深軟體架構師陳彥任採用了水平擴充的架構設計,而且是非集權式架構,好處是可避免任何單點故障,而且能任意擴張。


相關報導請參考「2012企業雲端開發術」

熱門新聞

Advertisement