转一篇架构师间的问答------如何对应大数据量网站的考验

提问嘉宾：

林昊，网名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 的良好结合，让我们通过它快速与测试、生产环境结合起来。