比较全面 有不少不错的观点

       本文并没有什么特别的东西，但是都很实在，而且能很好的组织起来，也可以看为一个架构。
        何为架构，要有大局观，大局观就是提前预防掉那些通用的问题：高可用，工程化，伸缩性，扩展性。对应需要的能力：了解分布式的一些东西，了解项目的业务和流程和运维使之工程化，了解负载均衡，能够对业务的分割和代码的分层。

文中其他的一些观点我倒是很喜欢：
1 先成就他人，再成就自己
2 刚开始加入的时候不要急于证明自己，要先融入。
3 最好的奖励就是目标的达成，最大的惩罚就是目标没实现
4 技术是要解决问题，但是我们要关心的是解决问题的人。
5 学会妥协
6越激烈的争辩代表越关心这个问题

文中有些例子有点意思
1 wiki的实现中就是业务退一小步，技术进一大步。这个他们能够那么省钱的原因啊。
2 秒杀从根本上来讲并不是很难，首先是页面的静态化，开始秒杀的按钮通过js来实现，js不缓存，js尽量小。开始秒杀的时候使用可以秒杀的js。秒杀很少能达数据层，因为就那么几个能成功。主要的压力在应用服务器，但是用一个记数服务器，收到请求更新这个数字，大于数字的直接返回秒杀失败。所以大部分都会进入失败的逻辑，整个也很简单。只要业务服务器能抗住这些访问压力就基本ok了，如果业务服务器不够，可以直接在负载均衡那边随机失败一部分。
3 负载均衡的实现： 1 dns实现 2应用层实现，使用反向代理。3 网络层实现 ip负载均衡，通过网关来修改目标ip 4 数据链路层 改mac地址，如lvs。 负载均衡的策略主要有 轮询 随机 最少连接 hash。
4 一致性hash的时候，用多个虚拟节点对应一台实际的服务器，如150:1 这样会大大减少负载波动。