微服务和Spring Cloud Alibaba介绍

微服务介绍

系统架构演变

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。

从互联网早起到现在，系统架构大体经历了下面几个过程: 单体应用架构—>垂直应用架构—>分布

式架构—>SOA架构—>微服务架构，当然还有悄然兴起的Service Mesh(服务网格化)。

单体应用架构

在互联网早期的时候家庭电脑都还没有普及，上网都是一件很新奇的事情，用户群体也很少，更别高并发高可用之类的，网站只需要实现最简单最基础的功能，所以刚开始互联网的应用都是一个单体应用架构。

比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，

我们会把它们做成一个web项目，打成war包然后部署到一台tomcat服务器上，数据库连接一个单体数据库。我们称之为 all in one 所有东西都在一台服务器上面。

优点：

• 项目架构简单，小型项目的话， 开发成本低
• 项目部署在一个节点上， 维护方便

缺点：

• 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护 

• 项目模块之间紧密耦合，单点容错率很低 一个功能出问题可能导致整个引用都挂掉
• 无法针对不同模块进行针对性优化和水平扩展  负载均衡只能对整个应用做，这样的效果也很低

目前互联网公司用的已经很少很少，主要在一些企业宣传网站，外包公司做的快速交互项目，学校学生练手项目

垂直应用架构

垂直应用架构就是把上面的单体应用拆分成几个互不相干的应用，做负载均衡的时候就不需要对整个应用了。

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量

还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块

的影响就比较小. 那么此时我们希望只多增加几个订单模块， 而不增加消息模块. 此时单体应用就做不到了， 垂直应用就 应运而生了。

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体 应用拆分成:

• 电商系统(用户管理 商品管理 订单管理)
• 后台系统(用户管理 订单管理 客户管理)
• CMS系统(广告管理 营销管理)

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台

和CMS的节点。

优点：

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

• 一个系统的问题不会影响到其他系统，提高容错率。

缺点：

• 拆分的若干系统之间相互独立，不能互相调用
• 系统之间相互独立， 会有重复的开发任务

在OA管理系统中用的多

分布式架构

把垂直架构中拆分的若干应用拥有的公共模块抽取出来，之前拆分的应用保持不变。非常适合刚起步公司的应用架构，

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

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务

逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

抽取公共的功能为服务层，提高代码复用性

缺点：

系统间耦合度变高，调用关系错综复杂，难以维护。现在需要进行RPC远程调用，调用关系复杂了

SOA架构

就是为了解决分布式当中调用关系错综复杂难以维护的问题。在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加 一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture)是关键。

优点:

• 使用治理中心（ESB\dubbo）解决了服务间调用关系的自动调节
• 同时SOA可以实现协调 调用协议不同，开发语言不同导致的问题

缺点：

• 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
• 服务关系复杂，运维、测试部署困难

微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。

微服务架构与SOA架构的不同

微服务架构比 SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。

SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。

项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

当然拆分粒度视业务复杂程度而定。

优点：

• 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展

• 微服务之间采用Restful等轻量级http协议相互调用

缺点：

• 分布式系统开发的技术成本高（容错、分布式事务等）

• 复杂性更高。各个微服务进行分布式独立部署，当进行模块调用的时候，分布式将会变得更加麻烦。

微服务架构介绍

作者 

Martin Fowler

他写的文章

①：英文:https://martinfowler.com/articles/microservices.html

②: 中文:http://blog.cuicc.com/blog/2015/07/22/microservices

​​​​​​​

他说微服务其实是一种架构风格，我们在开发一个应用的时候这个应用应该是由一组小型服务组成，每个小型服务都运行在自己的进程内；小服务之间通过HTTP的方式进行互联互通。

作为单体应用，当访问压力变大的时候使用负载均衡并不能起到很好的效果，模块之前的耦合太严重可能造成服务器性能的浪费。

微服务经过更细密度的拆分，有利于业务的扩展等。

微服务常见的问题及解决方法：

1.这么多小服务，如何管理他们？服务治理，注册中心，【服务注册，发现，剔除】nacos

一个服务需要去调用其它多个服务，按以前的逻辑我们就需要知道这些服务的远程地址，这些远程地址有可能会频繁的变化，这样子对于服务本身去维护这些远程地址就非常的麻烦，所以就有了微服务治理方法-注册中心nacos

注册中心nacos：可以管理我们所有的服务，所有的服务都通过自己定义的名字注册到nacos中去，然后服务调用的时候只需要通过这些名字去调用就可以实现远程调用了。同时当一个服务出问题了，ncoas会自动剔除掉它

2.这么多小服务，服务与服务之间是如何通信的呢？

早期的时候需要进行远程服务调用的时候，我们就会用到java提供的httpClient(url,"参数")调用http协议的接口。

但是在微服务当中，服务之间的接口都是RestFul协议的接口(json传输)，如果用httpClient 调用的时候就需要把参数转为json 并把返回的json数据转为指定的对象，就涉及到数据的序列化和反序列化这样子就会很麻烦。

spring-boot提供了这样一种自动转换的方法 叫做RestTemplate(url，“参数”)专门调用Rest接口的远程服务，免去了序列化和反序列化的过程

spring-cloud提供了这样一种解决方法-Feign ,它的作用使得服务与服务之间的调用就像调用自己应用里的方法一样简单。

3.这么多小服务客户端如何去访问呢？

前端去访问后端的多个服务，这些服务的远程地址都是不一样的，我们可以通过网关来管理我们的服务，前端统一的去请求网关，然后网关统一路由到对应的服务，这样就免去了跨域的问题，网关还可以实现认证授权等功能。

4.这么多小服务，一旦出现问题了，应该如何自处理？(容错) sentinel

比如说在一个扇出的服务当中，有一个短信服务，短信服务出现了问题，那么整个调用链路就出现了问题-服务雪崩 ，这个时候我们就可以用容错的机制对这个服务进行降级，对这次调用做记录，使用MQ之后再进行补偿就行了

5.这么多小服务，一旦出现问题了，应该如何排错? (链路追踪) skywalking

再好的应用也避免不了会出错，当出错的时候对于微服务我们应该怎么去追踪排查呢？

通过链路追踪 定位到具体是哪个服务出现了问题。

对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一

个问题提供了相应的组件来解决它们。

1.首先客户端发送请求，首先会到网关，一个网关压力太大我们就会实现负载均衡，在客户端到网关之间加一个负载均衡。

2.网关会从nacos注册中心中通过注册名称找到对应的微服务，调用服务之前会实现sentLnel容错机制，防止服务的雪崩等一些问题

3.服务和服务之间的调用会采用Feign

4.服务使用的redis，mq，oss等一些中间件

5.服务使用到数据库就会使用到SEATA 保持分布式事务保持事物的一致性

常见的微服务架构

1.dubbo: zookeeper +dubbo + SpringMVC/SpringBoot

• 配套 通信方式：rpc
• 注册中心：zookeeper / redis
• 配置中心：diamond

这一套也只能实现治理中心，比如说服务熔断，链路追踪等dubbo基本上还是不支持的，所以有时候还是得结合spring-cloud来玩

2..SpringCloud：全家桶+轻松嵌入第三方组件(Netflix)

• 配套 通信方式：http restful
• 注册中心：eruka / consul
• 配置中心：config
• 断 路 器：hystrix
• 网关：zuul
• 分布式追踪系统：sleuth + zipkin

Netfix已经闭源了，不再更新了，如果出现问题而闭源又不会更新，所以尽量还是不要用了。

3.SpringCloud Alibaba （目前的主流）

Spring Cloud 以微服务为核心的分布式系统构建标准

“分布式系统中的常见模式”给了 Spring Cloud 一个清晰的定位，即“模式”。也就是说 Spring Cloud 是针对分布式系统开发所做的通用抽象， 是标准模式的实现。这个定义非常抽象，看完之后并不能知道 Spring Cloud 具体包含什么内容。再来看一下 Spring 官方给出的一个 High Light 的

架构图，就可以对这套模式有更清晰的认识：

可以看到这个图中间就是各个 Microservice，也就是我们的这个微服务的实现，周边周围的话就是去围绕这个微服务来去做各种辅助的信息事情。

例如分布式追踪、服务注册、配置服务等，都绕微服务运行时所依赖的必不可少的的支持性功能。我们可以得出这样一个结论：Spring Cloud 是以 微服务为核心的分布式系统的一个构建标准。

Spring Cloud Alibaba 介绍

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发微服务架构的必需组件，方便开发者 通过 Spring Cloud 编程模型轻松使用这些组件来开发微服务架构。

依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解 决方案，通过阿里中间件来迅速搭建分布式应用系统。