scale cube(伸缩立方/扩展立方)学习

scale cube，scale是扩展或者伸缩的意思，cube就是一个立方体。接下来简单介绍一下这个cube的意思。本文主要参考了akf scale-cube。

Q: 什么是scale cube？

A：可以翻译为伸缩立方，或者扩展立方。它总结了应用进行扩展/伸缩的三个方向，每个方向是立方体的一个轴。如图：

AKF_Scale_Cube.gif

其中XYZ轴分别表示：

X轴，水平扩展，即将服务和数据复制多份
Y轴，根据功能对应用进行拆分(比如微服务)
Z轴，根据服务或者数据进行分区

Y轴是根据"Disimilar Things"进行拆分，即不相似的东西，拆成独立的服务；Z轴是根据"Similar Things"，即将相似的东西放到一起。比如根据用户的来源地进行拆分，来自于中国北方的访问一个副本，来自于南方的访问另一个副本。

如图：

Scale_Cube_2.gif

Q: scale cude中的X轴怎么理解？

A: 简单来说，就是将应用变为几个副本，前面加上一个负载均衡器，使用一些负载均衡策略将流量导到各个副本上，以实现对更多流量的响应。

好处：

实现起来简单容易、快速
事务支持良好

坏处：

存储。如果每个副本拥有自己的存储，那么占用的存储空间就会增大。
缓存。并没有处理缓存问题。
如果应用本身是有状态的，比如具有session，或者要求session被存储起来，那么多副本伸缩就较难处理。

如图：

X_Axis_Scale_Cube.gif

其中：

Web层，表示对Web Servers(Web服务器)进行复制，并且做负载均衡。如果是一个web应用，放到了tomcat里面，那么web层的X轴扩展就是多个tomcat实例。
App层，将session存储在浏览器或者独立的缓存中，这样才能复制出多个副本。这些副本或者使用浏览器中的session，或者使用同一个地方对session进行缓存。
DB层。使用读写分离。读副本为只读业务场景服务，如报告、搜索等业务场景，就使用读副本。

一般来说，数据库的多副本和应用层的多副本处理方式是不一样的。常见的就是多个副本使用同一个数据库，数据库进行读写分离。

Q: scale cube中的Y轴怎么理解？

A: 简单来说，就是将一个大的应用分割为多个小的服务。分割的标准是不相似度(dissimilar)。这个跟大应用中的模块有些类似，模块与模块之间往往是不相似的。只是模块运行在同一个进程中，现在是将模块运行在不同的进程中。比如订单管理、顾客管理就可以分为不同的小的服务，共同组成电商应用。

优点：

对事务的扩展良好（呃...不太明白这点）
每个服务可以自由进行扩展
组织机构可以进行扩展
缓存命中率提升。因为各个服务可以自行设计数据库和缓存策略了嘛
可以通过故障隔离来增加可用性。以前是一个单体的话，某个地方出错了，整个单体进程就挂了。如果是微服务，某个服务出错了，其他服务依然可以继续运行。

缺点：

架构需要更多的时间
带来了更多的服务，造成了更高的复杂度

如图：

Y_Axis_Scale_Cube.gif

这个方向就跟微服务是一样的了。将单个应用拆分为多个微服务，也就符合微服务架构的优点和缺点了。

Q: scale cube中的Z轴怎么理解？

A: z轴更像是根据相似的东西进行切分。这里举两个例子就比较容易理解了：

根据客户(customer)的id，进行区分。比如10000号之前的客户的流量导入到副本A，10000号之后的导入到副本B
根据商品的sku，进行区分。某些sku由副本A进行处理，其他的由副本B处理。

优点：

对事务的扩展良好（呃...不太明白这点）
减少了响应时间。比如按地域进行分割，湖南的请求到达的就是湖南的服务器
增加了缓存命中率。缓存的数据量减少了，自然命中率就上升了。比如数据从所有的customer，变成了10000号以内的customer，自然数据量就减少了。
可以有故障隔离了。比如副本A出问题了，影响的只是10000号以内的customer，其余的不影响。

缺点：

架构需要花更多时间
复杂度增加

如图：

Z_Axis_Scale_Cube.gif

Q: 为什么是个立方呢？

A: cube，立方的意思就是。这三个维度并不是完全独立的，他们可以同时进行，以达到扩展的目的。
考虑立方中的某个点，就是既有X轴上的值，又有Y轴上的值，又有Z轴上的值。也就是说，一个系统里面，可能是微服务的，可能针对某个服务做了多副本及负载均衡的，同时针对customer id进行了分区的。

Q: scale cube和微服务是什么关系？

A: 很明显，scale cube中的Y轴就是通过dissimilar things，将应用划分为多个微服务。所以微服务是scale cube的一个方向。至于scale cube能不能用于微服务拆分，这里可取的就是dissimilar了。也就是说，要判断业务模块之间的相似性，区分其不同，相似的放一块，不同的就拆分为多个微服务。

参考资料：
[1] https://akfpartners.com/growth-blog/scale-cube/*