目录

一、单体架构VS微服务架构

1.单体架构

​（1）.单体架构的优点

（2）.单体架构的缺点

 2.微服务架构

 （1）微服务的特性

 （2）微服务架构图

 （3）微服务的优点

 （4）微服务的缺点

 （5）微服务适用场景

 （6）微服务不适用场景 

二、微服务拆分

1. 微服务拆分--方法论

(1)领域驱动设计（Domain Driven Design）

(2)面向对象（By name / by verb） 

2 微服务拆分--常用

（1）按职责划分

（2）按通用性划分

3 微服务拆分--合理的粒度

三、实际项目流程

---

一、单体架构VS微服务架构

1.单体架构

（1）.单体架构的优点

• 架构简单
• 开发、测试、部署方便

（2）.单体架构的缺点

• 代码冗余，质量参差不齐，导致运维复杂性高
• 部署慢，全量部署，频率低，代码量大时，更加明显
• 扩展能力受限
• 阻碍技术创新，代码重构风险极高

 2.微服务架构

 （1）微服务的特性

• 每个微服务可运行在自己的进程中，意味着每个微服务都有自己的tomcat
• 每个微服务都能独立运行，共同构建整个系统
• 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理。
• 可使用不同的语言与数据存储技术（契合项目的情况和团队实力）
• 微服务之间通过轻量的通信机制进行通信，例如通过REST API进行调用。轻量通信机制，通信协议需要轻量，跨平台
• 全自动的部署机制。自动化构建、部署、测试等等。

 （2）微服务架构图

  （3）微服务的优点

• 单个服务更易于开发/维护，单个服务是有限的业务。
• 单个微服务启动较快
• 局部修改易于部署
• 技术栈不受限
• 按需伸缩

 （4）微服务的缺点

• 运维要求高，运维若干个jar，所以需要全自动的运维部署机制
• 分布式固有的复杂性
• 重复劳动，在相同开发语言下，可以提取一共公共模块，而不同语言是无法实现，还是得重复

 （5）微服务适用场景

• 大型/复杂的项目。如果你的应用用单体架构可以搞定了，就无需杀鸡用牛刀。
• 有快速迭代的需求
• 访问压力大的，微服务是去中心化的。

 （6）微服务不适用场景 

• 业务稳定，需求几乎不会变
• 迭代周期长，没有快速迭代的需求

二、微服务拆分

1. 微服务拆分--方法论

(1)领域驱动设计（Domain Driven Design）

推荐两本书：

《DDD的开山鼻祖》

《实现领域驱动设计》

(2)面向对象（By name / by verb） 

通过名词或动词拆分

2 微服务拆分--常用

（1）按职责划分

规划好微服务的职责边界，只关注职责范围内的业务，比如订单服务

（2）按通用性划分

把通用性功能做成微服务，比如用户中心，消息中心， 阿里的大中台与小中台其实也是按通用性，只是中台是多个微服务的聚合。

3 微服务拆分--合理的粒度

• 良好地满足业务
• 幸福感，团队对微服务的维护不会觉得像单体一样冗余复杂，部署也会高效
• 增量迭代，每个微服务相对独立，每次发布只是有限的微服务
• 持续进化，技术优化，风险可控
• 微服务拆分是动态的，可以会随着时间增减

三、实际项目流程

1、分析业务（流程图、用例图、架构图等等），主要任务是业务建模，确定架构

2、确定业务流程（评审）

3.设计API（我需要哪些API呢）/数据模型（表结构设计|类图|ER图等等）

4.编写API