微服务拆分的思考

一、前言

前面几篇文章介绍了微服务核心的两个组件：注册中心和网关，今天我们来思考一下微服务如何拆分，微服务拆分难度在于粒度和层次，粒度太大拆分的意义不大，粒度太小开发、调试、运维会有很多坑。

二、微服务划分方案

1、按技术调用关系纵向拆分

• 应用层：面向各个端，比如面向收银员的，面向总部员工的。

• 核心领域：系统的核心业务，需要保证绝对稳定。

• 基础能力：更通用的基础服务，比如账号权限等。

• 依赖系统：对其它部门或外部公司的依赖。

基本原则：上层可以调用下层，同级可以相互调用，下层不能调用上层。

POS系统我考虑按技术调用关系拆分为6个左右的微服务，见下图

基础服务和核心业务要保证绝对稳定，一般业务可以接受短暂服务挂掉。基础服务主要是账号权限以及商品合并为一个微服务，核心业务拆成两个微服务，交易微服务会依赖于库存微服务，一般业务里分三个微服务，采购、数据统计和其它，任务调度放在其它微服务中。

业务模块架构图可参见 《窗帘销售平台技术架构的一点思考》

2、按业务流程横向拆分

业务流程反应的是数据流，数据从上游流到下游，上游微服务不可以调用下游微服务，下游微服务可以调用上游微服务。

挖机报价系统比较适合按业务流程拆分，见下图

业务模板架构图可参见  《从一张表格开始做挖机报价系统》

基础的账号权限、客户、商品合为一个微服务，售前、销售、售后拆成三个微服务

三、微服务拆分其它要考虑因素

1、基于开发人员

一个微服务有一个独立的负责人，还要考虑到有backup，小的技术团队不适合拆分粒度太细，否则开发效率和运维都会很痛苦。

2、基于迭代频次

系统发布是引起故障的主要原因，如果一个服务稳定不需要经常变更的可以拆成一个微服务，经常需要变更的拆分成另外一个微服务。

3、基于可靠性

核心服务是需要重点保障的，可以将其单独拆出来，核心服务功能逻辑尽量简单，减少依赖，这样稳定性会更高。