适用范围
针对中小型互联网公司，特别适用于手机App的后台架构，支撑5万日活，满足中小型公司需求
QPS， 如果是5万日活，使用集中在每天的4小时，每个用户大概产生100的请求，那么平均下来，我们系统大概应该支撑的请求为：50000 100 / (4 60 * 60) = 350 qps/s
业务数据 业务量，我们自己是新闻业务，可能会有其他的业务，比如游戏，商城等等，基本每天新增的业务数据都会在同一个量级， 每日10000， 另外跟用户相关的信息也是比较大的一块，比如用户的订阅等行为，一共5万的用户，保存相关信息可能大概需要100条的数据。
缓存大小 主要业务数据和用户相关的热点数据限时保存在缓存中， 大概需要5个G左右。
日志大小 用户日志和请求日志。 大概每天3个G左右
技术架构
基于阿里云服务搭建
负载均衡
前期可以单机运行，业务量上来之后集群，使用nginx进行负载均衡，也可以选择阿里云的收费SLB
CDN
用于保存静态文件，阿里云跟七牛云都可以。一些图片数据如用户头像等由前端直接上传到七牛云，将返回的地址再返回给数据库，图片等大型文件不再经过服务器处理。app的新版本也直接保存在七牛云，更新的时候直接从七牛云下载，减少客户端请求服务器的带宽，可以明显提高访问速度
分布式调用框架
可以直接选用dubbo，这个是使用最多应用范围最广的，遇到问题也能快速解决。springcloud目前国内用的较少，而且eureka2.0之后不再开源。也可以选择当当的dubboX
消息队列MQ
可选的有： ActiveMQ, 阿里云消息， robbitMQ, 各有好处， 但是考虑到运维的难度，推荐阿里云消息。
缓存
使用Redis
数据库
主要基于读写分离和主从复制考虑
搜索
建议ELK， 可以自动同步数据库，除了搜索引擎的功能外，还可以做日志搜索，监控系统
一些典型的业务场景说明
- 把业务底层做成SOA模块，通过分布式调用框架对外提供服务。
- 单独做一个小的系统来运行定时任务
- 热点数据放缓存，然后通过MQ来更新缓存
- 日志等数据有必要可以考虑上个Mongo