移动App服务端架构设计

移动 App 服务端架构设计一：基础流程图。其实有一点还需要加上，就是对json 的压缩和加密，一来给用户节约流量，二来防止请求被截取破解我们的参数。具体先压缩后加密还是先加密后压缩这个问题看需求。看到这个架构设计时，你们可能会说如果程序入口挂了，所有的服务都不可以用了。所以这个架构的弱点在程序入口处，因此要有一( 多) 台机器做负载，负载的工具可以是HaProxy(软件 )或者 F5( 硬件 ) 的负载。 F5 比较昂贵，我没用过，haproxy的配置我就不贴了，谷歌一大把。二： Json参数设计手机 App 的灵魂是用户数，有了用户数才有一切。据我得到的数据，目前一款app 从开始制作到推广到注册到充值的费用是14.6元( 内部数据 )。所以一款App 的成功大部分取决于渠道推广。 而一款手机的mac.imsi等数据是唯一标识一个手机用户的标准。可能某个用户换了一款手机，但是还想用以前的账号登录，所以userID也是必不可少的字段。但是会出现一个问题，两个mac.imsi，userID，但是他是一个用户，所以对用户信息的更新是至关重要的。但是用户数据的更新不可能放在客户端，当你界面提供了上传imsi.mac.phonenumber等字段到服务端时，用户会义无反顾的选择否。如果你偷偷上传用户的隐私数据到数据库，这是国内通用做法。不排除被用户控告的可能性。所以我们要想一起两全其美的办法。每一次都把这些信息上传上去，美其名曰：唯一标识用户。至于其它的数据，那是运营哥需要的数据，可以在数据中加上。{ "context": { "userID": "1", "pwd": "fuckGfw", "imei": "353641012835017", "imsi": "460000000000000" }, "reqType": { "rt": "xxx" } } 每次把 context中的参数进行更新，保持你所拥有的用户数据是真实值钱的。其中的rt 字段为每次请求的目的( 请求类型 )，它用来区分每次请求上来我们需要调用那一台服务器的服务来处理请求。服务架构和数据已经准备OK ，我们接下来coding. 1 ：请求入口的承载类型选取你是选择传统的.aspx页面为入口还是ashx 还是 wcf/wcfRest/WebApi 这个自由度很大，具体在项目中的选择主要看心情。我心情不好，所以选择.aspx页面。主入口为 Default.aspx页面，代码如下 1: protectedvoid Page_Load( object sender, EventArgs e) 2: { 3: if (!IsPostBack) 4: { 5: try 6: { 7: } 8: catch (Exception exc) 9: { 10: } 11: } 12: } 在主入口处加一...