微服务-(二)-微服务的拆分

单体架构

单体架构是什么

一个归档包(列如WAR包)包含一个系统所有功能的应用程序，我们通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。

单体架构的优点

• 架构简单
  整个系统都是采用的统一的技术线及框架

• 开发、测试、部署方便
  单体架构在是一直一个工程包，在同一目标下进行开发、测试更为方便，而部署也只需启动一个进程。

单体架构的缺点

• 复杂性高
  对于中大型的系统，所有功能业务都在单体工程中完成，其代码量、业务复杂性相当高，对缺陷定位、后期维护都带来了一定的难度。

• 部署慢，频率低
  一个系统一个归档包(列如WAR包)，因其代码量等原因，服务部署启动过程都会非常的缓慢，因此通常都会尽量减少对服务部署的频率，限制了起迭代能力

• 扩展能力受限

• 阻碍技术创新
  单体架构是技术框架是统一的，比如需要将持久层的框架从Hibernate更改为Mybatis则需要将整个项目都进行修改，对于工程较大的系统甚至可能会带来灾难性的后果

微服务

微服务的特性

• 每个微服务可独立运行在自己的进程里；
• 一系列独立运行的微服务共同构建起整个系统；
• 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，列如订单管理、用户管理等；
• 可使用不同的语言与数据存储技术(契合项目情况和团队实力)；
• 微服务之间通过轻量的通讯机制进行通信，列如通过REST API进行调用；
• 全自动的部署机制。

微服务的优点

• 单个服务更易于开发、维护
• 单位微服务启动较快
• 局部修改容易部署
  只修改单个微服务可以只部署单个服务
• 技术栈不受限
  每个微服务都可用不同的语言与数据存储技术
• 按需伸缩
  根据需求对整个项目进行伸展及收缩，便以扩展。

微服务的缺点

• 运维要求高
  比如微服务之间使用了不同的语言及数据存储技术，对应维护人员的要求及人员就会增加。
• 分布式固有的复杂性
  如服务注册发现、微服务间的接口调用等等。
• 重复劳动
  各个微服务不在同一工程项目中，某些可以共用的功能需要每个微服务都要重复开发或开发接口进行调用

微服务的使用场景

针对于微服务的优点及特性总结使用场景

• 大型、复杂的项目
• 有快速迭代的需求
• 访问压力大

不是用微服务的场景

针对微服务的缺点及单体架构的优点总结场景

• 业务稳定
• 迭代周期长

微服务拆分

方法论

• 领域驱动设计（Domain Driven Design）
• 面向对象(by name.,by verb.)
• 职责划分
• 通用性划分

合理的粒度

• 良好地满足业务
• 幸福感
• 增量迭代
• 持续进化

笔记分享小程序拆分示例

• API文档地址：https://t.itmuch.com/doc.html
• 前端源码地址：https://github.com/eacdy/itmuch-miniapp

微服务架构

简单的架构图