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/ 

你可能感兴趣的:(Web,.net,css,NoSQL,脚本)