app后端架构设计（转）
(1)Restful设计原则
Restful风格：RESTfu设计原则，它被Roy Felding提出（在他的”基于⽹络的软件架构“论⽂中第五章）。⽽REST的核⼼原则是将你的API 拆分为逻辑上的资源。这些资源通过http被操作（GET ,POST,PUT,DELETE）。
但现在看，⼀般的操作只有两种：GET ,POST。
这个设计原则最简单的应⽤就是根据object⽽不是页⾯来设计api。最开始的时候，app的⼀个页⾯需要什么数据，api就返回什么数据。结果随着app的UI不断改版，需要的数据不断变化，不停地修改api，最后当api的改动会影响以前的版本的时候，只能写⼀个新的api版本，最后弄得api中有很多_V2,V3这样的标志，恶梦!
后来在⽹站的重构过程中，就根据object来设计api，但根据object来设计，⼜有⼀个问题，⼀个⼤object可能包含很多⼩object，是⼀个api返回全部⼩object，还是分为多个api返回？根据业务和技术，带宽等仔细考虑吧。
(2) api的命名
其中⼀个原则，⼀看api名字就知道这个api是⼲啥。在创业团队中，⼀般就只有⼀两个⼈负责后台，当你要负责⼏⼗甚⾄上百个api，你就知道不能“望名知api”是个什么样的痛苦。
(4) api返回数据
app客户端的语⾔ java 和object-c都是强类型语⾔，所以怎么处理空值显得特别重要，不合理的设计很容易造成app的闪退。
从后台的⾓度来说，api中返回的数据中，正确值和空值的类型必须⼀样，举例，⽤户名的字段是“realname": "xxx”，如果⽤户名为空，则应该返回“realname": ""。如果返回值是⼀个array，空数据则返回⼀个空array，绝对禁⽌null值。
对于客户端，必须⽤个全局的函数来处理所有api的返回数据，需要有⼀个机制：对于某个客户端需要数据，如果api中缺失，客户端⾃动补上并给予默认值。这个机制在我们的实践中⼤⼤减少了app的闪退。
同时，在数据库设计的时候，⼀个合理的设计必须是所有字段都有默认值，不应该允许null值。null在⼤量的语⾔和数据库中，会带来⽆穷的问题。对于这个数据库设计原则，我以前不太明⽩，现在经历了⼀年的api设计后，终于懂得。
如果客户端是php，还有⼀个问题，php中数组和字典都是array，但在java 和object-c中是不⼀样，这个
问题⼀定要注意。
(5)图⽚的处理
在不同版本的app中，各种不同尺⼨的⼿机中，同⼀张图⽚显⽰的尺⼨可能是不⼀样，如果每次都需要⽤返回原图，然后在客户端处理，则极⼤浪费⽹络资源。⽽如果是后台处理好图⽚才返回，则⼜是⼀个挑战，怎么有效保存和裁剪多种图⽚尺⼨呢
例如，⼀开始头像只需要返回60*60的尺⼨，后来在新的版本需要返回70*70, ⼜出了⼀个新版本，需要返回80*80, 每次增加⼀个新的尺⼨，怎么在数据库上记录下来。这个问题在⼀开始做api的时候没考虑，后来不得不⽤了⼀个极端的⽅法，没增加新的图⽚尺⼨，就在数据库中增加⼀个新的字段，保存并⽣成新的图⽚尺⼨，结果最后数据库的头像字段
有"avatar","avatar_60_60","avatar_70_70","avatar_80_80"，这种极度恶虐的设计。
最后，针对图⽚，我们才⽤了这样的策略：
（1）客户端本地缓存图⽚，只有没有合适的图⽚，才去服务器取。
（2）当客户端需要某种尺⼨的图⽚，由客户端告诉服务端图⽚的尺⼨，服务端动态⽣成并缓存起来。
采⽤了这样的图⽚处理机制，数据库中只要有⼀个字段保存原图就⾏了，其它尺⼨就由客户端告诉服务端动态⽣成。以后⽆论什么尺⼨的图⽚，数据库中都不需要记录，数据库只有原图就⾏了。
(6)返回的提⽰信息
最科学的情况，服务端只返回信息代码，具体的⽂字提⽰由客户端决定。
如果⽂字信息是由服务端返回，则最起码要区分2种信息：提⽰⽤户的信息，提⽰客户端程序员的信息。这两者的区别：
1.提⽰⽤户的信息是要在让客户知道的，提⽰客户端程序员的信息不需要让客户知道的。
2. 提⽰⽤户的信息⽂字很友好，客户不需要专业基础⼀看就知道是什么，提⽰客户端程序员的信息则很专业，例如告诉客户端少传了哪个参数？哪个参数有问题等等。
(7)在线api⽂档和测试
我们⽹站的api在线测试⽂档，既是⼀份在线api⽂档，也是⼀个在线测试⼯具，极⼤⽅便沟通和测试。每次客户端程序员觉得某个api有什么问题，我们就是这个在线⼯具上讨论沟通的。客户端程序员最喜欢这个玩意了^-^。
上个图解⼀下馋（这个图是旧版的api，已经弃⽤了）：
负责做这个功能的同事专门写了篇博客详细介绍了这个在线api测试⽂档，还带有demo：
----------------------------------------------------------------------------------------------------------
个⼈认为，在⼩型的创业团队中，特别是以应⽤产品为主，在架构后台的时候，需要集中精⼒解决⾃⾝业务上的问题，不是花时间解决第三⽅已经解决的问题，简单点来说，就是能⽤第三⽅服务就使⽤第三⽅的服务。基于这个原则，就有了下⾯的系统架构：
1. apns：由于在apns中，⽆效的token会导致连接apns连接的失效从⽽使apns信息丢失。解决的⽅案是维护发送队列，当apns服务器返回错误的token后，把这个错误token后的消息重发。第三⽅推送很好了实现了这个技术⽅案，我们选择了百度云推送。
2. email：要考虑邮件发送失败的重发问题，所以不再在服务器上搭建sendmail服务发送，选择了邮件服务商mailgun。mailgun还提供每个账号每⽉1万封邮件的免费额度，很适合创业团队。
3. coreseek: ⼀个基于Sphinx的全⽂检索引擎。在前⾯描述的LBS模块中，和检索⽤户昵称，商铺等搜索功能上需要⽤到。
4. redis：⼀个⽀持多种数据结构的key-value数据库，在LBS模块，性能优化等多个⽅⾯都有⼴泛的⽤处。
5. httpsqs：轻量级的消息队列。
后端字符串转数组
6. xmpp：采⽤了开源的openfire，当web服务需要向openfire通讯，有两种情况：
（1）实时的需求，例如注册的时候在聊天服务器注册⼀个⽤户，那么是直接连聊天服务器。
（2）如果是其它⾮实时的需求，例如通过聊天服务器向app发送⼀个更新通知，那么就在队列中处理。
7. 监控，采⽤了监控宝和云服务器提供的监控数据，能满⾜⽬前的需求了。
参考：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。