【转】高扩展性网站的50条原则

 

《高扩展性网站的50条原则》，利用一天半的时间快速浏览总结的电子书，对网站的建设有一个原则性的把握，书中提到的大部分原则现在已成为互联网行业的共识，但并不妨碍我们重新整理分类，从全局层面把控高扩展性网站的建设思路，文中的每一条尽管高度凝练，但都值得细细品味。完成于2015年6月11日11:02:19。

（一）化简方程

1. 不要过度设计：基于成本的考虑，只设计能满足要求的系统即可，过于理想化的设计不利于系统的维护与成本控制；
2. 设计时考虑扩展性：设计20倍的容量，实现3倍的容量，部署1.5倍的容量，即所谓的D-I-D方法；
3. 在设计复杂系统时将方案的设计、范围和实施一简再简，在精简过程中可以参考2-8原则，优先最主要，最核心的实现；
4. 减少页面的DNS查找：
5. 通过减少与合并等机制，尽可能减少页面上的对象，降低请求资源的次数；
6. 使用同一品牌的网络设备，减少不同品牌的网络设备间带来的扩展性问题；

总结：

（二）分布工作

1. 横向复制：复制服务或数据库来分散事务负载，X轴原则；
2. 纵向拆分：根据动词或名词，拆分服务和数据
3. 拆分相近的东西：利用某些主题的属性进行查分，如利用客户的ID、所在地等进行拆分；

总结：

（三）横向扩展设计

1. 设计横向扩展方案；
2. 采用经济型系统，包括服务器及其他硬件，节约成本；
3. 横向扩展数据中心：设计具有三个或更多实时数据中心的系统，分散数据，分散事务负载；
4. 利用云计算进行设计，面对突发的扩展，利用自建或第三方的云技术可以帮助快速环境准备；

总结：

（四）使用正确的工具

1. 合理选择数据存储：尤其是对于RDBMS的选择，看是否有事务要求，如果只是简单存储，考虑文件系统或缓存等；
2. 谨慎使用防火墙；
3. 利用监控工具收集并分析系统日志文件

总结：

（五）不要重复工作

1. 不要立即检查刚做过的工作，即不要立即读刚写入大数据，因为这种写出错的概率微乎其微；
2. 避免使用重定向，如果必须使用，优先考虑服务器配置；
3. 放松时序约束，数据的分布总会给状态带来短暂的不一致，强行约束时序会使系统处理缓慢；

总结:

（六）积极利用缓存

1. 大用户流程使用CDN；
2. 使用HTTP头中的Expires、Cache-Control、Last-Modified等过期设置，包括对Web服务器对应HTTP头信息的设置；
3. 缓存Ajax调用；
4. 应用页面缓存，在web服务器前加上页面静态内容缓存；
5. 应用缓存使用；
6. 在数据库和应用层之间加入对象缓存，如memcached；
7. 将对象缓存独立成单独的层为上层提供服务；

总结：

（七）从错误中吸取教训

1. 从偶尔错误事件及失败中总结学习；
2. 不要依靠QA发现错误，更多的从控制编程角度控制；
3. 没有回退共的设计是失败的设计；
4. 讨论失败并从中吸取教训；

总结：

（八）数据库原则

1. 在设计数据模型时，考虑实体间较复杂的关系，为将来的数据库分割或其他处理做好准备；
2. 使用类型正确的数据库锁，如隐式锁、显式锁、行锁、页锁、范围锁、表锁、数据库锁；
3. 不要使用多阶段提交协议处理存储或事务，因为其是阻断性提议，对数据库的锁定要求更强；
4. 避免使用select for update ,因为该语句查询到的行都会被锁住；
5. 不要使用select * 选择所有数据列，使用select或insert的时候都制定列名；

总结：

（九）容错设计与故障设计

1. 采用隔离故障的泳道，通过将服务拆分或将大数据量的表按属性划分进行隔离，减少隔离域之间的同步调用及数据共享；
2. 避免单点故障，采用master/master的模式，通过负载均衡器均衡跨服务的流量；
3. 避免系统串联，如果要串联，也要将单个系统和核心环节的系统设置成集群模式；
4. 对于有风险或共享的服务，需要创建一种结果做到启用或禁用（可通过配置文件、数据库、启动参数、同步命令、文件标记等方式）

总结：

（十）避免状态或分发状态

1. 避免状态：努力实现无状态，通过合理的设计选择；
2. 分发状态：尽量在浏览器端维护会话，保持在cookie中；
3. 分发状态：利用分布式缓存存放状态，通过缓存数据提高存取速度，需要考虑支持持久化的缓存服务选择或利用数据库进行持久化

总结：

（十一）异步通信和消息总线

1. 尽可能使用异步通信保证每个服务和层都是独立的，即使一定要用同步服务，需要设置服务超时时间；使用异步通讯的常见四种情况：（调用外部API或第三方方法；调用长时间运行的进程；调用容易出错和频繁更改的方法；调用无时间约束或业务连续性约束的系统或服务）；
2. 确保消息总线能够扩展：通过服务按不同类型或不同处理方式进行拆分；
3. 避免让消息总线过于拥挤，不要发布所有消息，减少低价值高成本的流程，对低价值/低成本和高价值/高成本的流量进行采样；

总结：

（十二）其他原则

1. 慎用第三方解决方案扩展；
2. 从成本角度合理使用存储，对于不同价值的数据采用不同的存储策略；
3. 删除数据库事务处理过程中的业务逻辑处理，让数据库只做数据事务处理方面的共走，与业务逻辑无相关；
4. 设计能够监控的应用，在设计阶段就要考虑监控，做到从业务的角度监控而不仅仅是CPU、内存、网络等纯技术监控；
5. 团队中的技术能力要能胜任对系统、组件、服务等相关能力的需要，做到自助可控；

总结：