网站建设公司宣传文案,网站开发 入门 pdf,小程序制作网站,加强健康养老网站建设一、前言 前面几篇文章介绍了微服务核心的两个组件#xff1a;注册中心和网关#xff0c;今天我们来思考一下微服务如何拆分#xff0c;微服务拆分难度在于粒度和层次#xff0c;粒度太大拆分的意义不大#xff0c;粒度太小开发、调试、运维会有很多坑。 二、微服务划分…一、前言 前面几篇文章介绍了微服务核心的两个组件注册中心和网关今天我们来思考一下微服务如何拆分微服务拆分难度在于粒度和层次粒度太大拆分的意义不大粒度太小开发、调试、运维会有很多坑。 二、微服务划分方案 1、按技术调用关系纵向拆分 应用层面向各个端比如面向收银员的面向总部员工的。 核心领域系统的核心业务需要保证绝对稳定。 基础能力更通用的基础服务比如账号权限等。 依赖系统对其它部门或外部公司的依赖。 基本原则上层可以调用下层同级可以相互调用下层不能调用上层。 POS系统我考虑按技术调用关系拆分为6个左右的微服务见下图 基础服务和核心业务要保证绝对稳定一般业务可以接受短暂服务挂掉。基础服务主要是账号权限以及商品合并为一个微服务核心业务拆成两个微服务交易微服务会依赖于库存微服务一般业务里分三个微服务采购、数据统计和其它任务调度放在其它微服务中。 业务模块架构图可参见 《窗帘销售平台技术架构的一点思考》 2、按业务流程横向拆分 业务流程反应的是数据流数据从上游流到下游上游微服务不可以调用下游微服务下游微服务可以调用上游微服务。 挖机报价系统比较适合按业务流程拆分见下图 业务模板架构图可参见  《从一张表格开始做挖机报价系统》 基础的账号权限、客户、商品合为一个微服务售前、销售、售后拆成三个微服务 三、微服务拆分其它要考虑因素 1、基于开发人员 一个微服务有一个独立的负责人还要考虑到有backup小的技术团队不适合拆分粒度太细否则开发效率和运维都会很痛苦。 2、基于迭代频次 系统发布是引起故障的主要原因如果一个服务稳定不需要经常变更的可以拆成一个微服务经常需要变更的拆分成另外一个微服务。 3、基于可靠性 核心服务是需要重点保障的可以将其单独拆出来核心服务功能逻辑尽量简单减少依赖这样稳定性会更高。