移動App服務端架構設計

其實有一點還需要加上，就是對json的壓縮和加密，一來給使用者節約流量，二來防止請求被擷取破解我們的引數。具體先壓縮後加密還是先加密後壓縮這個問題看需求。

看到這個架構設計時，你們可能會說如果程式入口掛了，所有的服務都不可以用了。

所以這個架構的弱點在程式入口處，因此要有一(多)臺機器做負載，負載的工具可以是haproxy(軟體)或者f5(硬體)的負載。f5比較昂貴，我沒用過，haproxy的配置我就不貼了，谷歌一大把。

, "reqtype": }

每次把context中的引數進行更新，保持你所擁有的使用者資料是真實值錢的。其中的rt欄位為每次請求的目的(請求型別)，它用來區分每次請求上來我們需要呼叫那一台伺服器的服務來處理請求。

服務架構和資料已經準備ok，我們接下來coding.

1：請求入口的承載型別選取

你是選擇傳統的.aspx頁面為入口還是ashx還是wcf/wcfrest/webapi 這個自由度很大，具體在專案中的選擇主要看心情。我心情不好，所以選擇.aspx頁面。

主入口為default.aspx頁面，**如下

1:   protected void page_load(object sender, eventargs e)

2:

8:          catch (exception exc)

9:

11:      }

12:   }

在主入口處加乙個大範圍的catch，而在catch中輸出系統忙。嗯，美其名曰：使用者體驗。

對json的壓縮我使用了gzip,**如下：

1:      public static class compressionhelper

2:

19:                  ms.close();

20:              }

21:              return output;

22:          }

23:

24: ///

25: /// decompress the byte

26: ///

27: ///

28: ///

29:          public static byte decompress(byte input)

30:

42:                      gs.close();

43:                  }

44:                  ms.close();

45:              }

46:              return output.toarray();

47:          }

48:      }

壓縮完json後，還需要加密，別腦殘的說md5，小心我抽你。這個看你對資料的安全性如何看待。如支付寶用的rsacryptoserviceprovider加密，如asp.net的viewstate用的base64編碼。其實用什麼編碼無所謂，你只需要定製屬於你自己的碼表。**我就不貼了，我怕把我1個月100塊的保密費弄成10000的律師費。。。

接下來到重點了。你反序列化時可以使用linq to json或者newtonsoft.json隨便得到了rt欄位的型別。一般同學就開始這樣寫了：