微服务架构（天行健，君子以自强不息；地势坤，君子以厚德载物。）

1.认识微服务

1.1.单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

单体架构的优缺点如下：

优点：

• 架构简单

• 部署成本低

缺点：

• 耦合度高（维护困难、升级困难）

1.2.分布式架构

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

分布式架构的优缺点：

优点：

• 降低服务耦合

• 有利于服务升级和拓展

缺点：

• 服务调用关系错综复杂

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

• 服务拆分的粒度如何界定？

• 服务之间如何调用？

• 服务的调用关系如何管理？

我们需要制定一套行之有效的标准来约束分布式架构。

1.3.微服务

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责

• 自治：团队独立、技术独立、数据独立，独立部署和交付

• 面向服务：服务提供统一标准的接口，与语言和技术无关

• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。

其中在Java领域最引人注目的就是SpringCloud提供的方案了。

1.4.SpringCloud

SpringCloud是目前国内使用最广泛的微服务框架。官网地址：Spring Cloud。

SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。

其中常见的组件包括：

另外，SpringCloud底层是依赖于SpringBoot的，并且有版本的兼容关系，如下：

1.5.微服务总结

• 单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统

• 分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝

• 微服务：一种良好的分布式架构方案

  ①优点：拆分粒度更小、服务更独立、耦合度更低

  ②缺点：架构非常复杂，运维、监控、部署难度提高

• SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

2.服务拆分和远程调用

任何分布式架构都离不开服务的拆分，微服务也是一样。

2.1.服务拆分原则

总结微服务拆分时的几个原则：

• 不同微服务，不要重复开发相同业务

• 微服务数据独立，不要访问其它微服务的数据库

• 微服务可以将自己的业务暴露为接口，供其它微服务调用

 3.微服务架构补充

3.1 单体应用架构

本质就是将项目所有模块(功能)打成jar或者war，然后部署一个进程

优点: 1:部署简单:由于是完整的结构体，可以直接部署在一个服务器上即可。 2:技术单一:项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。

缺点: 1:系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长;

2:系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机;

3:可伸缩性差:系统的扩容只能只对这个应用进行扩容，无法结合业务模块的特点进行伸缩。

4: 线上问题修复周期长:任何一个线上问题修复需要对整个应用系统进行全面升级。

5: 跨语言程度差

6: 不利于安全管理，所有开发人员都拥有全量代码。

小型项目适合单体应用架构. 比如:OA办公系统。管理类的项目 仓库管理系统。

3.2 微服务应用

微服务架构论文: Microservices

简单来说，微服务架构风格[1]是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
> 一个项目被拆分若干个项目
> 每个项目可以独立运行
> 每个项目可以使用不同的语言开发
> 每个项目可以拥有独立的数据库
> 项目与项目之间可以通信[http协议]

解读微服务特点:

1:微服务是一种项目架构思想(风格)

2:微服务架构是一系列小服务的组合（组件化与多服务)

3:任何一个微服务，都是一个独立的进程(独立开发、独立维护、独立部署)

4:轻量级通信http协议(跨语言,跨平台)

5:服务粒度(围绕业务功能拆分---模块拆分【系统管理服务】【日志服务】【焦虑测试】【抑郁测试系统】)

3.3 微服务架构的优势

1.易于开发和维护   一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态;

2.单个微服务启动较快   单个微服务代码量较少，所以启动会比较快;

3.局部修改容易部署   单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可;

4.技术栈不受限   在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈

5.按需伸缩  焦虑系统访问量大，只需要对焦虑系统进行扩展。

3.4 微服务架构的缺点(挑战)

1、服务太多，导致服务间的依赖错综复杂，运维难度大 

2、微服务放大了分布式架构的系列问题

• 分布式事务(seata)

• 分布式锁怎么处理(redisson) ,

• 服务注册与发现(nacos) .

• 依赖服务不稳定(sentinel)导致服务雪崩怎么办?

3、运维复杂度陡增，部署数量多、监控进程多导致整体运维复杂度提升。