微服务架构并无标准架构，不然什么架构师大会也不会各个系统架构百花齐放了。虽然没有固定的套路，却有一些经验，今天就来做一个总结。
基于角色拆分
这种拆分方式常见于基础设施以及其PaaS层的架构，比如服务治理、k8s、kafka。所谓基础组件的PaaS层是说，基础设施本身主要作为基础设施使用，是IaaS层。但是基础设施本身需要维护功能，需要增删改查等运维操作。业界基于开源做的二次开发也着重在做这方面的工作。
下面以kafka做说明。因为要上升到PaaS层，下图基于美团对kafka的二次开发封装，产品名叫mafka。
咱们直接看★标注的部分mafka-manager，这个就是运维操作统一管理端。充当的就是管理者的角色。再看看kafka其他组件的名称：生产者( producer )、消费者( consumer )、经纪人( broker )。核查员( monitor )。架构的组织都是根据角色来来划分的。
为什么我要将mafka-manager用★标注呢。因为不管是基础设施还是别的，以产品化的观点，需要对外提供一个完整的产品体验。完整的产品包含什么呢？统一的产品外观、统一的接口定义、统一的服务运营。
我们要接入mafka，虽然最终程序里要用的是生产者、消费者这些，但是第一步都要在mafka-manager对应的界面上申请。mafka-manager类似于网关入口的角色。业界有专门把这些接口服务抽象出来叫做api网关。
在k8s架构中，api网关这个概念更加明显一些。
kubectl是k8s的控制台命令交互界面、web UI是浏览器交互界面，不同的交互界面会走统一的api server。这里api server就是api网关服务。
基于可扩展性拆分
X轴 —— 代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；
Y轴 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分；
Z轴 —— 关注服务和数据的优先级划分，如分地域划分。
白话来说：X轴拆分就是通过加机器水平拆分；Y轴拆分就是按业务逻辑垂直拆分；Z轴拆分就是按照算法进行分片，这个算法比如按地域，不同地域访问不同的分片或者服务。
举个例子，比如一般公司的redis集群会有一个团队来进行统一维护。redis集群有主有从，数据都是一样的，多副本容灾，这是X轴水平的拆分。一个公司很多业务，redis团队会对不同的业务提供不同的集群，这是Y轴垂直拆分；集群内部数据会通过sharding做分片，这是Z轴算法拆分。
基于稳定性拆分
在业务架构中，通常会通过核心模块的划分或者主次链路的划分来进行微服务拆分。
在《三平面分离架构》中，我提到过分离出控制平面、数据平面和管理平面。这本质上也是通过核心模块划分来进行拆分的一种方式。控制平台一般是核心链路，核心数据作为控制逻辑的一部分可以通过本地缓存等措施弱依赖于数据平面。管理平台是后台管理等，用于增删改查，人工操作时才用，其他时间挂掉都没关系。
基于资源需求拆分
根据性能需求来进行拆分。简单来说就是访问量特别大，访问频率特别高的业务，又要保证高效的响应能力，这些业务对性能的要求特别高。比如积分竞拍、低价秒杀、限量抢购。
我们要识别出某些超高并发量的业务，尽可能把这部分业务独立拆分出来。这么做的原因非常简单，一个保证满足高性能业务需求，另一个保证业务的独立性，不互相影响。
类似积分竞拍、超低价秒杀、限量抢购，对瞬间峰值和计算性能要求是非常高的。这部分的业务如果跟其他通用业务放在一块，一个是可能互相影响，比如某个链路阻塞，会导致雪崩沿调用链向上传递。
另外一个是如果多个业务耦合在一块，发布频率变高、服务扩缩容变难、维护复杂度变高。如下图例子所示，订单服务是一个性能要求高的服务，一般会单独拆分。
总结
咱们实际工作中，通常会发现一种拆分方式和另一种拆分方式并不冲突。一个完整的架构也不只使用了一种拆分方式。《领域驱动设计(DDD)中简单易用的10种技巧》也可以配合来使用。
本文提到的api网关严格上不是业务划分时的一个模块。业界通常把api网关作为一个基础设施。如果在架构图中包含了api网关通常是下图所示：
上图中的架构既包含了业务逻辑的业务划分，也有配置中心、注册中心这样的技术划分。总体上来说是一个技术架构图。而api网关本身也更多被归为是技术概念，而不是业务概念。
在《尤娜系统的第一次飞行中换引擎的架构垂直拆分改造》中，首先就拆分出来了api网关层，这说明尤娜要下一盘大棋，最终对外会提供一个统一的产品。
