微服务架构并无规范架构，不然什么架构师大会也不会各个系统架构百花齐放了。尽管没有固定的套路，却有一些教训，明天就来做一个总结。
基于角色拆分
这种拆分形式常见于基础设施以及其 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 网关服务。
基于可扩展性拆分
首先来理解一下 AKF 扩大立方体。
AKF 扩大立方体（Scalability Cube），是《架构即将来》一书中提出的可扩大模型，这个立方体有三个轴线，每个轴线形容扩展性的一个维度：
X 轴 —— 代表无差别的克隆服务和数据，工作能够很平均的扩散在不同的服务实例上；
Y 轴 —— 关注利用中职责的划分，比方数据类型，交易执行类型的划分；
Z 轴 —— 关注服务和数据的优先级划分，如分地区划分。
文言来说：X 轴拆分就是通过加机器程度拆分；Y 轴拆分就是按业务逻辑垂直拆分；Z 轴拆分就是依照算法进行分片，这个算法比方按地区，不同地区拜访不同的分片或者服务。
举个例子，比方个别公司的 redis 集群会有一个团队来进行对立保护。redis 集群有主有从，数据都是一样的，多正本容灾，这是 X 轴程度的拆分。一个公司很多业务，redis 团队会对不同的业务提供不同的集群，这是 Y 轴垂直拆分；集群外部数据会通过 sharding 做分片，这是 Z 轴算法拆分。
基于稳定性拆分
在业务架构中，通常会通过外围模块的划分或者主次链路的划分来进行微服务拆分。
在《三立体拆散架构》中，我提到过拆散出管制立体、数据立体和治理立体。这实质上也是通过外围模块划分来进行拆分的一种形式。管制平台个别是外围链路，外围数据作为管制逻辑的一部分能够通过本地缓存等措施弱依赖于数据立体。治理平台是后盾治理等，用于增删改查，人工操作时才用，其余工夫挂掉都没关系。
基于资源需要拆分
依据性能需求来进行拆分。简略来说就是访问量特地大，拜访频率特地高的业务，又要保障高效的响应能力，这些业务对性能的要求特地高。比方积分竞拍、高价秒杀、限量抢购。
咱们要辨认出某些超高并发量的业务，尽可能把这部分业务独立拆分进去。这么做的起因非常简单，一个保障满足高性能业务需要，另一个保障业务的独立性，不相互影响。
相似积分竞拍、超低价秒杀、限量抢购，对霎时峰值和计算性能要求是十分高的。这部分的业务如果跟其余通用业务放在一块，一个是可能相互影响，比方某个链路阻塞，会导致雪崩沿调用链向上传递。
另外一个是如果多个业务耦合在一块，公布频率变高、服务扩缩容变难、保护复杂度变高。如下图例子所示，订单服务是一个性能要求高的服务，个别会独自拆分。
总结
咱们理论工作中，通常会发现一种拆分形式和另一种拆分形式并不抵触。一个残缺的架构也不只应用了一种拆分形式。《畛域驱动设计 (DDD) 中简略易用的 10 种技巧》也能够配合来应用。
本文提到的 api 网关严格上不是业务划分时的一个模块。业界通常把 api 网关作为一个基础设施。如果在架构图中蕴含了 api 网关通常是下图所示：
上图中的架构既蕴含了业务逻辑的业务划分，也有配置核心、注册核心这样的技术划分。总体上来说是一个技术架构图。而 api 网关自身也更多被归为是技术概念，而不是业务概念。
关键词：大数据培训