web运维的可扩展性考虑
2010-08-17 12:14
92 查看
1.优化
* 不要过度优化。这可能会从你的重要函数中拿走一些宝贵的资源。
*不要过早考虑扩展。考虑你系统当前面临的或可能支持的 10 倍负载,在大多数情况下会影响生产效率。在无法满足 2 个或 3 个服务前,关系数据库还是不错的选择。
* 为了水平扩展性而优化和重构前,先优化单个节点的性能。
2.工具
*
工具是熟练的技师造的。工具不能使技师变得熟练。
*
工具本身不能解决问题,但正确的使用它可以解决问题。
*
想要短期内熟练掌握一种工具用来生产,在遇到不是很棘手的问题时查询这些工具用户手册。
3.Cookies
*
尽量使用 cookies 来保存数据。
*
如果你担心损害,给它们签名。
*
如果你担心用户看见它们的内部,给它们加密。
*
和构建过多的服务端相比,使用用户的浏览器作为数据存储的复制节点还是比较廉价的。
4.数据存储
* NoSQL 不能解决所有问题。
*
关系数据库也不能解决所有问题。
* 其他的一切也不能解决所有问题。
*
找到需求,了解原因,然后找解决方案。
5.自动化
*
当你发现你做某件同样的事超过 2 次,写脚本让它自动执行。
*
当用户在监控系统发现前报告了错误,写个更好的监控工具。
6.版本控制
*
版本控制同样重要。
*
提供审计跟踪来帮助了解之前发生了什么。人不可能记住所有事情。当很难解决产品问题时,这将是一个很好的查询问题的地方。
7.网络
*
考虑包而不是字节来节省负载时间。
*
压缩一个 400 字节的 CSS 文件是没必要的,因为最小的 IP 数据包的大小是 1300 字节左右(如果数据小于这个大小,余下的包会被空字节填充)。
*
事实上,压缩和解压缩会消耗服务端和客户端的 CPU 资源。
*
不要有在 HTML 中嵌入 CSS 文件来节省一些额外包的想法。
8.缓存
*
缓存所有静态数据
*
给对象添加随机数或字符来强制加载该对象。
o
如请求“ /images/myphoto.12345.jpg ”而不是“ /images/myphoto.jpg ”。
o
去掉随机 ID ,使用如 htaccess 重写规则。
*
尽可能使用 CDNs ,但确保你切换到 CDN 之前,了解你页面的所有对象。无意义的转发可能会损失掉以前很好的加载时间。
9.人
*
当你为运维团队招人时,千万不要雇佣连他 / 她遇到的一个生产问题都记不住的人。你要识别出那些遇到问题并能解决问题的人。
*
允许他们在生产中冒险,观察他们如何完成它。冒险是适应新思想的一部分。让他们失败并帮助他们知道怎样提高。
10.系统
*
了解你的系统的基线。系统当前统计的一个实例或快照不能满足系统的所有当前的状态。
*
使用工具每隔一段时间取得数据会帮助你了解这些信息。
11.Moderation
*
Moderate the tools and process you use
*
Moderate the moderation
本文摘自:http://www.royans.net/arch/thoughts-on-scalable-web-operations/
* 不要过度优化。这可能会从你的重要函数中拿走一些宝贵的资源。
*不要过早考虑扩展。考虑你系统当前面临的或可能支持的 10 倍负载,在大多数情况下会影响生产效率。在无法满足 2 个或 3 个服务前,关系数据库还是不错的选择。
* 为了水平扩展性而优化和重构前,先优化单个节点的性能。
2.工具
*
工具是熟练的技师造的。工具不能使技师变得熟练。
*
工具本身不能解决问题,但正确的使用它可以解决问题。
*
想要短期内熟练掌握一种工具用来生产,在遇到不是很棘手的问题时查询这些工具用户手册。
3.Cookies
*
尽量使用 cookies 来保存数据。
*
如果你担心损害,给它们签名。
*
如果你担心用户看见它们的内部,给它们加密。
*
和构建过多的服务端相比,使用用户的浏览器作为数据存储的复制节点还是比较廉价的。
4.数据存储
* NoSQL 不能解决所有问题。
*
关系数据库也不能解决所有问题。
* 其他的一切也不能解决所有问题。
*
找到需求,了解原因,然后找解决方案。
5.自动化
*
当你发现你做某件同样的事超过 2 次,写脚本让它自动执行。
*
当用户在监控系统发现前报告了错误,写个更好的监控工具。
6.版本控制
*
版本控制同样重要。
*
提供审计跟踪来帮助了解之前发生了什么。人不可能记住所有事情。当很难解决产品问题时,这将是一个很好的查询问题的地方。
7.网络
*
考虑包而不是字节来节省负载时间。
*
压缩一个 400 字节的 CSS 文件是没必要的,因为最小的 IP 数据包的大小是 1300 字节左右(如果数据小于这个大小,余下的包会被空字节填充)。
*
事实上,压缩和解压缩会消耗服务端和客户端的 CPU 资源。
*
不要有在 HTML 中嵌入 CSS 文件来节省一些额外包的想法。
8.缓存
*
缓存所有静态数据
*
给对象添加随机数或字符来强制加载该对象。
o
如请求“ /images/myphoto.12345.jpg ”而不是“ /images/myphoto.jpg ”。
o
去掉随机 ID ,使用如 htaccess 重写规则。
*
尽可能使用 CDNs ,但确保你切换到 CDN 之前,了解你页面的所有对象。无意义的转发可能会损失掉以前很好的加载时间。
9.人
*
当你为运维团队招人时,千万不要雇佣连他 / 她遇到的一个生产问题都记不住的人。你要识别出那些遇到问题并能解决问题的人。
*
允许他们在生产中冒险,观察他们如何完成它。冒险是适应新思想的一部分。让他们失败并帮助他们知道怎样提高。
10.系统
*
了解你的系统的基线。系统当前统计的一个实例或快照不能满足系统的所有当前的状态。
*
使用工具每隔一段时间取得数据会帮助你了解这些信息。
11.Moderation
*
Moderate the tools and process you use
*
Moderate the moderation
本文摘自:http://www.royans.net/arch/thoughts-on-scalable-web-operations/
相关文章推荐
- CheungSSH国产自动化运维工具开源Web界面
- Linux运维学习笔记之十八:WEB架构深度优化之PHP
- 架构设计从这5点考虑,能帮后期运维很大忙!
- 从 ASPX 页面进行 Web 服务调用时的性能考虑
- distri.lua的web运维工具
- 让 Nginx 支持 WAF 防护功能web防火墙 - 沧海一粟 - Web系统架构与服务器运维,php开发
- Velocity China 2011大会(Web性能和运维)PPT免费下载全!
- zabbix 2.2.1 触发web前端报警,唱<<离歌>>,用于提醒机房运维人员
- 工作那点事儿——Linux Web服务器网站运维常用分析命令
- Git WebHook:用于迅速搭建并使用 WebHook 进行自动化部署和运维系统( Python)
- web目录下不应该存在多余的程序(安全考虑)
- 记录一个关于互联网、网页设计、Web开发、服务器运维优化、项目管理、网站运营、网站安全的网站
- 麦子学院IT资源,web前端,UI设计,Java全套,IOS,android,产品经理,pyhton,网络安全,运维
- SAP接口设计的扩展性考虑
- Java EE集群技术初探——第五部分(Web层集群实现技术中尚需要考虑的问题)
- 基于WEB信息管理系统测试时应考虑的因素有哪些
- [运维]ESXI Web Client
- web前端知识杂记(1浮动占据居中空间)(2清楚内部的浮动效果) (3考虑布局) (4letter-spacing导致textalign不居中用text-indent解决)
- 工作流实施中FlowPortal.net对于表单设计易用性和可扩展性的考虑
- Web开发要考虑用户禁用浏览器的JS吗?