在上一篇文章，我们从「服务维度」学习架构师的常用能力——微服务设计与治理。围绕着微服务生命周期的七个阶段，总结了常用的16条原则。其中原则15在微服务服务治理实践中非常重要，本文将重点进行拆解分析。

所谓AKF扩展立方体（AKF Scale Cube），是一个描述从单体应用到一个分布式可扩展架构的模型概念。

「水平扩容」比较容易理解，就是我们常见的操作——加机器。

根据AKF模型，面对服务负载升高的情况，其实除了加机器外，我们还可以考虑「功能拆分」或者 「数据分区」。

「Y轴扩展」相对复杂，我总结了几种模式：

1）微服务拆分。根据具体业务模型、领域模型拆分更细粒度的微服务。

2）业务隔离拆分。利用消息队列，将在线业务（OLTP）和耗费大量资源的计算任务拆分隔离。

3）核心与非核心隔离。对于一个微服务，可以将SKA客户与普通客户进行隔离，SKA客户使用独立的集群资源，提高稳定性。

某个微服务负载过高，一个非常常见的原因就是这个微服务承担了过多的职责。这个时候，我们需要根据具体业务模型、领域模型拆分更细粒度的微服务，也是我们常说的「垂直拆分」。

最典型的拆分方法论就是按照领域驱动设计（DDD）进行拆分。

以电商领域为例，按照领域可以拆分为：

系统按照领域拆分为多个微服务后，各个微服务由单独的团队负责整个生命周期的维护，单独部署运行。

这种隔离拆分的方式，能带来以下优势：

「Y轴扩展」除了按照领域进行服务拆分之外，另外一种非常重要的拆分方式，是将在线业务（OLTP)类型服务中「耗时任务」进行隔离拆分。

我们服务一般会采用Tomcat或者Jetty部署，同时采用同步调用的方式。以Jetty为例，默认线程池最大线程数为200。如果请求中有耗时任务，影响了同步请求的RT，那么线程池满后就会阻塞请求。

因此，耗时任务会显著提高服务负载、降低在线业务服务的吞吐能力。

通过引入消息队列或者任务队列框架，我们可以将耗时任务从在线业务服务中进行隔离拆分。

这种隔离拆分的方式，能带来以下优势：

「Y轴扩展」的第三种方式，是将核心与非核心进行拆分。

比如，我们通常可能会将「核心接口」与「非核心」接口通过一个服务内的不同线程池实现隔离。但是在节点资源（cpu/内存/带宽等）上并不能实现隔离。

因此，我们可以更进一步，通过集群拆分的形式进行隔离。

通过服务路由的配置，将核心接口路由到核心集群（一般节点配置更高），非核心接口路由到非核心集群。

另外，也有saas服务，通常会对SKA客户做独立集群，也是类似的逻辑。

这种隔离拆分的方式，能带来以下优势：

Z轴扩展的核心思想，是基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。

生产实践中，常用的z轴扩展有两种应用：

单元化架构主要关注的是应用部署、调用层面的问题。

一个单元，是一个五脏俱全的缩小版全站，它部署了所有微服务。

但它又不是真正的全站，因为每个单元只能操作一部分数据。

从这里我们也能看出，单元化架构要求系统必须具备的一项能力——数据分区。

当然，仅把数据分区了还不够，单元化的另外一个必要条件是，全站所有业务数据分区所用的拆分维度和拆分规则都必须一样。

一般来说，我们绝大多数系统都是面向用户的，按用户维度对数据分区，是一个最佳实践。

当然，如果是全球化部署的单元化架构，还需要考虑按照地域进行分区。

数据分区（shard），即是将全局数据按照某一个维度水平划分开来，每个分区的数据内容互不重叠，这也就是数据库「水平拆分」所做的事情。

前面提到了「数据分区」是「单元化」的必要条件，但是「数据分区」还有其他很多场景应用。

最典型的，就是MySQL单机瓶颈后，需要进行「分库分表」。在服务中需要引入一些支持数据拆分和路由的中间件，如sharding-jdbc、mycat等，在数据层面需要配置相应的分片逻辑。

另外，其他数据库的分区扩展（如redis集群、mongo集群等），也是非常典型的应用场景。

一般包括以下几种数据划分的方式：

本文从「AKF扩展立方」说起，介绍了提高服务负载能力的几种服务治理方式。

除了X轴扩展（加机器）外，还可以通过Y轴扩展（功能/业务拆分）、Z轴扩展（数据分区）等方式，更优雅、更精细地进行优化。

希望能够抛砖引玉，提供一些启发和思考。