架构师接龙是《程序员》杂志最近推出的一个活动，活动方式为：每期一个提问嘉宾，一个回答嘉宾，并由回答嘉宾提出新的问题给下期的架构师，形成接龙，之前第一期是支付宝的冯大辉提问，腾讯的研发总监王速瑜回答，我参与的是第二期，这期会登在《程序员》0909期上，内容转帖如下，原帖为程序员官方上的：
http://www.programmer.com.cn/727/，呵呵，都只是个人的片面理解做出的回答，也欢迎大家在此帖中继续讨论，:)
王速瑜：数据集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？
林昊：一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在3ms内完成）来决定。当达到性能瓶颈时，通常需要进行数据的拆分或备份等策略，在这个过程中最需要考虑的，就是对应用的影响程度，因此通常会需要一个强大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构并存、数据冗余和同步等问题。
王速瑜：数据备份问题：对于大容量的数据备份，技术上如何做到不影响正常的服务？如何合理制定冷备、热备的实施策略、方式、时间段？在数据损坏、主服务器硬件损坏等故障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？
林昊：对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知实现数据备份，或基于高端数据库的特性（例如Oracle的Standby）。对于冷备、热备的实施，原则要求均为不影响正常业务功能，因此可选的时段只能是系统访问量较低的时段。方式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切换，就必须依赖强大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制，自动切换备库为主库，并通知所有应用转换为连接和使用新的主库，如果做不到自动的话，这个过程就仍然得基于“人肉”来进行操作了。
王速瑜：开放平台设计问题：开放平台API设计中，调用协议设计时有哪些考虑要求？对于请求类的调用协议设计，倾向于call?A=a&B=b这种方式（这种方式对调用者比较方便，但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比如WSDL、XML等？对用户鉴权的Token机制是怎样的？有没有对接入方进行QoS的考虑，是怎么做的?
林昊：对于开放平台而言，基本上目前Facebook引领了开放平台的技术，因此在协议上多数都采用Http，接口的设计上则都倾向于REST风格；对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式，并且此Token一定是由开放平台公司所提供；开放平台中是肯定会对接入方的QoS有限制的，并且这通常也影响到了开放平台的收费标准，在实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电信行业。
王速瑜：跨IDC部署程序模块在业务发展到一定阶段后在所难免，跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断的容灾措施？
林昊：跨IDC部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其次是部署所耗费的带宽成本和时间成本，对于部署结果验证而言，通常可采用的方法为业务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而言，通常需要借助自动化的部署系统。
王速瑜：Web2.0网站的海量小文件的存储，如用户头像、相册微缩图等文件，这些文件的特点是尺寸小（100KB以内），数量巨大（数以百万计），这些文件的存储、读取、备份都是问题，请问您是如何提供具体解决方案的？
林昊：目前互联网公司，例如Google、优酷等，对于小文件或大文件的存储都有自己的一套解决方案，而并不会去依赖高端的存储设备来解决。一方面是成本问题，另外一方面是伸缩问题，因此对于这些文件的存储、读取和备份多数都采用了类似GFS的方案或直接采用Hadoop提供的HDFS方案。
王速瑜：互联网产品部署是一个很关键的环节，很多互联网公司依然采取手工部署发布产品版本的方式，但是这种方式比较复杂而且低效，往往很容易出错，如果同时发布几个产品时，如果产品之间关联比较紧密，其中一个发布出错就会影响到其他的发布，请问作为架构师，您在日常工作中是如何解决这样的问题？您的团队中是否考虑自动化动态部署，具体方案是怎么样的？
林昊：在部署这个问题上，目前好像只有国外的几家互联网公司做的不错，其中最典型的是eBay。eBay在很多年前就已经做了一套自动化部署系统，在这套系统中，eBay可以将一次发布中的几个产品进行依赖关系的分析，从而决定其发布顺序，并可实现自动的发布、校验和回滚，这套系统相信也是现在中国几家互联网公司都在追求的目标。
王速瑜：作为互联网技术架构师，您能简单总结一下海里互联网服务技术架构方面的理念、原则，方法吗？
林昊：我觉得eBay的五点总结基本已经够全面：
（1）“ 拆分”，数据库的拆分以及应用的拆分，当然这需要强大的技术的支撑，这点要做到的目标通常是便于应用的无限水平伸缩；
（2）能异步就异步，这需要业务的允许；
（3）能自动就自动，就像自动化的部署系统；
（4）记住所有失败的事情，这点非常重要；
（5）容忍不一致性，这句话的含义是尽量少用强事务，而是采用最终一致性这类方案。
当然，除了上面这五点之外，还有像多用缓存、自行实现关键技术（以控制稳定性、性能和做到及时响应）等。
王速瑜：有很多优秀的软件架构师能力很强，但是由于缺乏海量服务技术应用和实践的机会，不能很好地进行海量服务应用的架构设计，您能给他们一些宝贵建议，分享一下您是如何不断学习成长起来的？您有哪些提高技术视野的方法和途径，比如有哪些书籍可以推荐，哪些优秀的网站可以推荐？
林昊：这个问题提到点子上了，很多架构师不知道如何应对大型、高并发的场景，最主要的原因是没有这样的实践的机会，毕竟目前只有在大型企业系统或互联网才能获得这类难得的实践机会，通常在没有实践机会的情况下是很难完全理解这些技术的。多数情况下，互联网中的技术方案都是在多次血泪宕机下成长起来的，建议只能是多看各种互联网技术介绍的文章，例如Google共享了很多，还有网上也有很多各家互联网公司技术架构文章的介绍，尤其是那类技术发展历程的介绍，可以设想下如果自己碰到这样的问题，会如何去解决，也许这样能慢慢掌握和理解大型、高并发系统的解决方案。书籍方面目前国内各种高性能方面的书也开始不断冒出了，例如有《MySQL性能调优与架构设计》、《构建高性能的Web站点》、《构建Oracle高可用环境》等，这些高性能的书通常都来源于作者亲身的经验，是非常值得学习的；另外要知道：如果想做到高性能，通常意味着要对软件（包括OS等）以及硬件技术都有充分的掌握，因此像《深入理解JDK》、《深入理解Linux内核》、《深入理解计算机系统》这些书也是非常值得一看的。至于网站方面，像http://highscalability.com/、http://www.javaperformancetuning.com/这些都是非常不错的网站。