【转】高扩展性网站的50条原则
![](https://images0.cnblogs.com/blog/718082/201506/111352540515648.jpg)
《高扩展性网站的50条原则》,利用一天半的时间快速浏览总结的电子书,对网站的建设有一个原则性的把握,书中提到的大部分原则现在已成为互联网行业的共识,但并不妨碍我们重新整理分类,从全局层面把控高扩展性网站的建设思路,文中的每一条尽管高度凝练,但都值得细细品味。完成于2015年6月11日11:02:19。
(一)化简方程
- 不要过度设计:基于成本的考虑,只设计能满足要求的系统即可,过于理想化的设计不利于系统的维护与成本控制;
- 设计时考虑扩展性:设计20倍的容量,实现3倍的容量,部署1.5倍的容量,即所谓的D-I-D方法;
- 在设计复杂系统时将方案的设计、范围和实施一简再简,在精简过程中可以参考2-8原则,优先最主要,最核心的实现;
- 减少页面的DNS查找:
- 通过减少与合并等机制,尽可能减少页面上的对象,降低请求资源的次数;
- 使用同一品牌的网络设备,减少不同品牌的网络设备间带来的扩展性问题;
![](https://images0.cnblogs.com/blog/718082/201506/111352548791762.png)
(二)分布工作
- 横向复制:复制服务或数据库来分散事务负载,X轴原则;
- 纵向拆分:根据动词或名词,拆分服务和数据
- 拆分相近的东西:利用某些主题的属性进行查分,如利用客户的ID、所在地等进行拆分;
总结:
![](https://images0.cnblogs.com/blog/718082/201506/111352563485746.png)
(三)横向扩展设计
- 设计横向扩展方案;
- 采用经济型系统,包括服务器及其他硬件,节约成本;
- 横向扩展数据中心:设计具有三个或更多实时数据中心的系统,分散数据,分散事务负载;
- 利用云计算进行设计,面对突发的扩展,利用自建或第三方的云技术可以帮助快速环境准备;
![](https://images0.cnblogs.com/blog/718082/201506/111352572381075.png)
(四)使用正确的工具
- 合理选择数据存储:尤其是对于RDBMS的选择,看是否有事务要求,如果只是简单存储,考虑文件系统或缓存等;
- 谨慎使用防火墙;
- 利用监控工具收集并分析系统日志文件
![](https://images0.cnblogs.com/blog/718082/201506/111352580987945.png)
(五)不要重复工作
- 不要立即检查刚做过的工作,即不要立即读刚写入大数据,因为这种写出错的概率微乎其微;
- 避免使用重定向,如果必须使用,优先考虑服务器配置;
- 放松时序约束,数据的分布总会给状态带来短暂的不一致,强行约束时序会使系统处理缓慢;
![](https://images0.cnblogs.com/blog/718082/201506/111352588011330.png)
(六)积极利用缓存
- 大用户流程使用CDN;
- 使用HTTP头中的Expires、Cache-Control、Last-Modified等过期设置,包括对Web服务器对应HTTP头信息的设置;
- 缓存Ajax调用;
- 应用页面缓存,在web服务器前加上页面静态内容缓存;
- 应用缓存使用;
- 在数据库和应用层之间加入对象缓存,如memcached;
- 将对象缓存独立成单独的层为上层提供服务;
![](https://images0.cnblogs.com/blog/718082/201506/111352593799986.png)
(七)从错误中吸取教训
- 从偶尔错误事件及失败中总结学习;
- 不要依靠QA发现错误,更多的从控制编程角度控制;
- 没有回退共的设计是失败的设计;
- 讨论失败并从中吸取教训;
![](https://images0.cnblogs.com/blog/718082/201506/111353002695315.png)
(八)数据库原则
- 在设计数据模型时,考虑实体间较复杂的关系,为将来的数据库分割或其他处理做好准备;
- 使用类型正确的数据库锁,如隐式锁、显式锁、行锁、页锁、范围锁、表锁、数据库锁;
- 不要使用多阶段提交协议处理存储或事务,因为其是阻断性提议,对数据库的锁定要求更强;
- 避免使用select for update ,因为该语句查询到的行都会被锁住;
- 不要使用select * 选择所有数据列,使用select或insert的时候都制定列名;
![](https://images0.cnblogs.com/blog/718082/201506/111353011293185.png)
(九)容错设计与故障设计
- 采用隔离故障的泳道,通过将服务拆分或将大数据量的表按属性划分进行隔离,减少隔离域之间的同步调用及数据共享;
- 避免单点故障,采用master/master的模式,通过负载均衡器均衡跨服务的流量;
- 避免系统串联,如果要串联,也要将单个系统和核心环节的系统设置成集群模式;
- 对于有风险或共享的服务,需要创建一种结果做到启用或禁用(可通过配置文件、数据库、启动参数、同步命令、文件标记等方式)
![](https://images0.cnblogs.com/blog/718082/201506/111353017855286.png)
(十)避免状态或分发状态
- 避免状态:努力实现无状态,通过合理的设计选择;
- 分发状态:尽量在浏览器端维护会话,保持在cookie中;
- 分发状态:利用分布式缓存存放状态,通过缓存数据提高存取速度,需要考虑支持持久化的缓存服务选择或利用数据库进行持久化
总结:
![](https://images0.cnblogs.com/blog/718082/201506/111353025046198.png)
(十一)异步通信和消息总线
- 尽可能使用异步通信保证每个服务和层都是独立的,即使一定要用同步服务,需要设置服务超时时间;使用异步通讯的常见四种情况:(调用外部API或第三方方法;调用长时间运行的进程;调用容易出错和频繁更改的方法;调用无时间约束或业务连续性约束的系统或服务);
- 确保消息总线能够扩展:通过服务按不同类型或不同处理方式进行拆分;
- 避免让消息总线过于拥挤,不要发布所有消息,减少低价值高成本的流程,对低价值/低成本和高价值/高成本的流量进行采样;
![](https://images0.cnblogs.com/blog/718082/201506/111353031911056.png)
(十二)其他原则
- 慎用第三方解决方案扩展;
- 从成本角度合理使用存储,对于不同价值的数据采用不同的存储策略;
- 删除数据库事务处理过程中的业务逻辑处理,让数据库只做数据事务处理方面的共走,与业务逻辑无相关;
- 设计能够监控的应用,在设计阶段就要考虑监控,做到从业务的角度监控而不仅仅是CPU、内存、网络等纯技术监控;
- 团队中的技术能力要能胜任对系统、组件、服务等相关能力的需要,做到自助可控;
![](https://images0.cnblogs.com/blog/718082/201506/111353038328927.png)