【微服务】认识微服务

1.1 单体、分布式、集群

单体

分布式

集群

1.2 系统架构演变

1.2.1 单体应⽤架构

1.2.2 垂直应⽤架构

1.2.3 分布式架构

1.2.4 SOA架构

1.2.5 微服务架构

1.3 微服务架构介绍

微服务架构的常⻅问题

1.4 SpringCloud介绍

1.4.1 SpringBoot和SpringCloud有啥关系?

1.4.2 SpringCloud版本名称?

1.4.3 为什么选择SpringCloud Alibaba？

1.1 单体、分布式、集群

我们学习微服务之前, 需要先理解单体、集群、分布式这些概念，这样会帮助我们在学习后⾯课程会更加容易些。

单体

⼀个系统业务量很⼩的时候所有的代码都放在⼀个项⽬中就好了，然后这个项⽬部署在⼀台服务器上就好了。整个项⽬所有的服务都由这台服务器提供。这就是单机结构。

单体应⽤开发简单 , 部署测试简单 . 但是存在⼀些问题 , ⽐如 : 单点问题 , 单机处理能⼒有限 , 当你的业务增⻓到⼀定程度的时候，单机的硬件资源将⽆法满⾜你的业务需求。

分布式

由于整个系统运⾏需要使⽤到Tomcat 和 MySQL ，单台服务器处理的能⼒有限 ,2G 的内存需要分配给

Tomcat 和 MySQL 使⽤，，随着业务越来越复杂，请求越来越多 . 内存越来越不够⽤了，所以这时候我们就需要进⾏分布式的部署

我们进⾏⼀个评论的请求，这个请求是需要依赖分布在两台不同的服务器的组件 [Tomat 和 MySQL], 才能完成的 . 所以叫做分布式的系统。

集群

在上⾯的图解中其实是存在问题的，⽐如Tomcat 存在单点故障问题，⼀旦 Tomcat 所在的服务器宕机不可⽤了，我们就⽆法提供服务了 , 所以针对单点故障问题，我们会使⽤集群来解决 . 那什么是集群模式呢 ?

单机处理到达瓶颈的时候，你就把单机复制⼏份，这样就构成了⼀个 “ 集群 ” 。集群中每台服务器就叫做这个集群的⼀个 “ 节点 ” ，所有节点构成了⼀个集群。每个节点都提供相同的服务，那么这样系统的处理能⼒就相当于提升了好⼏倍（有⼏个节点就相当于提升了这么多倍）。

但问题是⽤户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较⼩的节点来处理，这样使得每个节点的压⼒都⽐较平均。要实现这个功能，就需要在所有节点之前增加⼀个 “ 调度者 ” 的⻆⾊，⽤户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个 “ 调度者 ” 有个⽜逼了名字——负载均衡服务器。

我们在上⾯的图中仅展示了 Tomcat 的集群，如果 MySQL 压⼒⽐较⼤的情况下，我们也是可以对 MySQL进⾏集群的。

1.2 系统架构演变

随着互联⽹的发展，⽹站应⽤的规模也不断的扩⼤，进⽽导致系统架构也在不断的变化。

从互联⽹早起到现在，系统架构⼤体经历了下⾯⼏个过程 : 单体应⽤架构 ---> 垂直应⽤架构 ---> 分布

式架构 --->SOA 架构 ---> 微服务架构。

接下来我们就来了解⼀下每种系统架构是什么样⼦的，以及各有什么优缺点。

1.2.1 单体应⽤架构

互联⽹早期，⼀般的⽹站应⽤流量较⼩，只需⼀个应⽤，将所有功能代码都部署在⼀起就可以，这

样可以减少开发、部署和维护的成本。

⽐如说⼀个电商系统，⾥⾯会包含很多⽤户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成⼀个 web 项⽬，然后部署到⼀台 tomcat 服务器上。

优点：

项⽬架构简单，⼩型项⽬的话，开发成本低

项⽬部署在⼀个节点上，维护⽅便

缺点：

全部功能集成在⼀个⼯程中，对于⼤型项⽬来讲不易开发和维护

项⽬模块之间紧密耦合，单点容错率低

⽆法针对不同模块进⾏针对性优化和⽔平扩展

1.2.2 垂直应⽤架构

随着访问量的逐渐增⼤，单⼀应⽤只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有⽐较⼤的访问量 . 还是以上⾯的电商为例⼦，⽤户访问量的增加可能影响的只是⽤户和订单模块，但是对消息模块的影响就⽐较⼩ . 那么此时我们希望只多增加⼏个订单模块，⽽不增加消息模块 . 此时单体应⽤就做不到了，垂直应⽤就应运⽽⽣了 .

所谓的垂直应⽤架构，就是将原来的⼀个应⽤拆成互不相⼲的⼏个应⽤，以提升效率。⽐如我们可以将上⾯电商的单体应⽤拆分成 :

电商系统 ( ⽤户管理商品管理订单管理 )

后台系统 ( ⽤户管理订单管理客户管理 )

CMS 系统 ( ⼴告管理营销管理 )

这样拆分完毕之后，⼀旦⽤户访问量变⼤，只需要增加电商系统的节点就可以了，⽽⽆需增加后台

和 CMS 的节点。

优点：

系统拆分实现了流量分担，解决了并发问题，⽽且可以针对不同模块进⾏优化和⽔平扩展

⼀个系统的问题不会影响到其他系统，提⾼容错率

缺点：

系统之间相互独⽴，⽆法进⾏相互调⽤

系统之间相互独⽴，会有重复的开发任务

1.2.3 分布式架构

当垂直应⽤越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统⼀的业务层作为独⽴的服务，然后由前端控制层调⽤不同的业务层服务呢？这就产⽣了新的分布式系统架构。它将把⼯程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和⻚⾯的交互，业务逻辑都是调⽤服务层的服务来实现。