移动app服务端架构设计

《移动app服务端架构设计》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、移动App服务端架构设计-：基础流程图。入口服务1■服务2■醐库1■数据*2其实有一点还需要加上，就是对json的压缩和加密，一来给用户节约流量，二来防止请求被截取破解我们的参数。具体先压缩后加密还是先加密后压缩这个问题看W求。看到这个架构没计时，你们可能会说如果程序入口挂了，所有的服务都不可以用了。所以这个架构的弱点在程序入口处，因此要有一（多）台机器做负载，负载的工具可以是HaProxy（软件）或者F5（硬件）的负载。F5比较昂贵，我没用过，haproxy的配罝我就不贴了，谷歌一大把。二：Json参数设计手机App的灵魂是用户数

2、，有了用户数才有一切。据我得到的数据，0前一款app从开始制作到推广到注册到充值的费用是14.6元（闪部数据）。所以一款App的成功大部分収决于渠道推广。而一款手机的mac.imsi等数据是唯一标识一个手机用户的标准。可能某个用户换了一款手机，但是还想用以前的账号登录，所以userlD也是必不可少的字段。但是会出现一个问题，两个mac.imsi,userlD,但是他是一个用户，所以对用广信息的更新是至关重要的。但是用户数据的更新不可能放在客户端，当你界面提供了上传imsi.mac.phonenumber等字段到服务端时，用户会义无反

3、顾的选择否。如果你偷偷上传用户的隐私数据到数据库，这是国内通用做法。不排除被用户控告的可能性。所以我们要想一起两全其•美的办法。每一次都把这些信息上传上去，美其名曰：唯一标识用户。至于其它的数据，那是运营哥需要的数据，可以在数据中加上。{"context”：{"userlD••:n1H,npwd":"fuckGfw","imei":”353641012835017"，nimsi":"460000000000000”"reqType":{”rt":”xxx"}}每次把context屮的参数进行更新，保持你所拥有的川户数据是真实值钱的。

4、其屮的rt字段为每次请求的目的(请求类型)，它用來区分每次请求上來我们需要调用那一台服务器的服务来处理请求。服务架构和数据已经准备0K,我们接下来coding.1：请求入口的承载类型选取你足选择传统的.aspx页而为入口还是ashx还足wcf/wcfRest/WebApi这个自巾度很大，具体在项目中的选择主要看心情。我心情不好，所以选择.aspx页面。主入口为Default.aspx页面，代码如下2:3:4:5:6:7:8:9:10:if(!IsPostBack)}catch(Exceptionexc)1:protectedvoid

5、Page_Load(objectsender,EventArgse)11:}12：}在主入口处加一个大范闱的catch，而在catch屮输出系统忙:。嗯，美其名曰：用户体验。对json的压缩我使用了GZip，代码如下：1234publicstaticclassCompressionHelperIII