目录
一、单体架构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
