移动App服务端架构设计.doc

移动App服务端架构设计.doc:..移动App服务端架构设计-:基础流程图。入口服务1■服务2■醐库1■数据*2其实有一点还需要加上,就是对json的压缩和加密,一来给用户节约流量,二来防止请求被截取破解我们的参数。具体先压缩后加密还是先加密后压缩这个问题看W求。看到这个架构没计时,你们可能会说如果程序入口挂了,所有的服务都不可以用了。所以这个架构的弱点在程序入口处,因此要有一(多)台机器做负载,负载的工具可以是HaProxy(软件)或者F5(硬件)的负载。F5比较昂贵,我没用过,haproxy的配罝我就不贴了,谷歌一大把。二:Json参数设计手机App的灵魂是用户数,有了用户数才有一切。据我得到的数据,(闪部数据)。所以一款App的成功大部分収决于渠道推广。。可能某个用户换了一款手机,但是还想用以前的账号登录,所以userlD也是必不可少的字段。但是会出现一个问题,,userlD,但是他是一个用户,所以对用广信息的更新是至关重要的。但是用户数据的更新不可能放在客户端,,用户会义无反顾的选择否。如果你偷偷上传用户的隐私数据到数据库,这是国内通用做法。不排除被用户控告的可能性。所以我们要想一起两全其•美的办法。每一次都把这些信息上传上去,美其名曰:唯一标识用户。至于其它的数据,那是运营哥需要的数据,可以在数据中加上。{"context”:{"userlD••:n1H,npwd":"fuckGfw","imei":”353641012835017",nimsi":"460000000000000”"reqType":{”rt":”xxx"}}每次把context屮的参数进行更新,保持你所拥有的川户数据是真实值钱的。其屮的rt字段为每次请求的目的(请求类型),它用來区分每次请求上來我们需要调用那一台服务器的服务来处理请求。服务架构和数据已经准备0K,:,具体在项目中的选择主要看心情。我心情不好,。,代码如下2:3:4:5:6:7:8:9:10:if(!IsPostBack)}catch(Exceptionexc)1: protectedvoidPage_Load(objectsender,EventArgse)11:}12:}在主入口处加一个大范闱的catch,而在catch屮输出系统忙:。嗯,美其名曰:用户体验。对json的压缩我使用了GZip,代码如下:pressionHelperIII<summary>pressthebyte[]5:6:7:8:9:10:11:12:13:III</summary>III<paramname="input"></param>III<returns></returns>publicstaticbyte[]Compress(byte[]inpu