一、前言
前面几篇文章介绍了微服务核心的两个组件：注册中心和网关，今天我们来思考一下微服务如何拆分，微服务拆分难度在于粒度和层次，粒度太大拆分的意义不大，粒度太小开发、调试、运维会有很多坑。
二、微服务划分方案
1、按技术调用关系纵向拆分
-
应用层：面向各个端，比如面向收银员的，面向总部员工的。
-
核心领域：系统的核心业务，需要保证绝对稳定。
-
基础能力：更通用的基础服务，比如账号权限等。
-
依赖系统：对其它部门或外部公司的依赖。
基本原则：上层可以调用下层，同级可以相互调用，下层不能调用上层。
POS系统我考虑按技术调用关系拆分为6个左右的微服务，见下图
基础服务和核心业务要保证绝对稳定，一般业务可以接受短暂服务挂掉。基础服务主要是账号权限以及商品合并为一个微服务，核心业务拆成两个微服务，交易微服务会依赖于库存微服务，一般业务里分三个微服务，采购、数据统计和其它，任务调度放在其它微服务中。
业务模块架构图可参见 《窗帘销售平台技术架构的一点思考》
2、按业务流程横向拆分
业务流程反应的是数据流，数据从上游流到下游，上游微服务不可以调用下游微服务，下游微服务可以调用上游微服服务器托管网务。
挖机报价系统比较适合按业务流程拆分，见下图
业务模板架构图可参见 《从一张表格开始做挖机报价系统》
基础的账号权限、客户、商品合为一个微服务，售前、销售、售后拆成三个微服务
三、微服务拆分其它要考虑因素
1、基于开发人员
一个微服务有一个独立的负责人，还要考虑到有backup，小的技术团队不适合拆分粒度太细，否则开发效率和运维都会很痛苦。
2、基于迭代频次
系统发布是引起故障的主要原因，如果一个服务稳定不需要经常变更的可以拆成一个微服务，经常需要变更的拆分成另外一个微服务。
3、基于可靠性
核心服务是需要重点保障的，可以将其单独拆出来，核心服务功能逻辑尽量简单，减少依赖，这样稳定性会更高。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
文章目录 名称空间解释 访问kubernetes API的控制 RBAC的介绍 kubeconfig 用户的创建 集群默认角色 给组创建授权 针对pod配置服务账户 参考文档 名称空间解释 名字是啥？ 答：集群中每个对象的名称对于该类型的资源都是唯一的。并且每…
