web运维的可扩展性考虑 zz

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/