Hunter的大杂烩 技术学习笔记

 比较common sense的东西，条理不是很清晰，架构上的、产品上的、技术细节的混在一起了

===================

from:http://www.okdev.cn/?p=90 

这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。
这里讨论一下大型网站需要注意和考虑的问题
1、海量数据的处理
众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。

(more…)

在上篇《大规模互联网服务部署》中，提到的所谓“优雅降级”，在tc内部称为柔性，简单意义上就是在系统过载的时候，通过业务体验降级（减少提供的功能），限制并发使用用户数量等方式，将有限的资源提供给基础业务，来满足用户基本需求；

一般做传统软件业都是无法接受这种结果的，但是在互联网业里面，似乎是家常便饭，无论是ebay还是amazon，都认为是availability是最重要的，而Percona Performance Conference中Morgan对Availability的解释更加简单：

(more…)

摘自《程序员》2008.8

声明：本文所有权属于《程序员》杂志，如本转摘有任何产权方面的问题，请及时联系本人，谢谢！

============================================= 

大规模服务设计部署经验谈(下)

文／J a m e s H a m_lto n译／赖翥翔

运营和功能计划

    要高效地运营服务，关键在于让构建的系统有效地消除运营团队的绝
大部分管理交互。这样做的目标，是让一个高度可靠的24 x 7小时运行的
服务，由一个8 x 5小时工作的运营团队就足以维护起来。
    不过世事难料，一组或者多组系统救火不成，无法恢复上线的事情是
时有发生的。在熟知这些可能性的情况下，实现把损坏的系统标为当机这
个过程的自动化。依赖运营团队手动更新SQL表或者使用特别的技术移
动数据，都会招致灾难。与故障交战正酣时，往往错误也容易迭出。先预
估运营团队需要采取的补救措施，然后预先编写和测试这些过程。一般来
说，开发团队必须将紧急恢复措施自动化，而且他们必须对之进行测试。
显然，百密一疏，并非所有故障都能预估到，但通常一小组恢复措施就可
以用来恢复多种类型的故障。从根本上说，要构建并测试可以根据灾难的
范围和性质以不同方式使用及结合的“恢复内核”。
    恢复脚本应当在生产环境中进行测试。这里有一条普适规则，即如果
没经过频繁测试，什么程序都无法正常工作，因此不要实现团队没勇气使
用的任何东西。如果在生活环境中测试风险过高，那么脚本就没有达到能
在紧急情况下使用的标准，或者说在紧急情况下不安全。这里很关键的一
点是，灾难总是可能发生的，由无法按预期结果运行的恢复步骤所导致的
小问题酿成大灾难的例子是屡见不鲜的。要预见到这样的事件，设计出自
动化措施，让服务回复正常状态，而不至于丢失更多数据或损耗更多正常
运行时间。
    ◆让开发团队承担责任。Amazon也许是沿着这条道路贯彻得最坚定最矢
志不渝的公司了——他们的口号是“你创建就该你管”。这样的立场也许要比
我们会选择的更坚定一些，但这显然是一个正确的大方向。如果不得不频繁在
深更半夜给开发团队打电话，那么你就得做出一套自动化方案。如果需要频繁
给运营团队打电话，那么通常的反应就是要增加运营团队的人手。

(more…)

from: http://www.blogjava.net/Jack2007/archive/2008/04/27/196633.html

一，不要过设计：never over design

这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最快最有效的响应。。

ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构
web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的
二，web架构生命周期：web architecture‘s life cycle
既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你

设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长

google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的

(more…)