一、用户管理
二、消息推送
1. IOS
iOS 的消息推送机制面世之时是一种全新的解决方案（堪称平台中的平台），应用本身不能有常驻的后台进程，系统的开销少，内存使用更少，电量也更少（把更多的运算和资源开销放在云端，非设备端）。
- [Client App]注册消息推送；
- [Client App]跟[APNS Service]要deviceToken, Client App接收deviceToken；
- [Client App]将deviceToken发送给[Provider]Push服务端程序；
- 当Push服务端程序满足发送消息条件了，[Provider]向[APNS Service]发送消息；
- [APNS Service]将消息发送给[Client App].
2. Android
而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。
app的消息推送就需要在自己或者是第三方服务器与设备之间建立一条长连接，通过长连接进行推送（如上图流程所示）。如果说iOS推送是苹果服务器统一向设备内对应app的分发，那么Android就是app主服务器向设备对应app的推送，这一过程必须保持连接的稳定建立，并且需要app处于打开或保持进程的情况下才能完成推送。
三、存储云、图片云
互联网环境下，用户会上传多种类型的文件数据，比如微信发朋友圈时上传图片、微博发微博或评论时上传图片、视频，视频用户上传视频、淘宝卖家上传商品图片
- 数据量大：用户基数大，用户上传行为频繁，
- 文件体积小：大部分图片是几百KB到几MB，短视频播放时间也是在几分钟内。
- 访问有时效性：大部分文件是刚上传的时候访问最多，随着时间的推移访问量越来越小。
一般用存储云和图片云通常的实现都是“CDN + 小文件存储”。