1.4　微服务拆分

微服务架构的显著特点就是微小、程序功能单一、颗粒度小。所以，宏大的单体架构向微服务架构演进过程中，关键的步骤就是进行微服务拆分，将颗粒度较大的单体程序拆分成多个颗粒度较小的微服务程序。

下面介绍微服务设计原则和拆分原则。

1.4.1　微服务设计原则

1．AKF拆分原则

AKF扩展立方体（可以参考The Art of Scalability），是AKF公司的技术专家抽象总结的应用扩展的三个维度。按照这个扩展模式，从理论上来说可以将一个单体系统进行无限扩展。基于AKF扩展立方体的拆分如图1-4所示。

X 轴：指的是水平复制、水平扩容。例如，单体架构系统多运行几个程序实例，做成集群加负载均衡的模式。

Z 轴：基于类似的数据分区。例如，一个互联网打车应用突然变得火热，用户量激增。集群模式不再适用，可按照用户请求的地区进行数据分区，在北京、上海、广州等多建几个集群。

Y 轴：就是微服务的拆分模式，基于不同的业务拆分。例如，按照不同业务类型、不同处理步骤、系统前后衔接关系、部署区域等进行拆分。

2．前后端完全分离原则

前后端在逻辑和物理上的分离，前端和后端均独立部署，各自专注自身业务。另外，前后端完全分离后，将静态资源推送到CDN上将更加容易，可以方便使用CDN的静态资源加速能力。

3．无状态服务原则

微服务尽量无状态化，优点是应用可以任意横向扩容、扩展。

4．RESTful通信风格

无状态的RESTful通信风格的HTTP协议具备先天优势，扩展能力很强。JSON 报文序列化，轻量简单，具备语言无关性，主流语言都提供成熟的RESTful API框架，相对于一些RPC框架生态更完善。

1.4.2　微服务拆分原则

1．粒度适中原则

拆分不应该过分追求细粒度，要考虑适中性，不能过大或过小。拆分后的代码应该是易读、易维护的，业务职责也是明确且单一的。

2．先大后小原则

在拆分大粒度模块时，一个模块拆分为一个微服务。后续迭代优化时，可以根据需要将较大的服务进一步拆分为多个微服务。

3．公共服务抽取原则

公共服务一般分为数据库服务、缓存服务、消息服务、日志服务、查询服务等，这些服务封装为公共服务，然后向其他微服务提供API接口。

4．实体类封装原则

数据库表对应的实体类、过程数据类、关联查询结果类，以及第三方访问返回结果类等是所有微服务都会使用到的模块。