【译】可伸缩性最佳实践

这篇文章中总结了一些构建可伸缩性系统的最佳实践,总结的不错,于是翻译了下,原文在此:http://akfpartners.com/techblog/2009/08/11/scalability-best-practices/,翻译内容如下:

下面是我们认为的一些可伸缩性的最佳实践:
1、异步;尽可能的使用异步,同步调用会导致两个服务的可用性绑在一起,意味着一个服务出问题或变慢,另一个也会受到影响,这点也是eBay一直强调的;

2、泳道设计;错误隔离机制,避免一个失败影响全局,这种机制也有助于错误查找和代码替换;

3、缓存;在所有层次均使用缓存,例如数据、页面、页面片段等;

4、监测;从用户角度来看系统的性能。这包括从外部网络来对系统进行性能的监测,以及内部的系统间交互次数以及时间的监测;

5、数据复制;一方面是为了容灾,另一方面是为了提供多个用于读的数据库,降低写库的压力;

6、拆分;包括了应用的拆分以及数据库的拆分;

7、尽量少的使用数据库特性;尽可能的把数据库仅作为一个在线存储的功能而使用,不要把业务逻辑放在数据库里,否则将来会非常难扩展;

8、缓慢发布;发布时应缓慢发布,以保证新版本是正常的,避免由于某个压力测试时没测到的点,导致全站出问题;

9、压力以及性能测试;在发布前测试性能,尽管这不一定能发现全部问题,因此在发布前仍然要做好回滚的方案;

10、容量规划;提前判断系统能支撑多大的量,并做好扩容计划;

11、回滚;每次都要做好回滚的准备;

12、根源分析;确认有办法找到线上问题的根源所在,从而能够真正的解决问题;

13、从一开始就要注重质量;质量不能仅靠测试来保证,必须从设计阶段开始就去保证。

译注:
以上说的这十三点可谓是构建可伸缩系统的金玉良言,但可惜缺乏了实例引导,没有经验的同学估计会很难看明白为什么一定要这样做,如果有些实例来说明的话,就更帅了!

posted on 2009-08-19 14:41 BlueDavy 阅读(6904) 评论(4)  编辑  收藏 所属分类: Internet

评论

# re: 【译】可伸缩性最佳实践 2009-08-19 22:59 zhong

看需求,如果完全按这13条,系统复杂度太高,也容易出问题  回复  更多评论   

# re: 【译】可伸缩性最佳实践 2009-08-19 23:43 BlueDavy

@zhong
所以还有一点也是设计原则,就是简单,其实上面这些做的并不就一定会很复杂。  回复  更多评论   

# re: 【译】可伸缩性最佳实践 2009-08-22 13:57 Oasis Feng

同步也并不总是会导致性能牵连,这个的前提是在线程中做同步。协程是个很好的反例,它提倡将一切业务逻辑都推向同步,而不是异步。这样业务流程的编写会变得异常简洁和优雅。(异步编程总是那么让人觉得不舒服)  回复  更多评论   

# re: 【译】可伸缩性最佳实践[未登录] 2009-10-20 19:57 郑晖

这的确是篇好文章,这里指出一个小小的翻译疏忽:

第七点:尽量少的使用数据库特性(Use Few RDBMS Features)
应为“关系数据库”(RDBMS),而非一般的database。
事实上,原文的一个链接:
http://akfpartners.com/techblog/2009/06/17/newsletter-the-future-of-relational-databases/
主要是对关系数据库的可伸缩性提出了质疑。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2009年8月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
303112345

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜