如何拆分微服务？

关于服务拆分的切入点，我们先从MartinL.Abbott所著《架构即未来》中所介绍的AKF扩展立方体出发寻找一些灵感，然后给出本文中关于服务拆分的三大维度。

一、AKF拆分原则

AKF扩展立方体（Scalability Cube）是一种可扩展模型，这个立方体有三个轴线，每个轴线描述扩展性的一个维度（见下图），分别是：

• Y轴

关注应用中功能划分，基于不同的业务拆分。

• Z轴

关注数据分区，通常是指基于请求和用户独特的需求，进行系统划分，并使得划分出来的子系统相互隔离，但又是完整的。有些类似于对表数据的拆分。

• X轴

关注水平扩展，其实就是将微服务运行多个实例，做集群加负载均衡的模式。做负载均衡其实是为了提高系统的性能。

以上X、Y和Z轴的划分可以概括为X 轴关注水平复制，Z 轴类似数据分区，而Y 轴则强调基于不同的业务拆分。理论上按照这三个扩展维度，可以将一个单体系统进行无限扩展。

二、微服务拆分维度

1. 基于业务拆分（类似于Y轴）

将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。

例如，做一个电商系统，可以划分为商品、订单、支付、发货、买家、卖家等服务。

2. 基于数据拆分（类似于Z轴）

在进行业务拆分过程中，我们发现业务往往与数据有较大耦合性。因为按照业务的维度拆分后，我们发现其中两个或多个服务在表数据层面关联较为紧密，存储跨库查询的情况。这会导致服务的拆分变得非常的困难。针对这种情况我们可以采取以下两种方式处理：

1. 把涉及到跨库查询的两个或多个微服务重新整合在一起，变成一个微服务。
2. 从技术角度解决跨库查询问题。关于该点本篇文章不做讲解。

例如，电商系统的订单和支付两个服务的表数据联系比较紧密，我们就可以把这两个微服务合并成一个服务，比如说叫下单服务。

3. 基于性能拆分（类似于X轴）

将对性能压力大的模块拆出来，避免影响其他服务，而且对其做性能提升、高可用等优化都更简单高效。

例如电商系统里的抢购，排队功能的性能压力很大，就可以将其独立为一个服务（而不是把它合并到下单服务里）。

注意：这几种拆分维度不是多选一，而是根据实际情况自由组合。