SpringCloud篇

SOA 和微服务的区别?(必会)

谈到 SOA 和微服务的区别, 那咱们先谈谈架构的演变

1. 集中式架构

项目功能简单, 一个项目只需一个应用, 将所有功能部署在一起, 这样的架构好处是减 少了部署节点和成本

sofaboot如何做到微服务开发 微服务架构较soa的优势_dubbo


缺点: 代码耦合，开发维护困难, 无法水平扩展, 单点容错率低，并发能力差2. 垂直拆分架构

当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我 们根据业务功能对系统进行拆分：

sofaboot如何做到微服务开发 微服务架构较soa的优势_java_02


优点：

  • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同模块进行优化, 方便水平扩展，负载均衡，容错率提高

缺点：
系统间相互独立，会有很多重复开发工作，影响开发效率

3. 分布式服务

当垂直应用越来越多, 随着项目业务功能越来越复杂, 并非垂直应用这一条线进行数据调用, 应用和应用之间也会互相调用, 也就是完成某一个功能,需要多个应用互相调用, 这就是将功能拆完来完成的分布式架构.

sofaboot如何做到微服务开发 微服务架构较soa的优势_sofaboot如何做到微服务开发_03


优点:

将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率.

缺点:
系统间耦合度变高，调用关系错综复杂，难以维护.

4. 服务治理架构 SOA
SOA ：面向服务的架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键, 而最初的服务治理基石是 Dubbo 服务治理.

sofaboot如何做到微服务开发 微服务架构较soa的优势_dubbo_04


以前分布式服务的问题？

  • 服务越来越多，需要管理每个服务的地址, 调用关系错综复杂，难以理清依赖关系
  • 服务过多，服务状态难以管理，无法根据服务情况动态管理

SOA 服务治理架构的优点:

  • 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址.
  • 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系 .
  • 动态监控服务状态监控报告，人为控制服务状态 .

SOA 服务治理架构的缺点:

  • 服务间依然会有依赖关系，一旦某个环节出错会影响较大(容错机制)
  • 服务关系复杂，运维、测试部署困难，不符合开发-运维一站式维护的思想.

5. 微服务
前面说的 SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行 拆分。因此两者非常容易混淆，但其实缺有一些差别：

微服务的特点：

  • 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责.
  • 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
  • 面向服务：面向服务是说每个服务都要对外暴露 Rest 风格服务接口 API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供 Rest 的接口即可。
  • 自治：自治是说服务间互相独立，互不干扰
  • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
  • 技术独立：因为是面向服务，提供 Rest 接口，使用什么技术没有别人干涉
  • 前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、 移动段开发不同接口
  • 数据库分离：每个服务都使用自己的数据源
  • 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合， 易维护. 基于 docker 容器是开发.

    目前微服务微服务架构主流的是 SpringBoot+Dubbo 和 SpringBoot+SpringCloud的架构模式.

综上, 无论是 SOA 还是微服务, 都需要进行服务调度, 目前主流的服务调度室 RPC 和 HTTP 两种协议, 而 Dubbo 基于 RPC 的远程调度机构, SpringCloud 是基于 Rest 风格(基于 http 协议实现的)的 Spring 全家桶微服务服务治理框架. 说到这里也可以继续说下 Dubbo 和 SpringCloud 的区别.

SpringCloud 是什么?(了解)

SpringCloud 是一系列框架的集合，集成 SpringBoot，提供很多优秀服务：服务发现和注册，统一配置中心, 负载均衡，网关, 熔断器等的一个微服务治理框架.

SpringCloud 的优势?(了解)

  • 因为 SpringCloud 源于 Spring，所以它的质量，稳定性，持续性都是可以保证的。
  • SpringCloud 天热支持 SpringBoot 框架，就可以提高开发效率，能够实现需求。
  • SpringCloud 更新很快，后期支持很给力。
  • SpringCloud 可以用来开发微服务。

SpringCloud 有哪些核心组件?(必会)

  • Eureka: 注册中心, 服务注册和发现
  • Ribbon: 负载均衡, 实现服务调用的负载均衡
  • Hystrix: 熔断器
  • Feign: 远程调用
  • Gateway: 网关
  • Spring Cloud Config: 配置中心

(1)Eureka
提供服务注册和发现, 是注册中心. 有两个组件: Eureka 服务端和 Eureka 客户端

Eureka 服务端: 作为服务的注册中心, 用来提供服务注册, 支持集群部署.
Eureka 客户端: 是一个 java 客户端, 将服务注册到服务端, 同时将服务端的信息缓存到本地, 客户端和服务端定时交互.

  1. 原理
  • Eureka-Server：就是服务注册中心（可以是一个集群），对外暴露自己的地址。
  • 提供者：启动后向 Eureka 注册自己信息（地址，服务名称等），并且定期进行服务续约
  • 消费者：服务调用方，会定期去 Eureka 拉取服务列表，然后使用负载均衡算法选出一 个服务进行调用。
  • 心跳(续约)：提供者定期通过 http 方式向 Eureka 刷新自己的状态
  1. 服务下线、失效剔除和自我保护
    * 服务的注册和发现都是可控制的，可以关闭也可以开启。默认都是开启
    * 注册后需要心跳，心跳周期默认 30 秒一次，超过 90 秒没发心跳认为宕机
    * 服务拉取默认 30 秒拉取一次.
    * Eureka 每个 60 秒会剔除标记为宕机的服务
    * Eureka 会有自我保护，当心跳失败比例超过阈值(默认 85%)，那么开启自我保护，不再剔除服务。
    * Eureka 高可用就是多台 Eureka 互相注册在对方上.
    (2)Ribbon
    * Ribbon 是 Netflix 发布的云中服务开源项目. 给客户端提供负载均衡, 也就是说 Ribbon 是作用在消费者方的.
    * 简单来说, 它是一个客户端负载均衡器, 它会自动通过某种算法去分配你要连接的机器.
    * SpringCloud 认为 Ribbon 这种功能很好, 就对它进行了封装, 从而完成负载均衡.
    * Ribbon 默认负责均衡策略是轮询策略.
    (3)Hystrix 熔断器
    有时候可能是网络问题, 一些其它问题, 导致代码无法正常运行, 这是服务就挂了, 崩溃了. 熔断器就是为了解决无法正常访问服务的时, 提供的一种解决方案.
    解决因为一个服务崩溃而引起的一系列问题, 使问题只局限于这个服务中,不会影响其他服务.
    Hystrix 提供了两种功能, 一种是服务降级, 一种是服务熔断.
    服务降级原理:
  • Hystrix 为每个服务分配了小的线程池, 当用户发请求过来, 会通过线程池创建线程来执行任务, 当创建的线程池已满或者请求超时(这里和多线程线程池不一样,不存在任务队列), 则启动服务降级功能.
  • 降级指的请求故障时, 不会阻塞, 会返回一个友好提示(可以自定义, 例如网站维护中请稍后重试), 也就是说不会影响其他服务的运行.

服务熔断原理:

sofaboot如何做到微服务开发 微服务架构较soa的优势_分布式_05


状态机有 3 个状态：

  • Closed：关闭状态（断路器关闭），所有请求都正常访问。
  • Open：打开状态（断路器打开），所有请求都会被降级。Hystix 会对请求情况计数， 当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是 50%，请求次数最少不低于 20 次。
  • Half Open：半开状态，open 状态不是永久的，打开后会进入休眠时间（默认是 5S）。 随后断路器会自动进入半开状态。此时会释放 1 次请求通过，若这个请求是健康的， 则会关闭断路器，否则继续保持打开，再次进行 5 秒休眠计时。

(4)Feign: 远程调用组件

  • 后台系统中, 微服务和微服务之间的调用可以通过 Feign 组件来完成.
  • Feign 组件集成了 Ribbon 负载均衡策略(默认开启的, 使用轮询机制), Hystrix 熔断器 (默认关闭的, 需要通过配置文件进行设置开启)
  • 被调用的微服务需要提供一个接口, 加上@@FeignClient(“url”)注解
  • 调用方需要在启动类上加上@EnableFeignClients, 开启 Feign 组件功能.

(5)Gateway: 路由/网关

  • 对于项目后台的微服务系统, 每一个微服务都不会直接暴露给用户来调用的, 但是如果用户知道了某一个服务的 ip:端口号:url:访问参数, 就能直接访问你. 如果再是恶意访问, 恶意攻击, 就会击垮后台微服务系统.因此, 需要一个看大门的大 boss, 来保护我们的 后台系统.
  • Gateway 支持过滤器功能，对请求或响应进行拦截，完成一些通用操作。
  • Gateway 提供两种过滤器方式：“pre”和“post” .
  • pre 过滤器，在转发之前执行，可以做参数校验、权限校验、流量监控、日志输出、 协议转换等。
  • post 过滤器，在后端微服务响应之后并且给前端响应之前执行，可以做响应内容、 响应头的修改，日志的输出，流量监控等。
  • Gateway 还提供了两种类型过滤器

(一) GatewayFilter：局部过滤器，针对单个路由

  1. GatewayFilter 局部过滤器，是针对单个路由的过滤器。
  2. 在 Spring Cloud Gateway 组件中提供了大量内置的局部过滤器，对请求和响应做过滤操作.
  3. 遵循约定大于配置的思想，只需要在配置文件配置局部过滤器名称，并为其指定对应的值，就可以让其生效.

(二) GlobalFilter ：全局过滤器，针对所有路由.
1.GlobalFilter 全局过滤器，不需要在配置文件中配置，系统初始化时加载，并作用在每个路由上。

2.Spring Cloud Gateway 核心的功能也是通过内置的全局过滤器来完成。

3.自定义全局过滤器步骤：

  • 定义类实现 GlobalFilter 和 Ordered 接口
  • 复写方法
  • 完成逻辑处理

(6)Spring Cloud Config
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。
在 Spring Cloud 中，有分布式配置中心组件 spring Cloud Config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程 Git 仓库中.

SpringBoot 和 SpringCloud 的关系(必会)

  • SpringBoot 是为了解决 Spring 配置文件冗余问题, 简化开发的框架.
  • SpringCloud 是为了解决微服务之间的协调和配置问题, 还有服务之间的通信, 熔断, 负载均衡远程调度任务框架.
  • SpringCloud 需要依赖 SpringBoot 搭建微服务, SpringBoot 使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，SpringCloud 很大的一部分是基于 SpringBoot 来实现。
  • SpringBoot 不需要依赖 SpringCloud 就可以独立开发. SpringBoot 也可以集成 Dubbo 进行开发.

SpringCloud 和 Dubbo 的区别(高薪常问)

SpringCloud 和 Dubbo 都是主流的微服务架构.

  • SpringCloud 是 Apache 下的 Spring 体系下的微服务解决方案.
  • Dubbo 是阿里系统中分布式微服务治理框架.

技术方面对比

  • SpringCloud 功能远远超过 Dubbo, Dubbo 只实现了服务治理(注册和发现). 但是 SpringCloud 提供了很多功能, 有 21 个子项目
  • Dubbo 可以使用 Zookeeper 作 为 注 册 中 心 , 实现服务的注册和发现 , SpringCloud 不仅可以使用 Eureka 作为注册中心, 也可以使用 Zookeeper 作为 注册中心.
  • Dubbo 没有实现网关功能, 只能通过第三方技术去整合. 但是 SpringCloud 有 zuul 路由网关, 对请求进行负载均衡和分发. 提供熔断器, 而且和 git 能完美集成.

性能方面对比

  • 由于 Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配 以 Hession 序列化完成 RPC。
  • 而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的，相对来说，Http 请求会有更大的报文，占的带宽也会更多。
  • 使用 Dubbo 时, 需要给每个实体类实现序列化接口, 将实体类转化为二进制进行 RPC 通信调用.而使用 SpringCloud 时, 实体类就不需要进行序列化.

刚才有提到注册中心不一样,那么 Eureka 和 Zookeeper 有什么区别? 我们继续往 下说~

Eureka 和 Zookeeper 的区别(高薪常问)

在谈这个问题前我们先看下 CAP 原则: C(Consistency)-数据一致性; A(Availability)- 服务可用性; P(Partition tolerance)-服务对网络分区故障的容错性, 这三个特性在任何分布式系统中不能同时满足, 最多同时满足两个, 而且 P(分区容错性)是一定要满足的.

  • Eureka 满足 AP(服务可用性和容错性), Zookeeper 满足 CP(数据一致性和容错性)
  • Zookeeper 满足 CP, 数据一致性, 服务的容错性. 数据在各个服务间同步完成后才能回用户结果, 而且如果服务出现网络波动导致监听不到服务心跳, 会立即从服务列表中剔除, 服务不可用.
  • Eureka 满足 AP, 可用性, 容错性. 当因网络故障时, Eureka 的自我保护机制不会立即 剔除服务, 虽然用户获取到的服务不一定是可用的, 但至少能够获取到服务列表. 用户访问服务列表时还可以利用重试机制, 找到正确的服务. 更服务分布式服务的高可用需求.
  • Eureka 集群各节点平等, Zookeeper 集群有主从之分.
  1. 如果 Zk 集群中有服务宕机,会重新进行选举机制,选择出主节点, 因此可能会导致整个集群因为选主而阻塞, 服务不可用.
  2. Eureka 集群中有服务宕机,因为是平等的各个服务器,所以其他服务器不受影响.
  • Eureka 的服务发现者会主动拉取服务, ZK 服务发现者是监听机制
  1. Eureka 中获取服务列表后会缓存起来, 每隔 30 秒重新拉取服务列表.
  2. Zk 则是监听节点信息变化, 当服务节点信息变化时, 客户端立即就得到通知.