目前我对Web开发的认识
浏览数：28 /
时间：2015年06月09日
前端
- 使用mvvm框架，每个视图维护自己的数据模型，更专注于视图模型及状态，在框架的帮助下规范视图与后端的交互及减轻工作量
- 解耦前后端开发
我的选择是avalon.js
后端
业务入口
- 任意语言的web开发框架都可以
- 主要任务是把HTTPRequest转换为RequestContext
- 对RequestContext做基本的验证，如有效性、入口权限等
- 按照HTTP接口约定，调用相应的服务并返回Response
服务
服务要SOA化
- 爬虫服务使用Python，开发简单、相关类库丰富、可跨平台部署
- 搜索服务使用Java，目前在这块还没有实践经验，看好ElasticSearch
- 图片服务，任意带丰富图片处理类库的语言都可以
- 接口约定应该允许客户端用参数指定返回的图片的长宽
- 接口需要直接对外公开
- 邮件服务
数据库
方案一
- 关系数据库选择postgresql
- 应对复杂查询的能力比mysql强
- 对json数据有很好的支持，可以省掉用来保存无结构key-value数据的nosql数据库
- 对地理数据有很好的支持
- 自带优秀的读scalability
- 写scalability有postgresql-xl
- pg vs mysql
- redis做缓存
方案二
- 任意对事务支持良好、可多线程访问的关系数据库
- 需要考虑读、写scalability
- redis用作nosql，主要处理key-value数据
- redis用作缓存
高并发读不是什么大问题，缓存+数据库集群能很好的解决。难点在于用数据库集群应付高并发写的同时需要保证ACID。
反向代理
毫无疑问是nginx
运维
运维也是开发的需求方
目标
- 掌握资源使用情况
- 限制应用可接触的资源
- 资源总量能迅速扩张
- 任何操作都能回滚（time machine机制）
- 任何操作都有历史记录
- 任何数据和操作都可视化
策略
- 限制应用的访问权限
- 自身所在目录
- 以环境变量指定的目录，如APP_LOG_HOME、APP_DATA_HOME、APP_UPLOAD_HOME
- 有必要的话用特定账户运行该应用
应用日志格式须由运维指定，既要人类可读，又要方便代码解析
日志记录应该是非阻塞的
监控应用进程占用的CPU、IO
我的选择是avalon.js
业务入口
- 任意语言的web开发框架都可以
- 主要任务是把HTTPRequest转换为RequestContext
- 对RequestContext做基本的验证，如有效性、入口权限等
- 按照HTTP接口约定，调用相应的服务并返回Response
服务
服务要SOA化
- 爬虫服务使用Python，开发简单、相关类库丰富、可跨平台部署
- 搜索服务使用Java，目前在这块还没有实践经验，看好ElasticSearch
- 图片服务，任意带丰富图片处理类库的语言都可以
- 接口约定应该允许客户端用参数指定返回的图片的长宽
- 接口需要直接对外公开
- 邮件服务
数据库
方案一
- 关系数据库选择postgresql
- 应对复杂查询的能力比mysql强
- 对json数据有很好的支持，可以省掉用来保存无结构key-value数据的nosql数据库
- 对地理数据有很好的支持
- 自带优秀的读scalability
- 写scalability有postgresql-xl
- pg vs mysql
- redis做缓存
方案二
- 任意对事务支持良好、可多线程访问的关系数据库
- 需要考虑读、写scalability
- redis用作nosql，主要处理key-value数据
- redis用作缓存
高并发读不是什么大问题，缓存+数据库集群能很好的解决。难点在于用数据库集群应付高并发写的同时需要保证ACID。
反向代理
毫无疑问是nginx
运维
运维也是开发的需求方
目标
- 掌握资源使用情况
- 限制应用可接触的资源
- 资源总量能迅速扩张
- 任何操作都能回滚（time machine机制）
- 任何操作都有历史记录
- 任何数据和操作都可视化
策略
- 限制应用的访问权限
- 自身所在目录
- 以环境变量指定的目录，如APP_LOG_HOME、APP_DATA_HOME、APP_UPLOAD_HOME
- 有必要的话用特定账户运行该应用
应用日志格式须由运维指定，既要人类可读，又要方便代码解析
日志记录应该是非阻塞的
监控应用进程占用的CPU、IO
- 应对复杂查询的能力比mysql强
- 对json数据有很好的支持，可以省掉用来保存无结构key-value数据的nosql数据库
- 对地理数据有很好的支持
- 自带优秀的读scalability
- 写scalability有postgresql-xl
- pg vs mysql
- 需要考虑读、写scalability
高并发读不是什么大问题，缓存+数据库集群能很好的解决。难点在于用数据库集群应付高并发写的同时需要保证ACID。
毫无疑问是nginx
运维
运维也是开发的需求方
目标
- 掌握资源使用情况
- 限制应用可接触的资源
- 资源总量能迅速扩张
- 任何操作都能回滚（time machine机制）
- 任何操作都有历史记录
- 任何数据和操作都可视化
策略
- 限制应用的访问权限
- 自身所在目录
- 以环境变量指定的目录，如APP_LOG_HOME、APP_DATA_HOME、APP_UPLOAD_HOME
- 有必要的话用特定账户运行该应用
应用日志格式须由运维指定，既要人类可读，又要方便代码解析
日志记录应该是非阻塞的
监控应用进程占用的CPU、IO
运维也是开发的需求方
- 自身所在目录
- 以环境变量指定的目录，如APP_LOG_HOME、APP_DATA_HOME、APP_UPLOAD_HOME
- 有必要的话用特定账户运行该应用
应用日志格式须由运维指定，既要人类可读，又要方便代码解析
日志记录应该是非阻塞的
监控应用进程占用的CPU、IO
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
