SpringCloud入门：一、.微服务架构概述

爱被打了一巴掌 2023-10-04 20:36 75阅读 0赞

### 1.1 什么是微服务 ###

微服务的流行,离不开Martin Fowler,这个老头也是一个奇人,特别擅长抽象归纳和制造概念. Martin Fowler 在他的[博客][Link 1]([Microservices][Link 1]),对微服务进行的概括,如果英文不行,可以查看翻译版([微服务｜YYGCui's blog][YYGCui_s blog]).

他对微服务的描述如下:

![78ba0db659054cdfafdaff042d9dcc84.png][]

微服务就是一个单体架构的应用按照业务划分为一个一个的独立运行的程序即服务,它们之间通过Http协议进行通信(也可以采用消息队列来通信,比如RabbitMQ,kafaka等),可以采用不同的编程语言,使用不同的存储技术,自动化部署(如Jenkins),减少人为控制,降低出错概率,服务数量越多,管理起来越复杂,因此采用集中化管理,例如Eureka,Zookeeper等比较常见的服务集中化管理框架.

微服务是一种架构风格,一个大型的复杂软件应用,由一个或多个微服务组成,系统中的每个微服务可被独立部署,各个微服务之间是松耦合的,每个微服务只关注于完成一件任务并很好的完成任务.

### 1.2 系统架构演变 ###

随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化.从互联网早期到现在,系统架构大致经历了以下几个过程:

![9bcd5d2c2af549e590159cc6979a2769.png][]

接下来我们就来了解每一种系统架构是什么样的,以及各有什么优缺点.

![30437bc2729d449fa4db526dd535702e.png][]

#### 1.2.1 单体应用架构 ####

所谓单体架构,就是所有的功能打包在一个war包里,基本没有外部依赖(除了容器),部署在一个J2EE容器(Tomcat,JBoss,WebLogic)里,包含了POJO,DAO,Service,UI等所有的逻辑.

在互联网早期,一般的应用程序流量比较小,只需要一个应用,将所有的功能代码都部署在一起就可以,这样可以减少开发,部署和维护的成本.

比如说一个电商系统,里面包含用户管理模块,产品模块,订单模块...等等很多模块,我们会把它们做成一个web项目,然后部署到一台tomcat服务器上.

![167ce093e8b9446a80be728a39c0a3d4.png][]

单体架构比较适合小项目,优点是:

*  开发简单,集中式管理
 *  基本不会重复开发
 *  功能都在本地,没有分布式的管理开销和调用开销

它的缺点也很明显,特别对于互联网项目来说:

*  开发效率低:所有的开发都在一个项目改代码,递交代码相互等待,代码冲突不断
 *  代码维护难: 代码功能耦合在一起
 *  部署不灵活: 构建时间长,任何小的修改都必须重新构建整个项目,这个过程往往花费很长的时间
 *  稳定性不高: 往往一个微不足道的小问题,可能导致整个引用挂掉
 *  扩展性不够: 只支持某一种开发语言,无法兼容多言语

#### 1.2.2 垂直应用架构 ####

随着访问量的逐渐增大,单一应用只能依靠增加tomcat服务器节点来应付,但是这时候会发现并不是所有的模块都会有比较大的访问量,还是以电商为例,用户访问量的增加可能影响的只是用户和订单模块,但是对于消息模块的影响比较小,那么此时我们希望只多增加几个订单模块,而不增加消息模块,此时单体应用程序就无法实现了,垂直应用架构就应用而生,所谓的垂直应用架构,就是把原来一个单体应用拆成互不相干的几个应用,以提高效率,比如我们可以将上述电商的单体应用拆分成:

*  电商系统(用户管理,产品管理,订单管理...)
 *  后台系统
 *  CMS系统(广告管理,营销管理)
 *  ![f237586141834eb48f88f1c2bb8e9f90.png][]

优点:

*  系统拆分实现了流量分担,解决了并发问题,而且可以针对不同模块进行优化和水平扩展'
 *  一个系统的问题不会影响到其他系统,提供容错率

缺点:

*  系统之间相互独立无法进行相互调用
 *  系统之间相互独立,会有重复的开发任务

#### 1.2.3 分布式架构 ####

当垂直应用越来越多,重复的业务代码就会越来越多,这时候,我们就思考可不可以将重复的代码抽取出来,做成一个统一的业务层作为独立的服务,然后由前端控制层调用不同的业务服务?

这样就产生了新的分布式系统架构,它将把工程拆分为表现层和服务层两个部分,服务层包含业务逻辑,表现层只需要处理与页面的交互,业务逻辑都是调用业务服务层的服务来实现.

![5c52242155414385814f0fb8db964fa4.png][]

优点:

抽取公共的功能形成独立的服务,提高代码的复用性

缺点:

系统间耦合度提高,调用关系错综复杂,难以维护

#### 1.2.4 SOA架构 ####

在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需要增加一个调度中心对集群进行实时管理,此时,用于调度和治理中心(SOA Service Oriented Architecture)是关键.

![15f459bc9628409883a07a10dc485948.png][]

优点:

使用治理中心,解决了服务间调用关系的自动调节

缺点:

*  服务间会有依赖关系,一旦某个环节出现错误影响比较大(服务雪崩),主要原因是拆分的不够彻底
 *  服务关系复杂,运维,部署困难

#### 1.2.5 微服务架构 ####

微服务架构在某种程度上是面向服务架构SOA的继续发展的下一步,它更加强调服务的"彻底拆分".![e25139e2b8b146e8b226325c46fe11a7.png][]

微服务与SOA的区别:

微服务架构相比SOA架构,它的细粒度会更加精细,每个服务与服务之间互不影响,微服务架构中,每个服务必须独立部署,微服务架构更加轻巧,轻量化,SOA架构中可能数据库存储会发生共享,微服务强调每个服务都是单独数据库,保证每个服务之间互不影响.微服务架构比SOA架构更加适合公司敏捷开发,快速迭代版本.

优点:

*  服务原子化拆分,独立打包,部署和升级,保证每个微服务清晰的任务划分,利于扩展
 *  微服务之间采用Resultful等轻量级http协议相互调用

缺点:

*  分布式系统开发的技术成本高,对开发者的要求更高
 *  运维成本高. 比如: 部署项目数量倍增,监控进程倍增,故障定位难,问题难追溯

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

[Link 1]: https://www.martinfowler.com/articles/microservices.html
[YYGCui_s blog]: http://blog.cuicc.com/blog/2015/07/22/microservices/
[78ba0db659054cdfafdaff042d9dcc84.png]: https://img-blog.csdnimg.cn/78ba0db659054cdfafdaff042d9dcc84.png
[9bcd5d2c2af549e590159cc6979a2769.png]: https://img-blog.csdnimg.cn/9bcd5d2c2af549e590159cc6979a2769.png
[30437bc2729d449fa4db526dd535702e.png]: https://img-blog.csdnimg.cn/30437bc2729d449fa4db526dd535702e.png
[167ce093e8b9446a80be728a39c0a3d4.png]: https://img-blog.csdnimg.cn/167ce093e8b9446a80be728a39c0a3d4.png
[f237586141834eb48f88f1c2bb8e9f90.png]: https://img-blog.csdnimg.cn/f237586141834eb48f88f1c2bb8e9f90.png
[5c52242155414385814f0fb8db964fa4.png]: https://img-blog.csdnimg.cn/5c52242155414385814f0fb8db964fa4.png
[15f459bc9628409883a07a10dc485948.png]: https://img-blog.csdnimg.cn/15f459bc9628409883a07a10dc485948.png
[e25139e2b8b146e8b226325c46fe11a7.png]: https://img-blog.csdnimg.cn/e25139e2b8b146e8b226325c46fe11a7.png