最近挖坟了
https://bbs.byr.cn/#!article/Python/1859https://bbs.byr.cn/#!article/Python/6763于是心头一热，顺手花了2天时间撸了一个图集小站，目前前端的异步加载样式还有点问题，欢迎来看?
http://51juchang.com/site/index/规规矩矩按照套路，先分享下设计框架
基础组件：
HTTP服务，部署BAE一台机器
Nginx
python-Flask框架 + supervisor守护
MySQL、redis
前端bootstrap+jquery
微信订阅号
产品设计：
1.列表页支持无限刷新，最好有访问历史，以及去重。
实际上Web不像app，难以拿到user_id或device_id等用户标识，除非主动以微信用户ID为标识，但不全。
鉴于样本量已经大了，索性先随机混排。（应该有办法，求教）
2.详情页除了披露图集全量数据，下发相关推荐位=列表页，用户不必每次返回列表页再下翻。
模块设计：
爬取模块 + API模块 + 订阅号
定时脚本每天爬取图片，但没有申请图片cdn，偷懒直接存了源站图片URI，落地到MySQL。
（细节：通过nginx反向代理302到源站图片地址。注意通过referer的处理尽可能避免403等盗链。。我是不是太穷太坏了）
API模块提供3个接口：
1. 列表页主页面框架，用于渲染前端样式
2. 列表页图集数据接口，用于异步拉数据
3. 详情页页面，用于披露图集详细数据
（细节：cache+db，用redis缓存db数据，有过期时间；访问次数记录redis，粗略以send为准，没有靠前端埋点触发show事件）
订阅号完全是多年尘封的号，简单修改了下，发现微信对权限更加严格，订阅号已经不支持button跳转url了=。=
想到几点待改善：
能够有办法标识用户身份，可以做访问历史，去重，收藏等
考虑数据变化可能性小，可全量cache到redis，或者设置较长过期时间。
详情页偷懒直接渲染所有图片，可能导致加载图片时间较长，后面可做成异步部分加载。
增加搜索，基于elasticsearch倒排匹配，后面有空加吧。
前端异步加载样式有点问题，不会前端也没搞好。
整个设计和实现比较简单，很弱的单机器实例，抗不了多少qps，理想是基础组件拆分部署，db读写分离，db零穿透，nginx负载均衡，落地图片CDN。。。（所有这些都需要机器，需要money啊。。突然感觉能操作公司成百上千机器好富有=。=）
--
修改:dashewan FROM 113.47.162.*
FROM 113.47.162.*