可伸缩性框架搭建

本文面向创业公司的工程师，介绍可伸缩的Web开发技术。伸缩性是指系统可以根据需求和成本调整自身处理能力的一种特性。伸缩性意味着系统可以满足更多用户访问处理更多数据且不会对用户体验造成任何影响。
近些年来，越来越多的行业开始和互联网结合，诞生了越来越多的互联网创业公司。互联网创业公司需要面对许多的不确定因素。如果你和你的小伙伴们够幸运，你们的公司可能会在几个星期之内让用户数、商品数、订单量增长几十倍上百倍。一次促销可能会带来平时几十倍的访问流量，一次秒杀活动可能会吸引平时数百倍的访问用户。这对公司自然是极大的好事，说明产品得到认可，公司未来前景美妙。

但是快速增长的用户和订单却对公司的技术提出极大的挑战。受计算资源本身的限制，一台服务器能启动的线程数、能存储的数据，每秒钟能完成的计算、能读写的数据、能传输的数据都是有限的。而系统处理每一个用户请求都需要消耗一定的计算资源，当大量的用户同时来访问系统的时候，会出现因计算资源不足而导致的响应延迟以及超时出错，当并发访问用户超过某个极限，甚至会导致服务器宕机，整个网站不可访问的惨剧。

当公司正在为用户增加订单量上升而庆祝的时候，却传来系统崩溃网站不可访问的噩耗。喜剧变成悲剧，庆祝会变成批斗会，作为负责公司技术的工程师，作为批斗会的主角，你，是否会觉得压力山大。

本文面向创业公司的工程师，介绍可伸缩的Web开发技术。伸缩性是指系统可以根据需求和成本调整自身处理能力的一种特性。伸缩性意味着系统可以改变自身的处理能力以满足更多用户访问处理更多数据而不会对用户体验造成任何影响。
一、构建可伸缩的Web架构

互联网创业的一个特点是开始的时候规模都很小，几个人的小团队，少量的启动资金，就开始创业了。Google是从斯坦福的实验室开始创业的，Facebook是从哈佛的宿舍里开始创业的，Alibaba是从马云家的客厅开始创业的。刚开始的时候，用户也少，所以只要一台服务器就可以应付所有的用户访问，这时整个Web系统架构如图1。数据库、Web应用、文件服务都部署在一台服务器上。



图1 互联网创业早期最简单的Web系统架构
如果创业方向正确，产品解决用户痛点，能为社会创造价值，就会有更多用户来访问网站。这时，Web系统受计算资源不足影响，会出现响应延迟，打不开网站等情况。解决方法有两种，一种方法是使用更强大计算能力的计算机，另一种方法是使用更多的计算机。第一种方法主要问题在于再强大的计算机也都有资源限制，而一个成功的网站的终极目标是服务全世界，随着网站的发展，不管多强大的计算机迟早也会遇到计算资源不足的问题；而且越强大的计算机其价格也越昂贵，这也是刚刚起步的创业公司不能承受的。所以几乎所有的互联网公司都选择了第二种方法，即构建一个弹性可伸缩的Web系统，通过逐步向系统中增加服务器从而提高整个系统的计算处理能力。

增加服务器的一个基本手段是将不同的服务部署在不同的服务器上，应用服务器，数据库服务器，文件服务器独立部署，如图2。



图2 进行简单拆分独立部署的Web系统架构
此外，还可以将不同的模块拆分到不同的服务器。比如一个电子商务网站，商城、论坛、卖家这些相对独立的模块可以独立部署，即使在商城系统内部，首页、商品列表、商品详情、订单等子模块也可以进一步独立部署，如图3。



图3 按功能模块进一步拆分独立部署的Web系统架构
事实上随着业务不断发展，网站需要使用更多的服务，缓存、消息队列、搜索、NoSQL、反向代理等，还需要将静态内容服务从应用服务器中分离出来，以及使用CDN（内容分发网络）进行静态内容访问加速。这些服务都应该部署在独立的服务器上，通过使用更多的服务器提高网站的整体处理能力。

这些可以分拆的功能和服务虽然已经独立部署，但是每个功能或者服务如果只能部署在一台服务器上，能够提供的计算能力以及能够处理的并发访问依然有限。解决方法是通过集群的方式将单一服务部署在多台服务器上，从而提供更强大的处理能力，如图4。



图4 集群部署的Web系统架构 
总之，可伸缩网站架构的核心思路就是通过分拆集群等手段向Web系统中添加各种服务器，为系统提供更多计算、存储、传输能力，这些服务器能有效分担系统访问压力，使Web系统能够支撑更多用户访问、存储更多数据而不至于影响用户体验。
二、使用可伸缩的基础技术产品

前面提到，单一服务或者应用需要通过集群的方式提供更强大的计算处理能力。集群即多台服务器部署相同应用或服务构成一个服务器群统一对外提供服务。如果有更多用户访问，需要处理更多并发访问请求的时候，只需要向集群中添加新的服务器即可。这就要求服务或应用本身具有可伸缩性。
1. 通过负载均衡实现应用服务器可伸缩

应用服务器一般指部署核心业务逻辑，主要处理用户请求的服务器。应用通常设计成无状态结构，即应用本身不记录用户请求的上下文信息，这样设计的好处是任何用户的任何一次请求都可以交给任何一个应用服务器去处理。实践中，一般通过负载均衡服务器将一组应用服务器构建成一个集群，如图5。



图5 通过负载均衡实现应用服务器可伸缩（图片来源《大型网站技术架构：核心原理与案例分析》）
首先在负载均衡服务器上配置所有的应用服务器信息，用户请求先到达负载均衡服务器，负载均衡服务器通过某种负载均衡算法计算得到一个应用服务器的网络地址，然后将请求数据包转发给这个应用服务器，由该服务器完成用户请求处理。如果用户数增加，并发请求超过现有集群的处理能力，只需要在现有应用服务器集群中增加服务器，在负载均衡服务器上增加新的服务器配置信息，部分用户请求就会转发到新增服务器上，实现分担集群访问压力的目的。
负载均衡服务器的实现有很多种，DNS负载均衡、HTTP重定向负载均衡，HTTP转发负载均衡、IP层负载均衡、数据链路层负载均衡等，实践中，中小网站多使用Nginx等反向代理服务器实现HTTP转发负载均衡，而规模稍大以后则基本都使用LVS实现IP层负载均衡或者数据链路层负载均衡。目前越来越多的网站使用云服务部署网站，这些云服务也提供负载均衡服务，背后使用的技术依然是LVS或者HTTP转发。
2. 通过远程分布式缓存实现缓存可伸缩

缓存是改善网站性能的最重要手段，一方面缓存使用内存存储数据，可以更快速地响应请求；另一方面大量数据访问请求通过缓存返回，减少数据库压力，进一步改善性能。目前网站中大量使用的缓存服务是Memcached或者Redis。Memcached分布式缓存访问模型如图6。



图6 Memcached分布式缓存访问模型 （图片来源《大型网站技术架构：核心原理与案例分析》）
应用程序通过Memcached客户端访问Memcached服务器集群，其中路由算法模块负责根据应用程序输入的KEY计算得到应该访问哪台服务器，然后通过通信模块从对应服务器上读写数据。
如果Memecahed集群需要缓存更多数据或者需要提供更高的并发访问，只需要向集群中增加新的服务器，然后修改客户端服务器列表即可应用程序访问到新加的服务器。

需要注意的是如果路由算法选择不当，比如使用余数Hash算法，会出现加入一台服务器而导致现有的缓存数据大量访问不能命中的情况，其后果相当于缓存服务器集群整体宕机，给系统带来灾难性后果。目前Memcached主要采用一致性Hash算法，这种算法可以使加入新服务器对现有数据访问影响最小。而Redis通过一种类似虚拟节点的映射算法也可以达到相似的效果。
3. 通过主从复制和分布式数据库实现数据库可伸缩

目前各种网站主要使用的关系数据库是MySQL，MySQL支持数据复制功能，使用这个功能可以对数据库进行简单的伸缩。图7为使用数据复制的MySQL集群伸缩性方案。



图7 通过主从复制实现简单伸缩性的MySQL集群 （图片来源《大型网站技术架构：核心原理与案例分析》）
在这个方案中，虽然多台服务器部署MySQL实例，但是他们的角色有主从之分，数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。
主从复制只能通过增加有限的几台服务器分担数据库的访问压力，如果数据库需要记录数千万上亿条记录，需要应对每秒数十万次访问压力，那么主从复制是远远不够的。这种情况下，可以考虑使用更具伸缩性的各种NoSQL数据库产品，如HBase等，也可以考虑使用分布式数据库。分布式关系数据库则通过一个代理层将数据分片并经过路由后写入一个关系数据库集群中。

除了应用、缓存、数据库，其他的服务，诸如搜索、消息队列等也可以以类似的思路和方案实现集群可伸缩。
三、打造可伸缩的技术团队

创业公司刚开始时，通常不过两三个工程师，围绕核心业务，开发一个简单的版本就发布上线开始运营了。随着业务不断发展，服务器数量必定是越来越多、技术越来越复杂，对应的，公司规模也是越来越大，工程师团队越来越多人。一般说来，一家互联网公司能做到上市，工程师团队的人数大概从数百人到数千人不等，技术团队规模和创业时相比扩大数百倍。这就要求必须有效组织工程师团队，打造可伸缩的技术团队，使技术团队的成长和公司业务成长、技术水平进步保持一致。
1. 团队拆分

制约一个团队人数规模的主要因素是沟通路径，沟通路径越多，信息传递越慢，传递过程中引入的噪音越多，团队越趋于混乱。一个5人团队，沟通路径是10=(5*4)/2，一个9人团队，沟通路径是36=(9*8)/2，沟通路径随团队规模呈指数级增长。所以当技术团队人数增长到一定规模，和构建可伸缩的Web架构中需要对服务进行拆分一样，需要对团队进行拆分，将一个大团队拆分成几个小团队，使每个小的团队保持一个比较少的人数。

团队拆分有两种方案，一种是按职能拆分，前端工程师、后端工程师、测试工程师、运维工程师、数据仓库工程师各种工程师分别构成一个个的小团队，这种拆分的好处是团队结构比较稳定，团队成员都是使用同样技术的“自己人”，团队内部沟通交流更快速高效；带来的问题是开发过程是按照产品和项目组织的，而开发一个产品需要用到前端、后端、测试、运维各种工程师，开发过程会遇到各种跨团队的交流与合作，带来更多的沟通成本。另一种是按照产品和项目拆分，团队围绕产品展开，每个团队内部拥有开发维护一个产品所需的各种技术角色，从开发到测试发布运维都在团队内部搞定，不需要太多跨团队合作，这种拆分也存在一些问题，特别是创业公司早期，产品不稳定，管理层决定要上一个新产品，于是迅速招人开发，但是很多时候产品刚上线不久甚至还没上线，管理层的决定又有变化，产品不做了，团队解散，这种朝令夕改会对技术团队造成较大伤害，所以某些互联网公司特别将“拥抱变化”上升到公司价值观高度，让员工对这种情况做好心理准备。

对于公司而言，前一种方案带来的问题是沟通低效、人员冗余、开发进展缓慢；后一种方案带来的问题是员工情绪低落影响士气。显然前一种方案对公司发展影响更大，所以实践中，更多公司采用后一种团队组织方式。为了应对这种方案带来的消极影响，公司会积极组织各种培（xi）训（nao），提供各种员工福利员工关怀，让员工忘记各种不快，投入到下一个产品开发中。不过对创业公司而言，从本质上，员工利益和公司利益是一致的，只有公司活下去、做大做强，所有人才能更好的获益，不过这也要求创业公司尽可能做到决策透明，让所有员工能理解管理层的决定，并自觉维护、执行管理层的决定。
2. 保持敏捷
创业团队白手起家，不但表现在缺资金缺用户缺人才，也表现在缺管理缺标准缺规范，于是采用各种“野路子”的管理手段。但是公司发展到一定规模，这些手段就开始捉襟见肘，出现各种问题，于是公司开始从各种名企外企引入各类『管理人才』，进行规范化管理。不过在这个规范化的过程中，有时候会出现某种矫枉过正，导致公司僵化笨拙，还没成为大公司却得了一堆大公司的病。

举两个极端但是真实的例子。某公司要求代码单元测试覆盖率必须达到一定比率，并且写了工具专门扫描工程师提交的代码是否达到要求的单元测试覆盖率，于是就看到有些工程师为getXXX和setXXX方法写测试用例。某公司要求设计阶段必须写设计文档，并提供了设计文档模板，这个模板有一章叫做『数据库设计』，某个项目不需要数据库，因此设计文档不通过评审，为此工程师不得不设计了一个永远不会用到的数据库。

某位伟人曾经说过：教条不如狗屎，狗屎可以肥田，教条屁用没有。有些『管理人员』自己不曾在一线实践过，却为一线人员制定各种规章制度，效果可想而知。对创业公司而言，最好的管理不是流程规范，而是最佳实践。某个项目迭代管理做得好，某个项目设计文档写得好，拿来在全公司分享，大家一起学习改进，在实践中提高，产生更好的实践继续分享。从实践中来到实践中去，而不是从PPT来到Word中去。

原文转自:http://www.csdn.net/article/2015-10-28/2826059