1.优化
不要过度优化。这可能会从你的重要函数中拿走一些宝贵的资源。
不要过早考虑扩展。考虑你系统当前面临的或可能支持的 10 倍负载,在大多数情况下会影响生产效率。在无法满足 2 个或 3 个服务前,关系数据库还是不错的选择。
为了水平扩展性而优化和重构前,先优化单个节点的性能。
2.工具
工具是熟练的技师造的。工具不能使技师变得熟练。
工具本身不能解决问题,但正确的使用它可以解决问题。
想要短期内熟练掌握一种工具用来生产,在遇到不是很棘手的问题时查询这些工具用户手册。
3.Cookies
尽量使用 cookies 来保存数据。
如果你担心损害,给它们签名。
如果你担心用户看见它们的内部,给它们加密。
和构建过多的服务端相比,使用用户的浏览器作为数据存储的复制节点还是比较廉价的。
4.数据存储
NoSQL 不能解决所有问题。
关系数据库也不能解决所有问题。
其他的一切也不能解决所有问题。
找到需求,了解原因,然后找解决方案。
5.自动化
当你发现你做某件同样的事超过 2 次,写脚本让它自动执行。
当用户在监控系统发现前报告了错误,写个更好的监控工具。
6.版本控制
版本控制同样重要。
提供审计跟踪来帮助了解之前发生了什么。人不可能记住所有事情。当很难解决产品问题时,这将是一个很好的查询问题的地方。
7.网络
考虑包而不是字节来节省负载时间。
压缩一个 400 字节的 CSS 文件是没必要的,因为最小的 IP 数据包的大小是 1300 字节左右(如果数据小于这个大小,余下的包会被空字节填充)。
事实上,压缩和解压缩会消耗服务端和客户端的 CPU 资源。
不要有在 HTML 中嵌入 CSS 文件来节省一些额外包的想法。
8.缓存
缓存所有静态数据
给对象添加随机数或字符来强制加载该对象。
如请求“ /images/myphoto.12345.jpg ”而不是“ /images/myphoto.jpg ”。
去掉随机 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/