翻译自: http://microservices.io/articles/scalecube.html
转载声明: 请注明原文地址和该译文出处。
注意: 若有翻译不当之处，请指明。共同进步。
有一本书，名字是 《The Art of Scalability》，其展示了一个模型(The scale cube, 立方体扩展模型)描述了一个非常有用的 可从三个维度来进展扩展软件架构.
在此模型中，把一个应用服务 部署/克隆 多份 以达到负载均衡 这个称之为 X轴扩展。其它两种扩展方式 为 Y轴扩展和Z轴扩展。 我们所说的 微服务架构是基于 Y轴扩展方式的。 下面来详细聊下 这三种扩展方式。
X轴扩展
这种扩展方式是由运行多个相同的一个应用以此来实现负载均衡。如果有 N个相同的应用部署，那么每个单独的应用只需要处理 1/N 份的负载请求。 这是一种简单的，普遍的一种扩展方式。
这种扩展方式也有一个缺点那就是每一个单独的应用服务都有可能访问所有的数据，所以内存中不得不缓存更多的数据来高效的响应。另外一个缺点就是 当开发需求或是开发所导致的问题越来越多时或是应用本身的复杂性提高时 所带来的管理及运维挑战.
Y轴扩展
不同于X轴与Z轴 是由多个同时运行的相同应用服务组成。 Y轴扩展则是尽可能的拆分一个单独的应用 成 多个不同的服务。每个不同的服务则负责一个到多个相近的功能模块。
目前有很多种方式来进行拆分一个应用为多个不同的服务。 其中一个方法就是 基于动词 的拆分方式来定义服务是如何实现一个 用户用例， 比如在电商网站中 “买单” 这样一个动作可以单独开发一个服务与之对应。 那么理所当然还有另外一种拆分的方法就是 基于名词 的。
再比如说在电商网站中的 “历史订单管理”。
当然一个应用本身可能也需要两种拆分方式组合起来。
Z轴扩展
这种扩展方式类似于X轴，都是在多个服务器上运行一段相同的代码。它们最大的不同是Z轴扩展上的每个服务器仅仅 拥有/负责 一部分数据。 一些系统组件可以做到 分发/路由 每一个请求到相对应的服务器数据集中。 一个普遍使用的 分发/路由 规则就是基于 包含在请求属性当中的 “对像的主键值”， 另外一个则是基于发送请求的不同的用户类型。 举个栗子，一个应用服务可以提供更高的存储容量给 付费用户， 对免费用户则是相对应的少一些。
Z轴的拆分通常就是针对数据库的扩展。 数据根据一定的特征被分区在不同的分区服务器上。再举个栗子， 我们可以根据日期来拆分相同的数据。需要注意的是X轴扩展方式下的每个分区数据可能需要被部署到一个或多个复本服务器上。
Z轴扩展同样也可以用到对应用程序的拆分上，栗子， 一个搜索服务可能涉及多个分区服务器上的数据， 这时需要有一个路由程序发送搜索请求到索引并且存储相应数据的相应分区服务器上。 同时也需要一个 查询聚合器将每个分区返回的数据合并起来。
Z轴扩展有几个优点：
1) 每个分区服务器只处理一部分数据
2) 改善缓存的使用率并减少内存使用和IO操作
3) 同时改善了事务处理的扩展性, 因为不同数据的请求已经被分发到不同的服务器上.
4) 同样也易于故障隔离, 因为一个故障只仅仅影响一部分数据的访问, 不是所有.
几个缺点:
1) 增加了软件的复杂度
2) 需要实现数据分区方案, 特别是某种情况下我们有可能需要对数据进行 重新分区.
3) 如果软件的复杂度提升, Z轴扩展方式不能很好的处理. 这时需要用到的就是Y轴的扩展方式.
