NO IMAGE
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

 

      FLASH與後端通訊的手段多種多樣,網上相關教程太多了,這裡不再例舉。但很多時候,創業團隊由於受制於各種現實條件,可選擇的方案並不多。像我們公司,剛開始基本上只能選擇FMS PHP MYSQL。其實,對於我們前端來說,後端選擇什麼解決方案對我們的影響並不大,我們無非就是用的API不一樣而已。多看看教程,用很少的時間我們就能掌握其要領。那麼前後端合作的難點是什麼呢?我覺得關鍵是邏輯的劃分。

  “前後端合理劃分邏輯”,這句話咋看上去貌似簡單,其實裡面蘊含著諸多方面的考慮。比如安全性、後端效能、工作量、人事分工等等。安全性:記得我們的遊戲同時線上超過3000的時候,就已經有人開始攻擊我們的後端了,篡改了很多人的個人資料。幸虧攻擊的人只是我們一個善意的玩家,如果是惡意的商業攻擊,後果不堪設想。經過這次後,老闆開始纏著我們追問“怎麼防止別人攻擊,提高安全性”。這個問題又一次把我們難住了,我們都知道,基於HTTP的請求不被擷取是不可能的,而SWF檔案又不存在絕對的安全。就算你防得了惡意進攻,你也防不了良性的外掛,想從技術層面讓別人完全攻擊不了我們也是不可能的。那我們是不是隻能坐以待斃了?不是!如果前、後端在合作的時候,資料邏輯與合法性檢查都是做在後端的,就可以很好的避免一些良性外掛。首先是遊戲資料邏輯要儘量全做在後端,比如使用者在玩小遊戲的時候,我們不要只是在使用者結束小遊戲後,簡單的把資料傳回後端,後端記錄進資料庫完事,一旦攻擊者發現了你這個傳資料的後臺介面,完全可以避開SWF,做外掛直接呼叫你這個介面刷分,就算你驗證使用者也沒用,因為他可以先註冊一個合法的使用者,然後在外掛中登入再刷分。當然,你還可以對遊戲分數先加密在傳給後端,提高攻擊難度,但這也是不保險的,因為加密演算法就在你的SWF檔案中,別人可以很容易獲得。所以正確的做法應該是:遊戲開始的時候只告知後端遊戲ID→後端標識ID對應的遊戲已經開始並記錄開始時間→使用者每次獲得一個分數時,前端傳回來的不是分數,而是一個動作ID,後端根據動作ID給使用者加分→遊戲結束時,前端告知後端遊戲已經結束→後端得知遊戲結束,記錄結束時間,計算時間差,根據時間差和最後得分是否符合標準做出相應處理,如果符合標準就把最後得分入庫,並返回前端顯示給使用者,如果不符合標準,就啟動作弊處理系統。而這個標準一般是由數值策劃給出的。經過我這麼一分析,你可能頭痛了,本來一個很簡單的小遊戲計分,怎麼搞得這麼複雜?前後端工作量都增加了不說,對後端效能也提出了更高的要求,伺服器可能要增加了,後端人手可能要增加了,開發週期也要延長了,值得麼?這個問題問的很好,這正是我下面要說的:後端效能、工作量、人事分工:一旦我們每一步進行安全性與合法性驗證後,整個專案的工作量都會大大膨脹,開發週期也會大大延長;一旦我們把資料處理、業務邏輯和安全驗證都移到後端時,後端的壓力就會增加,伺服器要增多,對後端人員的能力要求也會提高。很多初創團隊在專案初期人力財力,軟體硬體都不足,可能顧不上那麼多,一心想著早點讓專案上線。在這種情況下,我覺得安全性可以暫時放一下,眾所周知的安全漏洞補上就可以了。但“資料處理和業務邏輯”這個,寧可開發的慢一點,寧可再招個後端高手,寧可多幾臺伺服器成本,也要把它們儘量都放在後端。因為這個沒分清的話,會影響到整個系統的清晰度,嚴重影響專案中後期的發展,為日後的重構增加難度和超多的工作量,我們還指望著在重構時加強安全性呢,到時候資料處理和業務邏輯還是要放後端!所以綜合考慮,該出手時就出手,能省的不浪費,不能省的不要摳!

  前面一節談了前後端合作的難點。這裡再簡單的談兩個要點:

  1,前端人員不要以前端的角度看後端:前端和後端有個本質的區別,就是前端的負荷是分擔在每個客戶端的,而服務端的負荷是集中在伺服器上的。對於我們前端來說,一個功能多佔了幾K記憶體,SWF檔案大了幾K根本不是什麼問題,可對後端來說就是很嚴重的問題了,一個人大幾K,上千人就是幾M了。伺服器在連線數、記憶體和CPU之間會有微妙的平衡點,一旦這個平衡點被打破,隨便再多哪怕一點點資源佔用,整個伺服器的效能都會嚴重下降,影響使用者體驗,當然,如果你有幾十上百臺冗餘伺服器供你負載平衡,你可以當我沒說,可如果你像我們公司一樣,一開始就3、5臺伺服器的話,就請前端人員一定要多多配合後端人員,幫他們省出每一個位元組,每一次請求。比如像道具屬性會有很多文字說明,這些說明應該以類似XML檔案的方式儲存為靜態檔案,後端返回給前端的道具資料包裡只需要一串物品ID,前端就可以根據這些物品ID在XML檔案裡查詢出這些道具對應的靜態物品屬性了。別看這些資料可能只有十幾K,對後端來說意義重大。還是那句話,只要不是架構性問題,前端不要怕麻煩,要儘量配合後端提高效能。

  2,前端後端要有很明顯的BUG分界點。當一個BUG出現時,後端應當很快的用一種統一的方案證明資料沒有問題!這個方案必須讓前端知道,並讓前端也可以操作。大家熟知的php
remoting裡有一個servicebrowser,這個東西就很好,它能羅列出所有PHP的介面,我們輸入引數,它就返回結果,我們可以根據結果直接檢視資料是否正確。——確定資料的正確性,對前端DEBUG非常重要,而一個BUG的解決,一般都是由前端人員入手並進行定位的。

  其實相對於前端和美術的合作,前端與後端的合作還是簡單清晰的,前後端在開發的過程中,應該是非常獨立的,後端開發完全可以先啟動,把資料介面提前寫好,等著與前端整合,而當整合過程發生問題時,又可以很快的界定是誰的問題。

相關文章

程式語言 最新文章