前端

使用mvvm框架，每个视图维护自己的数据模型，更专注于视图模型及状态，在框架的帮助下规范视图与后端的交互及减轻工作量

我的选择是avalon.js

解耦前后端开发自有资源独立管理，向后端开放资源使用的接口拿到后端静态资源标识后，按照约定独立运算获得资源URL，不需要后端参与

后端

业务入口

任意语言的web开发框架都可以主要任务是把HTTPRequest转换为RequestContext对RequestContext做基本的验证，如有效性、入口权限等按照HTTP接口约定，调用相应的服务并返回Response

服务

爬虫服务使用Python，开发简单、相关类库丰富、可跨平台部署 复杂程度低的爬虫用pyquery、requests就可以，复杂程度高的上scrapy搜索服务使用Java，目前在这块还没有实践经验，看好ElasticSearch图片服务，任意带丰富图片处理类库的语言都可以 接口约定应该允许客户端用参数指定返回的图片的长宽接口需要直接对外公开邮件服务

业务入口及服务都应该做到可容易水平扩展，甚至分布式

数据库

方案一

关系数据库选择postgresql 应对复杂查询的能力比mysql强对json数据有很好的支持，可以省掉用来保存无结构key-value数据的nosql数据库对地理数据有很好的支持自带优秀的读scalability写scalability有postgresql-xlpg vs mysqlredis做缓存

方案二

任意对事务支持良好、可多线程访问的关系数据库 需要考虑读、写scalabilityredis用作nosql，主要处理key-value数据redis用作缓存

高并发读不是什么大问题，缓存+数据库集群能很好的解决。难点在于用数据库集群应付高并发写的同时需要保证ACID。

反向代理

毫无疑问是nginx

运维

运维也是重要的需求方

目标

掌握资源使用情况限制应用可接触的资源资源总量能迅速扩张任何操作都能回滚（time machine机制）任何操作都有历史记录任何数据和操作都可视化

策略

限制应用的访问权限 自身所在目录以环境变量指定的目录，如APP_LOG_HOME、APP_DATA_HOME、APP_UPLOAD_HOME有必要的话用特定账户运行该应用应用日志格式须由运维指定，既要人类可读，又要方便代码解析

日志记录应该是非阻塞的

监控应用进程占用的系统资源

转载于:https://www.cnblogs.com/inside/p/4414821.html