架构设计的立方体扩展

转自：http://blog.csdn.net/houjixin/article/details/53675741

本文是对《架构即未来》一书第20章的总结； 

1. 立方体扩展是指X、Y、Z轴三个方向的扩展方式； 
2. X轴扩展，指水平扩展，这种方式简单易于实现，它要求服务必须是无状态的，部署1个和部署多个是一样的，这样可以根据系统当前的业务承载量来部署所需数量的服务实例，一般情况下，该业务需要与服务注册、治理、发现机制相结合，当一个服务A被水平扩展了一个新实例ai时，所依赖它（调用了它）的其他服务C需要能及时的发现这个新起来的ai，并且能把自己的对A的其他实例的调用分出来一部分到ai上，这种负载均衡机制一般有两种实现方式： 
（1） 在调用方程序中集成服务发现和负载均衡功能；如下图所示，这种方式实现负载，对调用方有影响，因为调用方在使用服务时还要集成它的服务发现和负载均衡相关功能模块。 
 
（2） 将服务发现和负载均衡做到中间代理中；这种方式所有的请求操作都是经过代理进行转发，当被调用服务A进行扩展时，由负载均衡器发现并连接到新启动的A服务实例，这些动作对于调用方C来说都是透明的；这种方式相对于第一种方式，会有一点性能损失。能起这种负载均衡作用的开源软件包括lvs，nginx（第四层负载均衡功能）； 
 
3. Y轴扩展，书中将Y轴扩展定义为按照交易处理的数据类型、交易任务或者两者的组合进行任务分割的过程。可以简单理解为将系统按照业务进行拆分，这就像工厂里的工人，当工人的所干的事情非常多时他什么都干不好，因此需要将工人进行分组，一部分人专门干一样事情；这里的Y轴扩展也是类似，当系统或者业务变得复杂时，我们就需要按照业务将系统分布不同的模块，每个模块专门干一件或一组相关联的业务，Y轴拆分之后，每个被拆分出来的服务完成一个独立的子功能或者子业务；例如一个系统原来有AC两个子功能组成，所有需要A和C功能的请求都会落到该系统上，随着业务量的增长，该系统被分为了A系统（完成A功能）和C系统（完成C功能），所有需要A功能的请求都被转到了A服务上，所有需要C功能的请求都被转发到了C服务上，从而实现对原系统的扩展。 
4. Z轴扩展，Z轴扩展可以按照两个方向去理解：（1）特殊人物要特殊对待，例如微博中，普通用户和那些大V的访问量时严重的不一样，当某个大V发表一个言论是，可能对在短时间内造成很大的压力，这个时候我们就可以把这些特殊的数据单独拉出来处理，这样他们访问量大的时候对别的用户的访问就不会受到影响；（2）将用户分组，还是以微博为例，当用户量比较少的时候，可能一个服务配合一组缓存和数据库就能应付所有用户，当用户量、访问量增大时，就需要将用户进行拆分，将一部分用户，例如按照ID取模将用户分到不同的服务中，这样系统的承载量就会增加； 
5. 立方体扩展中，比较难以理解的是Y轴扩展和Z轴扩展的区别，书中的介绍让跟感觉很混乱。根据个人理解，可以通过下面的例子进行理解区分： 
例如我们在设计一个类似qq或者微信的IM服务时，需要构建一个用户信息系统，该系统用于管理用户的个人信息（例如用户的账号、昵称、注册时间、手机号、邮箱等等）、好友关系和群组关系，当我们的用户量非常小的时候，可以将这些信息和操作都放在一个服务中完成，随着访问量的增加，我们很快就发现现有的服务（包括请求处理和数据的存取）已经扛不住访问量，这时候我们就考虑将系统查分为两个服务：用户信息服务和用户关系服务，用户信息服务管理（包括存储）用户个人信息，用户关系服务管理（包括存储）用户关系（包括好友关系和群组信息），这个拆分就是Y轴拆分，它是按照业务的不同进行的拆分；随着用户量的继续增长，我们发现用户信息服务又扛不住了，包括访问量和存储，这时候我们就需要再次对用户信息服务进行拆分，假设我们想把用户信息服务拆分为10个子服务，第i个子服务负责取模后为i的用户的请求，拆分时按照用户ID对10取模，然后将对应的用户分到0~9个用户信息服务中，例如ID为1000153的用户访问用户信息服务时它的请求将会被分到第3个子服务中，这个拆分动作就是Z轴拆分。