电商项目微服务架构拆分实战

1. 微服务架构拆分设计

1.1 微服务架构

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在 自己的进程中，服务间通信采用轻量级通信机制(通常用 HTTP 资源 API)。这些服务围绕业 务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

英文:Microserviceshttps://martinfowler.com/articles/microservices.html 

 中文:微服务｜YYGCui's blog YYGCui的个人博客http://blog.cuicc.com/blog/2015/07/22/microservices

单体架构 vs 微服务架构 

1.2 微服务拆分的一些通用原则

单一服务内部功能高内聚低耦合：每个服务只完成自己职责内的任务，对于不 是自己职责的功能交给其它服务来完成

闭包原则（CCP） ：微服务的闭包原则就是当我们需要改变一个微服务的时 候，所有依赖都在这个微服务的组件内，不需要修改其他微服务

服务自治、接口隔离原则：尽量消除对其他服务的强依赖，这样可以降低沟通 成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。这使 得服务可以独立开发、测试、部署、运行，以服务为单位持续交付。

持续演进原则：在服务拆分的初期，你其实很难确定服务究竟要拆成什么样。 应逐步划分，持续演进，避免服务数量的爆炸性增长。

拆分的过程尽量避免影响产品的日常功能迭代：也就是说要一边做产品功能迭 代，一边完成服务化拆分。比如优先剥离比较独立的边界服务（如短信服务 等），从非核心的服务出发减少拆分对现有业务的影响，也给团队一个练习、 试错的机会。同时当两个服务存在依赖关系时优先拆分被依赖的服务。

服务接口的定义要具备可扩展性：比如微服务的接口因为升级把之前的三个参 数改成了四个，上线后导致调用方大量报错，推荐做法服务接口的参数类型最 好是封装类，这样如果增加参数就不必变更接口的签名

避免环形依赖与双向依赖：尽量不要有服务之间的环形依赖或双向依赖，原因 是存在这种情况说明我们的功能边界没有化分清楚或者有通用的功能没有下沉下来。

阶段性合并：随着你对业务领域理解的逐渐深入或者业务本身逻辑发生了比较 大的变化，亦或者之前的拆分没有考虑的很清楚，导致拆分后的服务边界变得 越来越混乱，这时就要重新梳理领域边界，不断纠正拆分的合理性。

自动化驱动：部署和运维的成本会随着服务的增多呈指数级增长，每个服务都 需要部署、监控、 日志分析等运维工作，成本会显著提升。因此，在服务划分 之前，应该首先构建自动化的工具及环境。开发人员应该以自动化为驱动力， 简化服务在创建、开发、测试、部署、运维上的重复性工作，通过工具实现更 可靠的操作，避免微服务数量增多带来的开发、管理复杂度问题。

1.3 微服务拆分策略

功能维度拆分策略