单体架构

将业务的所有功能集中在一个项目中开发，打成一个jar包部署。适合开发功能相对简单，规模较小的项目。

优点

• 架构简单
• 部署成本低

缺点

• 团队协作成本高
• 系统发布效率低
• 系统可用性差

---

微服务架构

服务化思想指导下一套最佳实践架构方案。服务化就是把单体架构中的功能模块拆分成多个独立项目。

• 粒度小
• 团队自洽
• 服务自洽

---

SpringCloud

国内使用最广泛的微服务框架，集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验

---

微服务拆分

微服务工程结构

• 完全解耦：每一个微服务都创建为一个独立的工程，甚至可以使用不同的开发语言来开发，项目完全解耦。
  • 优点：服务之间耦合度低
  • 缺点：每个项目都有自己的独立仓库，管理起来比较麻烦
• Maven聚合：整个项目为一个Project，然后每个微服务是其中的一个Module
  • 优点：项目代码集中，管理和运维方便
  • 缺点：服务之间耦合，编译时间较长

什么时候拆分？

一般情况下，对于一个初创的项目，首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发，快速产出生产可用的产品，投入市场做验证。为了达成这一目的，该阶段项目架构往往会比较简单，很多情况下会直接采用单体架构，这样开发成本比较低，可以快速产出结果，一旦发现项目不符合市场，损失较小。

• 创业型项目：先采用单体架构，快速开发，快速试错。随着规模扩大，逐渐拆分
• 确定的大型项目：资金充足，目标明确，可以直接选择微服务架构，避免后续拆分的麻烦

怎么拆分？

微服务拆分时粒度要小

拆分目标

• 高内聚：每个微服务的职责要尽量单一，包含的业务相关联度高、完整度高
• 低耦合：每个微服务的功能要相对独立，尽量减少对其他微服务的依赖

高内聚首先是单一职责，但不能说一个微服务就一个接口，而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时，最好就只修改当前微服务，这样变更的成本更低。一旦微服务做到了高内聚，那么服务之间的耦合度自然就降低了。

拆分方式

• 纵向拆分：按照业务模块来拆分
• 横向拆分：抽取公共服务，提高复用性

远程调用

RestTemplate

Spring提供了一个RestTemplate的API，其中提供了大量的方法，可以方便的实现Http请求的发送

这个方式存在许多问题，后面会有优化方案