架构师接龙系列(200908-200911)

 

（本文来自《程序员》杂志0911期，更多精彩内容敬请关注0911期）

《程序员》杂志官方网站：http://www.programmer.com.cn/

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/programmer_editor/archive/2009/11/03/4761310.aspx

 

架构师接龙：黄冬VS邓毅

 

提问嘉宾：

黄冬，多年软件开发、系统架构、系统运营的经验。长期关注高可用性、高可扩展性的系统架构设计。主持设计和运行过多个大型高容量产品和系统。是中国FreeBSD 、 Python 社区的发起者和积极参与者，也是国内啄木鸟（ http://www..woodpecker.org.cn ）社区的创始人之一。现在北京从事系统架构咨询及系统运营外包的的创业。

 回答嘉宾：

邓毅，网易有道技术总监，负责新技术与应用研究团队的工作，带领很多有道核心技术的开发。清华大学计算机系博士学位，在模式识别、计算机视觉等领域有丰富的研究经验。

黄冬： 互联网在过去的数年中发展迅速，交换带宽已经从10M 迅速提升到了万 M ，而计算机的总线、 CPU 计算能力出现了很多瓶颈。经常会发现一台服务器的带宽有千 M 甚至更高，而使用的却不足，在架构上有什么考虑，让一台服务器能更多用起这样的带宽来？

邓毅： 网络技术的高速发展的确使得单台服务器的带宽有了很大的提高，这可以使得一些以前不太好做的事情更容易的实现。

一方面，对于后台计算服务部分，高速的带宽使得我们可以把更多的服务器通过以太网连接起来，进行大规模的分布式运算，让不同的机器处理大数据的不同部分，再通过网络把数据进行汇总，从而得到以前需要大型机才能获得的超大规模的计算能力，这让我们可以从海量的数据中分析出更加有用的信息。此外，通过网络，我们可以把多台机器联合起来组成分布式的存储系统，从而提高系统的存储容量、访问带宽以及可靠性。

另一方面，在前端与用户直接接触的部分，由于带宽的提升、网速的变快，用户的客户端程序可以更加频繁的与服务器进行通讯，传输更多的数据，“云计算”或者“软件加服务”的模式，使得原来单机服务无法实现的功能或者服务质量得以实现。例如有道的词典，当存在网络连接的时候，客户端的软件会把查询需求发送到服务器端，服务器端可以在一个非常大的词库中进行查询，还可以做一些智能分析的操作，从而在不占用用户本地资源的情况下，大大提升用户的体验。另一个例子是类似“云杀毒”之类的应用，通过网络把数据传回服务器进行杀毒，也是充分利用当今互联网的带宽。

黄冬： 作为负载均衡的一种方式，基于四层、七层的负载均衡交换在很长的时间里都是一种非常简单和常用的解决方案，随着服务器计算能力的提升，这种解决方案会发现越来越像是一个瓶颈点，有什么更好的考虑来解决这样的问题？

邓毅： 当网站的流量不断变大的时候，负载均衡交换的方法是一个较为简单的扩展系统容量的办法，但是它毕竟是一个通用的解决方案，有一定的局限性。所以，当这个方案遇到瓶颈的时候，就需要对业务流程和用户访问行为进行更细致的分析，找到可能的瓶颈。通常，解决这一些瓶颈的办法来源于对一些冗余运算或 I/O  的优化。例如，负载均衡有可能导致一些重复的运算（可能被均衡到不同的机器上去了），此时通过优化均衡方法、优化系统结构，可能可以在某个地方放入一个合适的缓存，保存中间结果，从而避免重复的运算，最终提高系统的吞吐。再进一步，如果还存在瓶颈，就可能需要在系统架构的层次做妥协，比如通过牺牲一定程度上事务的一致性换取更高的性能。

黄冬： 互联网的即时计算越来越多，而这样的计算越来越多的依赖大量的数据存储，比如依据数千万甚至更多的用户使用习惯和用户自身的使用历史，得出该次搜索的排充。在这样的计算面前是否有什么巧妙的方法？

邓毅： 使用大量的用户行为数据进行智能的分析，的确能够得到一些非常有用的数据，从而提升用户的体验。当然，这里需要大量的计算资源。

对于一些即时计算的场合，如果想享受这些数据带来的好处，一个办法就是把一些计算模型进行划分：对于规模较大且较长时期不会变化从而可以预处理的部分，在后台花费一些计算资源预先计算好，然后通过分布式的只读系统提供快速的读取服务；中等规模变化较快的数据，可以建立快速计算流程，定时计算，并立即可以访问；而与本次操作直接相关的数据，如用户特征、搜索词等，才是真正的即时计算，这时候需要考虑到足够短的响应时间。

把计算模型分解成这样的三个层次并不总是一件特别容易的时候，有时候甚至需要对计算模型进行必要少量的修改，在不大幅度牺牲准确度的情况下做一些简化，从而可以让不同类型的数据分开计算，最后再综合一起处理。

黄冬： 垂直搜索引擎已经成为各个网站及业务系统的必备功能，在这方面是否有一些良好的现成产品和架构方案？

邓毅： 随着互联网用户对于搜索这个概念的认识，垂直搜索日益成为各个网站的一个重要功能。当用户不知道某个东西在哪里的时候，可能不愿意一层层的去找，而会去搜。

相比通用搜索引擎，垂直搜索首先需要保证较低的开发成本，因为网站最大的技术力量需要花在其自身的核心价值上；其次，这样的引擎需要满足一定的性能和质量要求，虽然不必与通用过的搜索引擎那样快、那样准；最后，网站通常有自己特有的一些东西，比如一些结构较为特殊的数据需要搜索或者影响搜索排序，这就要求一个结构和功能可以方便定制的引擎。

互联网上有不少优秀的开源项目， 我个人比较了解的有 Apache  的分布式存储与计算软件 Hadoop 、搜索索引软件  Lucene  等。

黄冬： 大量的用户使用行为记录需要留存，而留存下的数据量非常大，对于相关的数据也要进行频繁和复杂的业务计算，对于这样的存储有什么解决方案吗？对于这样的分析型计算有什么有效的架构 ？

邓毅： 首先存储方面，根据计算对于数据的读写需求，可以有两种方案：

一种方式是采用适合流式处理的分布式文件系统，如 HDFS 、 GFS ，通过自动数据块的备份等技术，可以保证数据的可靠存储，同时利用大数据块的存储保证流式顺序数据读写的高性能。当一些数据需要经常性的全量访问，且这样的访问较容易流式的处理的时候，可以把这些数据存在这类文件系统中。

另一种方式是采用分布式的 Key-Value  结构，如  HBase 、 BigTable  等，他们的特点是可以支持随机读写，而简化的操作限制又使得它比数据库更容易实现大规模的分布式结构，因而适合计算中只需要读写海量数据中随机一部分条目的情况。

运算框架只要是支持大规模分布运算的都可以，例如前面提到的基于 Map/Reduce  的分布式计算框架  Hadoop 。  

 

**********************************************************

（本文来自《程序员》杂志0910期）

《程序员》杂志官方网站：http://www.programmer.com.cn/

 

架构师接龙：林昊&黄冬

提问嘉宾：

林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi在中国的推广起到了很大的作用。

回答嘉宾：

黄冬，有多年软件开发、系统架构、系统运营的经验验。长期关注于高可用性、高可扩展性的系统架构设计。主持设计和运行过多个大型高容量产品和系统，也是中国FreeBSD、Python社区的发起者和积极参与者，也是国内啄木鸟（http://www.woodpecker.org.cn）社区的创始人之一。现在正在北京从事系统架构咨询及系统运营外包的的创业之路。

    林昊：随着数据量的不断增长以及前端应用的不断水平扩充，数据库的压力会成为明显的问题，这个时候常用的方案是数据拆分，在数据拆分时有些什么较好的拆分方式，以及如何能够做到数据拆分后对已有程序不产生影响或产生很小的影响？

    黄冬：这个拆分以应用的特性为主，从业务的特性出发更为重要，不是一个技术层面的通用解决方案，一般来讲先会从业务自身分析，已经有人总结过数据库做拆分的几种方式：

    1．按功能划分（垂直切分）

    将不同功能相关的表放到不同的数据库中，这样做的好处是非常直观。但当某一部分的功能其数据量或性能要求超出了可控的范围，就需要继续对其进行深入的再切分。

    2．按表中某一字段值的范围划分（水平切分）

    当伴随着某一个表的数据量越来越大，以至于不能承受的时候，就需要对它进行进一步的切分。一种选择是根据key 的范围来做切分，譬如ID 为 1-10000的放到A上，ID 为10000~20000的放到B。这样的扩展就是可预见的。另一种是根据某一字段值来划分，譬如根据用户名的首字母，如果是A-D，就属于A，E-H就属于B。这样做也存在不均衡性，当某个范围超出了单点所能承受的范围就需要继续切分。还有按日期切分等等。

    3．基于hash的切分

    类似于memcached的key hash 算法，一开始确定切分数据库的个数，通过hash取模来决定使用哪台。这种方法能够平均地来分配数据，但是伴随着数据量的增大，需要进 行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash 算法重新运算，数据需要重新割接。

    4．基于路由表的切分

    前面的几种方式都是根据应用的数据来决定操作的，基于路由表的切分是一种更加松散的方法。它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个数据库，这种方式是一种更加通用的方案。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容存储到一台独立的Cache上是一个非常好的方式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加数据库节点的时候，可以在不影响在线应用的情况下来执行，当然这也跟应用 程序的架构设计相关，你的设计必须适用这种增加。

    最后我还需要说明的是数据不止可以存在数据库中，大的概念来讲，像邮件系统中的邮件、视频文件等都有着相同的分布式存储的算法。我自己经历过的邮件、播客等都应用了大量的数据切分的模式将数据切分到数百台存储节点中去。

    林昊：数据拆分只是解决数据量增长后带来的问题的一种解决方案，请问是否还有一些其他的方式来解决数据量增长带来的问题呢，以及如何来实现这些方式呢？

    黄冬： 原则上来讲只有两种方法来解决数据增长带来的问题：拆分和增容。也就是拆到多个节点去，或是提升单个节点的容量能力。但是也有一些特别的方式，它们不通用，需要从业务关点来仔细评估：

    1．Cache 是一种应用已久的方案，通过提前计算，将数据缓存起来。传统新闻网站的新闻的分发、Cache应用已久，而且当动态计算无法支撑时，静态化、缓存化总是百试不爽的终级方案。

    2．阶段计算、阶段存储，通过阶段的计算，减少最终数据量。例如mrtg（一种通用的snmp监控程序）它的rrd 存储就是这样阶段计算、阶段存储的例子，最终使用的24小时数据、月/ 年数据总是最少的，不一定需要所有的详细数据。

    林昊：互联网应用的功能都是出于一种高速发展的状况，如果所有功能都在同一个系统上的话，会带来维护困难、机器性能无法合理发挥以及水平扩展性不够好等问题，对于此类问题应如何解决，解决时带来些什么技术挑战呢？

    黄冬：互联网的应用已经将IT 行业自身与其他行业的结合融合了起来。从前的系统运营、业务运营、软件开发甚至硬件开发等结合到了一起。最为核心的是将外包服务者和技术服务提供者融合了起来。未来将是服务为王的时代，所以这个时代给技术带来的挑战皆因从服务提供到运营提供带来的转变：

    1）软件开发如何从软件工程的迟钝变得敏捷起来，互联网运营要求软件系统每月、每周甚至每日发布。

    2）配置管理如何从并行数个版本的分支态，转变为只有当前开发版本和线上运行版本；从发布软件包，转变为发布到数十、数百、数千台服务器上的发布。

    3）系统运营的统一化、细节化且快速反应的能力，在互联网不再看到之前几小时响应的招牌，更多的是可用性。

    更为本质的，就是将传统的技术如何完成需求达成项目，转变为整个技术团队为服务品质（可用性等）、质量（未知Bug数量）去努力的工作目标。

    林昊：大型网站经常会碰到如下现象，同样功能不同的用户使用时会由于其数据量或其他原因造成不同级别的响应时间，这种现象很容易带来这样的问题：响应慢的用户大量访问时影响到本来响应快的用户的访问，对于此类问题应如何解决呢？

    黄冬：

    1．应用系统与数据一样需要切分。比如同样是缓存池，小文件的页面、图片、flv 的视频就应该使用完全不同的服务器群。

    2．从系统层面也有一种策略就是将所有的应用部署在所有的设备上，通过流量分流来动态调整、切分应用间的相互影响。

    林昊：9月1日Gmail 出现了100分钟不可用的现象，其事后的声明表明这是由于他们采取的一个保障服务可用性的策略造成的流量过大的问题，对于这个问题您有什么解决的建议呢？

    黄冬：错误任何人都会犯，从一个技术人员为出发点我表示理解。从一个管理者为出发点我认为是对于该项工作投入不足，不过有哪一家公司拥有充足的资源呢？

    对于这样的问题，我也同样从技术和管理两个角度来提建议：

    从技术角度来讲，显然Gmail 的新策略在实施过程中过分乐观，造成了流量积累性的冲击，而整体系统的冗余并不能提供充分的切换空间。这样必须从容量估算和切换时的计算再进行理性的评估，当然切换时间点也可以考虑。

    从管理角度来讲，这样的工作是一个经验型、技巧型的工作，让更有经验、了解更多技巧的优秀工程师和更多资源的投入必然能提前性地解决这样的问题。拥有更多最优秀的人才应该是每一个企业管理者的重要工作。

    林昊：对于大型网站而言，经常要面对不可预知的热点事件带来的高流量，如何能够做到避免这样突发的高流量造成网站的不可用呢？

    黄冬：

    1．业务运营原则上来讲应该可以有所预知，像奥运这样的热点事件应很早就可以预知。

    2．系统自身就因为面对过热点事件，而拥有冗余能力。

    3．系统快速部署能力和扩展方式非常重要，之所以Cache在大型网站应用广泛，就是因为其扩展方式支持极快的部署。

    4．分布式服务更可以利用GSLB在全网调动流量，使得单个服务点的故障得以解决，同时也可以充分地利用多个节点的冗余能力。

    林昊：高度可伸缩是互联网追求的目标，基于您的经验，请提供一些构建高度可伸缩系统的最佳实践？

    黄冬：在系统架构中，我自己应用最多的是这三个原则：

    1．让数据靠近CPU ；

    2．消减重复的计算；

    3．让计算前置。

    这些原则考虑的更多一些，但是基于业务的灵活应用非常重要。

    林昊：云计算是目前互联网领域中相当热门的话题，您如何看待云计算给互联网领域带来的挑战以及利益呢？

    黄冬：云计算本身就是互联网带来的一种服务，所以它是让互联网更为深入生活的一个技术，它带着互联网积累的一系列技术和经验去改变传统行业的架构模式。未来每个企业都会有自己的云，每个云都会与其他的云建立起密不可分的关系。而中小企业将会逐步改变对虚拟主机和主机拖管的模式，走入云中。

    林昊：成本问题逐渐成为互联网行业关注的重点问题，请提供一些可降低成本的技术方法，并介绍一下这些技术方法会带来些什么挑战？

    黄冬：从成本上来说，实质上是越来越低的，我们会发现磁盘容量、计算能力已经越来越便宜。降低成本的方法即是勇敢地尝试和探索新的技术。从互联网的发展来看，有几个技术非常值得我们去关注：

    1． 存储技术。一些新的存储技术， 如Sun 的ZFS和基于ZFS的存储解决方案已经在很多地方使用起来。而且基于应用层的分布式存储技术也大量出现。它将原有EMC和Netapp的存储模型完全打倒。

    2．负载均衡技术。基于Linux 的LVS和BSD的PF的负载均衡技术其实早已经被大量使用。但现在数G带宽的应用越来越多，相信未来与交换机结合在一起的二层、三层负载均衡技术又会兴起。另一方面，基于应用系统架构设计的七层负载均衡技术与互联网的壮大在各个公司里变得越来越重要。

    从挑战上来讲，这些技术会让之前人们认为很“值钱”的某某认证付诸东流，而对于自己所掌握的技术能力会有更高的要求。现在来看，互联网的大容量正是会培养出一批优秀系统工程师、系统架构师的基础，谁能培养出这些人才并留住，必然会取得领先。

    林昊：自动化能大幅度地提升开发、测试、部署效率，甚至是更好的保障系统可用性，您觉得在互联网行业中哪些方面的自动化是最为重要的，如何来实现呢？

    黄冬：说实话，完全的自动化是相对的，必竟在执行任务过程中的意外会很多，而这样的意外必须由人来控制。在我自己面对的系统中，已经实施自动化的主要是：

    1．帐号管理和同步：我自己使用ssh、scp 和cron 加shell 脚本完成这样的工作。

    2．可控的自动化测试环境、生产环境部署，以及部署的回退：我们使用一个叫做Capistrano 的小工具完成这个工作，它是基于ruby 和ssh 的小工具，帮助我们完成在服务器群中的快速部署和回退。它与svn 的良好结合，让我们通过它快速与测试、生产环境结合起来。

***************************************************************

（本文来自《程序员》杂志0909期，更多精彩内容敬请关注0909期杂志。）

 

架构师接龙: 王速瑜VS.林昊

 

提问嘉宾：

王速瑜，腾讯R&D研发总监，从事产品研发和管理工作，对互联网产品发展趋势、管理理念、技术架构有浓厚的兴趣和深入研究实践。目前主要关注敏捷开发、大规模应用架构、企业SAAS、Web2.0产品的相关技术和趋势。

回答嘉宾：

林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi在中国的推广起到了很大的作用。

王速瑜：数据集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？

林昊：一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在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/这些都是非常不错的网站。

 

********************************************************************************

本次“架构师接龙”全文，请见2009年08期《程序员》杂志。

 

冯大辉 vs. 王速瑜：支付宝架构师对话腾讯研发总监

 

不久前，我们发表了支付宝架构师冯大辉提出的问题，并邀请了腾讯的研发总监王速瑜先生做出回答，下面登出本次问答的节选，希望广大网友和读者们积极参与，提出你们想要问的问题。

王速瑜，腾讯 R&D研发总监，从事产品研发和管理工作，对互联网产品发展趋势、管理理念、技术架构有浓厚的兴趣和深入研究实践。目前主要关注敏捷开发、大规模应用架构、企业SAAS、Web2.0产品的相关技术和趋势。博客地址：http://blog.thinklet.net/mantian/

冯大辉：假设一家C2C 网站，DB中某表存储买卖双方交易的数据信息，对于一条交易来说，买卖双方数据具有一定程度的耦合性，比如卖家的状态更新对应买家的状态也会更新，对于一个中大规模的电子商务网站，架构师在设计中如何考虑数据分片的问题（假定该表随着数据的膨胀必须拆分)?

王速瑜：对于一个中大规模的电子商务网站，随着网站的不断发展，其相应的数据规模会不断膨胀。数据分片技术是使网站得于实现可扩展性的一种常用解决方案。对于C2C类型的网站，由于交易记录不容易进行水平的数据分割，因此对于这样的应用处理要在进行细分：

1. 买卖双方交易的信息，具备较高的时效性，即交易全部完成后就不会再有更新，因此这部分数据可以与正在交易中的数据区分开来，并可以单独分表，定时归纳。具体的做法可以采用水平分割的数据分片技术，比如可以根据用户号码段范围进行切片，把不同的群体划分到不同的 DB 上，这样可以很好的进行横向水平扩展（Scale Out）。它可以很好的突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
2. 对于正在交易中的数据，主要根据时间进行分表。如果分的更细，则可以分三个表，但是这样在事务保证方面则要复杂很多，不建议这样做

冯大辉：技术团队在开发过程中是否进行集成测试? 进行与否的理由各是什么? 对于集成测试你是否有其他补充?

王速瑜：有进行集成测试，因为集成测试对于产品版本的发布是一环重要的保证。但是由于互联网产品研发的敏捷性，很难建立一套大而全的集成测试平台，而更多还是在功能级和模块级别上的集成测试。

互联网产品的测试跟传统的软件测试不太一样，互联网产品的特性是短平快，因此敏捷开发的理念在互联网产品研发中非常适合，腾讯很多团队都采用敏捷开发的实践，包括TDD,重构和持续集成。因此集成测试更多是体现在产品的每个小迭代和小发布中。互联网产品技术架构都是分层的，因此对于后台server的集成测试也很重要，这个在迭代过程的测试中容易被忽略。这一块往往需要开发额外的工具来辅助进行，比如对于协议接口的测试，通常会有一些小工具来辅助进行。

冯大辉：对于一个架构师来说，如何与冗杂的会议进行斗争? 你有哪些心得或者贵公司有哪些针对会议的策略呢?

王速瑜：对于架构师，参加会议是必然的，架构师往往都需要深入到具体的项目中去，在项目的开展过程，大概会有几类会议是由架构师发起或重点参与的，包括迭代0的架构设计讨论会、定期的架构和代码Review会等等，项目之外，架构师通常还会参加诸如行业级和公司级别的一些盛会和峰会。对于会议，更多还是抱着有益，高效的态度去参加。在实际工作当中，我觉得有以下几点是可以参考的：

1. 涉及架构发展和改进的会议一定要进行， 而且要在产品研发过程中阶段性进行。有利于保证架构工作的可持续发展；
2. 由架构师主导的会议，要把握高效会议的原则，包括会议前的充分准备工作、会议进程的把握、会后的关键事项跟进等等；
3. 架构师要积极参加产品的讨论会，了解产品发展的规划和细节，有很多架构工作是需要技术与业务相平衡的，参加这样的会议有利于架构师更好理解业务和它的发展，从而为架构的平衡做出更好的判断；
4. 架构师要扩展视野和保持不断学习的态度，因此行业技术盛会、公司技术峰会、产品月会等等类型的会议架构师要主动选择性去参加，可以保证架构师能了解技术趋势，提升自己的能力。
5. 不必要的会议尽量不参加，可以采取其他沟通手段，如邮件，IM工具来替代，提升沟通的效率。

冯大辉：架构师是否有必要关注用户体验? 如何从架构师的层面关注用户体验?

王速瑜：非常有必要。保证用户体验是所有软件最重要的目标，特别是互联网产品，如果该目标无法实现，再好的架构也没有存在的意义。因此如何在满足用户体验的前提下进行架构设计是架构师的必要素质。

产品的用户体验包括几个方面：产品的功能便利性、产品可用性、性能、安全性等等。例如：枪战类的游戏，需要优先保证其实时性。而在C2C订单交易中则优先保证其金钱的安全性。因此如何从架构层面就去关注用户体验非常重要。对于架构师来说，通常有以下几点是需要注意的：

1. 用户体验表现在外表，但来源与内在。比如互联网服务的性能设计，能否让用户在1秒内使用你的产品，将是保证用户继续使用产品的关键所在。架构上如何做得在海量用户的前提下很高的性能，就应该是架构师首要关注的点；
2. 用户体验与架构设计有时候会对立矛盾，架构师需要平衡。比如为了某个用户体验，可能需要架构上做出重点的调整，可能会带来巨大的运营成本。这个时候就需要架构师来Trade-Off了，柔性可用依然是可以采取的架构原则；
3. 一切以用户体验和价值为核心是每个架构师在架构互联网服务的基本准则。互联网服务不同于传统软件，UGC型的互联网产品更是如此，没有用户参与，再好的架构都是无益的，因此架构设计需要围绕用户体验和价值来持续进行。