SpringCloud基本认知

一.架构演变

1.单体

1.1.概念:

所有的模块，组件等都在一个应用中应用最终打成一个(war,jar)包使用一个容器(Tomcat)进行部署，通常一个应用享用一个数据库。
在单体应用中我们通常把应用分为三个组成部分：持久层，业务层，表现层

1.2.缺点:

1.单节点故障
2.高并发不支持
3.代码臃肿

2.集群/多实例

2.1.概念:

集群指的是把应用进行复制多个相同的应用一起工作来提高作业能力，多个应用做的是相同的事情。

2.2.作用:

一定程度上解决单节点故障和高并发问题

2.3.负载均衡:

2.3.1.概念:

负载均衡（Load Balancing）是指在分布式系统中，将工作负载（包括请求和数据）平均地分配给多个服务器，以实现更高的性能、可靠性和可扩展性。
负载均衡可以由专用的负载均衡设备（硬件负载均衡器）或软件来实现，例如Nginx、Apache等。常见的应用场景包括Web服务器集群、数据库集群、应用服务器集群等。

2.3.2.算法:

1. 基于轮询（Round-robin）：按照固定顺序轮流将请求分发给服务器。这是最简单的负载均衡策略，适用于服务器性能相近的情况。

2. 基于权重（Weighted）：给每个服务器分配一个权重，根据权重比例分发请求。可以根据服务器性能或运行状态来设置不同的权重。

3. 基于最少连接（Least Connection）：将请求发送到当前连接数最少的服务器上。这种策略可以避免把大量请求发送到已有较多连接的服务器上，达到负载均衡的效果。

4. 基于IP哈希（IP Hash）：根据请求的源IP地址计算哈希值，然后将请求发送到对应的服务器。这种策略可以确保相同的请求总是发送到同一台服务器上，适用于需要保持会话或状态的应用。

5. 动态负载均衡：根据服务器的运行状态、负载情况、响应时间等动态调整负载均衡策略，以达到更好的性能和资源利用。

3.分布式/SOA

3.1.概念:

分布式就是将应用按照业务进行拆分成多个子应用，多个子应用部署在不同的服务器中，多个子应用组成一个完整的系统

3.2.SOA:

SOA也是分布式架构，我们可以简单的理解为SOA把分布式架构划分成表示层和服务层，服务层中包含了业务逻辑和相关流程，只需要对外暴露服务即可，表现层负责处理和页面的交互。

4.微服务

4.1.概念:

微服务架构可以认识是在SOA架构上的一种发展。
微服务就是把单一应用进行细粒度的拆分成多个小(微)的服务相，每个服务独立运行，每个服务只需要专注一个业务即可，并且每个服务都可以有自己的数据库(分库)，服务之间互协调配合完成整个系统的业务

4.2.特点:

- 由多个服务组成完整的系统
- 每个服务都是独立的，有自己的进程
- 服务之间使用HTTP协议通信
- 不同的服务可以使用不同的编程语言
- 不同的服务的数据库可以多样化选择
- 微服务是一个分布式系统

二.SpringCloud

1.认识SpringCloud

1.1.概念:

Spring cloud是一个基于Spring Boot实现的服务治理工具包`，`用于微服务架构中管理和协调服务的`。
Spring Cloud是一系列框架的有序集合。

1.2.SpringCloud常用组件

Netflix Eureka

当我们的微服务过多的时候，管理服务的通信地址是一个非常麻烦的事情，Eureka就是用来管理微服务的通信地址清单的，有了Eureka之后我们通过服务的名字就能实现服务的调用。

Netflix Ribbon\Feign : 客户端负载均衡

Ribbon和Feign都是客户端负载均衡器，它的作用是在服务发生调用的时候帮我们将请求按照某种规则分发到多个目标服务器上，简单理解就是用来解决微服务之间的通信问题。

Netflix Hystrix ：断路器

微服务的调用是非常复杂的，有的时候一个请求需要很多的微服务共同完成，那么一旦某个服务发生故障，导致整个调用链上的微服务全都出现异常，甚至导致整个微服务架构瘫痪。Hystrix就是用来解决微服务故障，保护微服务安全的组件。

Netflix Zuul ： 服务网关

zuul作为服务网关，我们可以把它看作是微服务的大门，所有的请求都需要经过zuul之后才能到达目标服务，根据这一特性，我们可以把微服务公共的是事情交给zuul统一处理，如：用户鉴权，请求监控等。

Spring Cloud Config ：分布式配置

微服务架构中的服务实例非常的多，服务的配置文件分散在每个服务中，每次修改服务的配置文件和重新服务实例都是一个很麻烦的工作，Spring Cloud Config作为分布式配置管理中心就是用来统一的管理服务的配置文件。

Spring Cloud Bus : 消息总线

消息总线是在微服务中给各个微服务广播消息的一个组件，我们使用消息总线构建一个消息中心，其他微服务来接入到消息中心，当消息总线发起消息，接入的微服务都可以收到消息从而进行消费。

Spring Cloud sleuth :微服务链路追踪

当我们的应用采用微服务架构之后，后台可能有几十个甚至几百个服务在支撑，一个请求请求可能需要多次的服务调用最后才能完成，链路追踪的作用就是来监控维护之间的调用关系,让程序员方便直观的感受到一个请求经历了哪些微服务，以及服务的请求时间，是否有异常等。

2.服务通信协议

2.1.RPC

RPC(Remote Produce Call)远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型

2.2.Http

Http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。 现在热门的Rest风格，就可以通过http协议来实现

我们可以认为SpringCloud就是基于Http协议实现服务之间的通信。

3. SpringCloud与Dubbo

3.1.Dubbo简介

Dubbo最早是有阿里巴巴提供的一个服务治理和服务调用框架，现在已经成为Apache的顶级项目，Dubbo跟SpringCloud最显著的区别是Dubbo的定位只是一个RPC框架，相比SpringCloud来说它缺少很多功能模块，如：网关，链路追踪等，所以往往在使用Dubbo作为微服务开发框架的时候，还需要去配合其他的框架一起使用，如:加入zookeeper作为注册中心。

3.2.SpringCloud与Dubbo的区别

定位不一样

SpringCloud为了微服务的落地提供了一套完整的组件，而Dubbo只是一个RPC框架，缺失的功能很多。

通信协议不一样

Dubbo的通信方式是RPC，基于原声的tcp,性能较好，而SpringCloud的通信方式基于Http协议，虽然底层基于tcp，但是Http的封装过于臃肿，但是使用Http好处在于互相通信的两个服务可以使用不同的变成语言去编写，只要他们都支持Http通信即可互相调用，而Dubbo只支持Java,当然Dubbo交给Apache维护之后做了升级，Dubbo在以后不仅仅支持Java。

开发风格

从开发风格上来讲，Dubbo官方推荐倾向于使用Spring xml配置方式，SpringCloud是基于SpringBoot的开发风格，即采用注解的方式进行配置，从开发速度上来说，SpringCloud具有更高的开发和部署速度。