App后台的技术实现和一般的Web后台是有区别的。
3.1 用户验证方案
登录过程中怎样才能最大程度地避免泄漏用户的密码的可能呢？
用户登录后，App后台怎么去验证和维护用户的登录状态呢？
使用HTTPS协议：避免信息的泄漏，最基本的方案是所有涉及安全性的API请求都必须使用HTTPS协议。
基本的用户登录方案：传统Web网站使用Cookie+Session保持用户的登录状态，而App后台怎么避免每次验证用户身份都需要传输用户名和密码呢？
注意：这个方案并不是十分安全，身份验证依赖token字符串。如果用户泄漏了URL，那么token也泄漏了。
3.2 App通信安全
URL签名：不在网络上传输token的方案。
注意：上述没有过期时间，改进方法是在传递的参数中增加时间戳，但需要同步前后端的时间。
API请求使用了HTTPS协议也不能保证绝对安全，万一基于HTTPS的API请求被黑客截获，使用URL签名会有下面3个问题：
- 当用户登录后，App后台返回给App的信息（包括token等个人信息）没加密，有被截获的风险。
- URL签名只能保护token值不泄漏，但没法保护其他敏感数据，例如，当用户更新自己的个人信息时，所有的信息在传输过程中应该被加密。
- URL被黑客截获后还是能在一段时间内调用（假设App后台认为有效的间隔时间是30s）。
AES对称加密：同一个密钥可以同时用作信息的加密和解密，称为对称加密，也称为单密钥加密。
URL个人信息，以明文返回，存在被黑客截取的风险。可以下面的方法解决，使用时间戳生成HTTP请求头Token-Param的22位长度作为密钥secretKey。
敏感数据：用同样方法。
注意：以上的Token-Param和Token-Data都是笔者自定义的HTTP请求头。
更进一步的通信安全：如果App被黑客反编译了。
3.3 短信服务
手机注册，怎样才能确保短信服务的稳定性？
App后台发送短信是个很特殊的功能。
- 发送短信的功能没有任何开源软件可以实现。
- 发送短信只能依靠短信平台。
- 短信的到达率和延时是开发人员无法控制的。
选择短信平台：笔者用UCloud等。
建立可靠的短信服务：笔者推荐最可靠的做法是必须要接入最少两个短信平台。
3.4 处理表情的一些技巧
表情在MySQL的存储：笔者用二进制存储
当文字中夹带表情的处理：
3.5 高效更新数据
经常需要通过API获取最新的数据。推拉结合和数据增量更新就是实现高效获取数据的关键。
内容的推拉：推送和轮询结合。
数据增量更新策略：把相关的数据存储在App本地，在数据库中，每条数据都必须有update_time这个值，记录数据最后更新的时间，当App从服务器获取了一次数据后，记录下所获取的最新数据的update_time，当再次获取数据就只需要获取update_time到访问服务器这刻为止所更新的数据即可。
3.6 图片处理
数据库保存原图的路径。尺寸大小使用动态的策略。
整个架构中的图片最少有两层缓存。本地的和服务器的。
推荐七牛云存储
3.7 视频处理
FFmpeg：可以用来记录、转换数字音频、视频，并能将其转化为流的开源软件。
后台调用FFmpeg的功能：创业性公司可充分运用云服务，例如七牛
3.8 获取APK和IPA文件里的资源
Android和iOS的安装文件
3.9 文件系统
文件云存储服务：笔者认为创业公司的架构原则是“尽量使用成熟可靠的云服务和开源软件，自身只专注于业务逻辑”。
架设文件系统：FastDFS是一个开源的轻量级分布式文件系统，其对文件管理功能包括：文件存储、文件同步、文件访问等，解决了大容量存储和负载均衡的问题。
图片水印，缩放和裁剪：笔者推荐使用GraphicsMagick
CDN：使图片、音频、视频等静态文件下载速度更快，用户体验更好。
3.10 ELK日志分析平台
为了解决多台服务器日志查看不方便和日志中的异常，后台可以引入ELK这个分布式的日志收集和分析系统。
3.11 Docker构建一致的开发环境
由开发者在个人电脑上部署新的功能后独立测试，测试完毕后在测试服务器中部署新功能，再由公司内部的测试人员在测试服务器上测试，在测试服务器测试完毕后再在生产服务器部署新功能，正式发布该功能。
搭建一致的开发环境：镜像、容器、仓库
693
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
