2022 年最新基于 Spring Cloud 的微服务架构分析,mysql 面试笔试题

Posted 蒙娜丽莎的Java

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了2022 年最新基于 Spring Cloud 的微服务架构分析,mysql 面试笔试题相关的知识,希望对你有一定的参考价值。

Feign 的动态代理会根据在接口上的 @RequestMapping 等注解,来动态构造要请求的服务的地址

针对这个地址,发起请求、解析响应

Feign 是和 Ribbon 以及 Eureka 紧密协作的

首先 Ribbon 会从 Eureka Client 里获取到对应的服务注册表,也就知道了所有的服务都部署在了哪些机器上,在监听哪些端口

然后 Ribbon 就可以使用默认的 Round Rob
in 算法,从中选择一台机器

  • Feign 就会针对这台机器,构造并发起请求

6. Config(分布式配置)

=================

配置管理工具包,让你可以把配置放到远程服务器,集中化管理集群配置,目前支持本地存储、Git 以及 Subversion。

注册中心与 API 网关的分析

=============

微服务网关更多是在前后端分离,或者说涉及到独立的类似手机 APP 等前端应用的时候使用的最多,即把内部各个微服务组件模块的 API 接口能力统一注册和接入到网关,对于 APP 也只需要访问网关暴露的接口即可,同时通过网关还可以进一步的实现安全隔离。

也就是说在这种场景下,网关更多的是实现了接口服务的代理和路由转发能力,更多的是向外的一种能力发布。

  1. 一个独立的开发团队,为保证独立自治,以及内部多个微服务模块间的交互集成,最好启用独立的服务注册中心实现服务注册,发现能力。即开发团队内部多个微服务模块间的集成,不需要通过网关,只需要通过服务注册中心进行集成即可。

  2. 开发团队需要暴露能力给外部,包括暴露能力给其它的开发团队,需要考虑将该 API 接口注册到外部的网关上。在这里建议是拆分两个独立网关,一个是内部 API 网关,一个是放置到 DMZ 区面对公网访问的 API 网关。对于服务如果同时涉及到内部和外部使用,则两边注册。建议不要通过两次网关去路由,一个是影响性能,一个是不方便后续问题排查。

  3. 构建在开发团队之外的 API 网关必须具备负载均衡能力,可以配置多个 IP 地址。通过该 API 网关也最好具备和 Docker 容器扩展后的服务自动注册和地址加入扩展能力。


Eureka 的竞品分析:Nacos、ZooKeeper、Etcd

=================================

服务发现是一个古老的话题,当应用开始脱离单机运行和访问时,服务发现就诞生了。目前的网络架构是每个主机都有一个独立的 IP 地址,那么服务发现基本上都是通过某种方式获取到服务所部署的 IP 地址。DNS 协议是最早将一个网络名称翻译为网络 IP 的协议,在最初的架构选型中,DNS+LVS+nginx 基本可以满足所有的 RESTful 服务的发现,此时服务的 IP 列表通常配置在 Nginx 或者 LVS。后来出现了 RPC 服务,服务的上下线更加频繁,人们开始寻求一种能够支持动态上下线并且推送 IP 列表变化的注册中心产品。

Eureka

======

  • Spring Cloud Eureka 所选择的是 AP,采用的是去中心化结构,放弃了强一致性。也就是说 Eureka 集群中的各个结点都是平等的,没有主从的概念。通过互相注册的方式来进行消息同步和保证高可用。并且一个 Eureka Server 结点挂掉了,还有其他同等的结点来提供服务,并不会引发服务的中断

  • Eureka 只能当注册中心,想搞配置中心的话,还得搭配 Spring Cloud Config+Spring Cloud Bus。其中后者支持 Rabbiimq 和 Kafka 两种模式。

  • 使用 Java 语言来开发的,并且也是 Spring Cloud 的子项目,所以可以直接通过引入 jar 包的方式来集成 Eureka,这点非常方便

1. ZooKeeper

=============

这是一款经典的服务注册中心产品(虽然它最初的定位并不在于此),在很长一段时间里,它是国人在提起 RPC 服务注册中心时心里想到的唯一选择,这很大程度上与 Dubbo 在中国的普及程度有关。

  • Apache Zookeeper 所选择的是 CP,也就是放弃了高可用性。Zookeeper 集群在进行消息同步的时候,必须有一半以上结点完成了同步才会返回;而当 Master 结点挂了或者集群中有过半的结点不能工作了,此时就会触发故障恢复,重新进行 Master 选举。在这个过程中,整个 Zookeeper 集群无法对外提供服务,从而实去了 A(可用性)

  • 为了达到 C,Zookeeper 采用的是自己的 ZAB 协议。

2. Nacos

=========

Nacos 是阿里巴巴旗下的开源项目,在 2018 年开源,携带着阿里巴巴大规模服务生产经验,试图在服务注册和配置管理这个市场上,提供给用户一个新的选择。

  • Nacos 一大特性是即支持 CP,也支持 AP。可以根据需要灵活选择。

  • Nacos 除了注册中心之外,也能充当配置中心的作用。且配置中心可以按照 namespace,group 等维度来进行数据隔离,来达到不同环境之间配置隔离的功能。

值得一提的是,Nacos 作为配置中心的持久化机制可以依赖于 mysql 来完成(默认依赖于内置数据库)。只需要将 Nacos 目录下的 sql 脚本放到 mysql 中执行(会生成 11 个表),然后在 nacos 配置文件里面配一下 mysql 的账号密码即可。这样使用 mysql 作为数据源的方式相比于 nacos 内置数据库来说更容易管理

3. Consul

==========

Consul 是 HashiCorp 公司推出的一个开源工具。

  • Consul 是用 Go 语言编写的,所以无法像 Eureka 那样直接引入 jar 包就能集成,它还需要去服务器中进行额外的安装。

  • 除了注册中心的功能之外,Consul 还能起到配置中心的作用。

Consul 它保证的是 CP,使用 raft 协议,要求必须有过半的结点都写入成功才算是注册成功了,并且它也有 Master 和 Follower 的概念,在 Master 挂掉后,也需要自己内部进行

4. Etcd(待续)

============

对比 SpringCloud,Kubernetes 也提供完整的分布式微服务管理框架,几乎所有组件都有对应的产品,其中 Etcd 也可以提供类似 Eureka 的注册中心。

在 Go 生态中,还可以选择基于 Etcd 作为注册中心,Etcd 是由 CoreOS 团队维护的、高可用分布式键值存储数据库,可用于为集群提供配置和服务发现功能,Google 开源的容器管理工具 Kuberbetes 就是基于 Etcd 的。

和 Consul 一样,Etcd 也是基于 Raft 协议作为分布式一致性算法来解决领导者选举和日志复制问题,同样也是基于 Go 语言编写。

Etcd 也支持代理模式(proxy),只不过在 Etcd 中,代理模式和 Consul 的客户端代理模式类似,安装在部署服务的节点上,用来转发请求到 Etcd 集群,本身不存储任何数据,Etcd 集群相当于 Consul 中以服务端模式运行的 Consul 集群,通常要求配置三个及以上节点(不要太多,3~5 就够了,以便可用性和性能上达到平衡),负责真正的请求处理 —— 服务注册与发现。

在目前最新版本的 Etcd v3 中,通过网关模式(gateway)取代了 V2 版本中的代理模式(proxy)。

从服务发现的实现原理上来说,Consul 和 Etcd 的基本设计思路是一致的,Etcd 更简单,Consul 则更像一个全栈的解决方案,功能比 Etcd 要更丰富,比如支持可视化的 Web UI 管理界面、支持多数据库中心、安全层面除了 HTTPS 外还支持 ACL、更加全面的健康检查功能、内置 DNS Server 等,这些都是 Etcd 所不具备的,但是更全面的功能往往意味着更高的复杂性,针对微服务的服务注册和发现场景,Etcd 完全够用了。


Spring Cloud 全家桶的简介

===================

  • Spring Cloud Config:配置管理工具包,让你可以把配置放到远程服务器,集中化管理集群配置,目前支持本地存储、Git 以及 Subversion。

  • Spring Cloud Bus:事件、消息总线,用于在集群(例如,配置变化事件)中传播状态变化,可与 Spring Cloud Config 联合实现热部署。

  • Eureka:云端服务发现,一个基于 REST 的服务,用于定位服务,以实现云端中间层服务发现和故障转移。

  • Hystrix:熔断器,容错管理工具,旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

  • Zuul:Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。

  • Archaius:配置管理 API,包含一系列配置管理 API,提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。

  • Consul:封装了 Consul 操作,Consul 是一个服务发现与配置工具,与 Docker 容器可以无缝集成。

  • Spring Cloud for Cloud Foundry:通过 Oauth2 协议绑定服务到 CloudFoundry,CloudFoundry 是 VMware 推出的开源 PaaS 云平台。

  • Spring Cloud Sleuth:日志收集工具包,封装了 Dapper 和 log-based 追踪以及 Zipkin 和 HTrace 操作,为 Spring Cloud 应用实现了一种分布式追踪解决方案。

  • Spring Cloud Data Flow:大数据操作工具,作为 Spring XD 的替代产品,它是一个混合计算模型,结合了流数据与批量数据的处理方式。

  • Spring Cloud Security:基于 Spring Security 的安全工具包,为你的应用程序添加安全控制。

  • Spring Cloud Zookeeper:操作 Zookeeper 的工具包,用于使用 Zookeeper 方式的服务发现和配置管理。

  • Spring Cloud Stream:数据流操作开发包,封装了与 Redis、Rabbit、Kafka 等发送接收消息。

  • Spring Cloud CLI:基于 Spring Boot CLI,可以让你以命令行方式快速建立云组件。

  • Ribbon:提供云端负载均衡,有多种负载均衡策略可供选择,可配合服务发现和断路器使用。

  • Turbine:Turbine 是聚合服务器发送事件流数据的一个工具,用来监控集群下 Hystrix 的 Metrics 情况。

  • Feign:Feign 是一种声明式、模板化的 HTTP 客户端。

  • Spring Cloud Task:提供云端计划任务管理、任务调度。

  • Spring Cloud Connectors:便于云端应用程序在各种 PaaS 平台连接到后端,如:数据库和消息代理服务。

  • Spring Cloud Cluster:提供 Leadership 选举,如:Zookeeper,Redis,Hazelcast,Consul 等常见状态模式的抽象和实现。

  • Spring Cloud Starters:Spring Boot 式的启动项目,为 Spring Cloud 提供开箱即用的依赖管理。

本书适合具有一定 Java 基础和 Spring MVC 基础的人群以及希望往架构师方向发展的开发者阅读。

书籍教程结构

======

本书共分四部分,从基础到实战,讲解了基于 Spring Cloud 的常用组件。

第一部分(基础篇):第 1~4 章

第二部分(实战篇):第 5~10 章

第三部分(高级篇):第 11~13 章

第四部分(部署篇):第 14~15 章

第一部分(基础篇)

=========

第 1 章微服务概述

我们要学习微服务架构,就要了解它,本章将带领大家初步了解微服务,为后面系统学习微服务架构奠定良好的基础。

第 2 章 Spring Boot 基础

本书以实战为导向,讲解了如何使用 Spring Cloud 开发微服务项目,而 Spring Cloud 基于 SpringBoot,所以本章先来初步了解如何使用 Spring Boot 搭建框架。

第 3 章 Spring Boot 核心原理

通过第 2 章的学习,读者应该对 Spring Boot 有了一个大致的认识,利用 Spring Boot 可以极大地简化应用程序的开发,这都归功于 Spring Boot 的四大核心原理:起步依赖、自动配置、Actuator 和 Spring Boot 命令行。本章中,我们将深入探讨 Spring Boot 的核心原理,以便读者能更好地学习和使用 Spring Boot。

第 4 章 Spring Cloud 概述

从本章开始,我们将正式踏上探索 Spring Cloud 秘密的旅程。学完本书后,读者将学会搭建一个完整的分布式架构,从而向架构师的目标靠近。

第二部分(实战篇)

=========

SpringCloud 实战演练文档 K8S+实战+笔记+项目教程转发+评论,关注我私信回复"笔记"即可免费获取

第 5 章 项目准备阶段

本章中,我 将开始 个大型实战项目一一博客网站。通过“以战代练”的方式来学习如何构建 Spring loud 微服务架构,让读者走出理论的丛林,在实践中玩转微服务架构。

第 6 章 公共模块封装

从本章开始,我们将学习框架的搭建。由于代码量巨大,本书不可能全部贴出,所以只展示一些核心代码。全部源码可以从本书配套源码中查看。

第 7 章 注册中心: Spring Cloud Netflix Eureka

通过前面的学习,我们可以总结出来,注册中心是整套微服务架构的核心,即系统的心脏,它能够帮助我们管理所有的微服务,精确定位到具体的服务就是通过注册中心来实现的。构建注册中心的好处也是不言而喻的,通过注册中心,我们可以实现服务的负载均衡。配置的统-管理。服务间的通信等。目前。我们可以采用多种技术实现注册中心,如 Eureka. ZooKeeper. Consul 等,本书采用 SpringCloud 默认集成的 Eureka 框架来构建注册中心。

第 8 章 配置中心: Spring Cloud Config

我们知道,一个微服务系统可能由成千上万的服务组成,每个服务都会有自己的配置,不同服务之间的有些配置是相同的,比如数据库。如果对于每个服务,我们都复制相同的配置,一旦该配置发生了变化,那么每个服务都需要修改,代价可想而知。Spring Cloud 已经考虑到了这一点, 它为我们提供了一整套解决方案, 那就是强大的 Spring CloudConfig。

第 9 章 服务网关: Spring Cloud Gateway

本将介绍的微服务的又一大组件一一服务网关。我们需要服务网关,还有一些很重要的因素,比如服务网关会对接口进行统一拦截并做合法性校验,一个服务可以启动多个端口,利用服务网关进行负载均衡处理等。目前市面上有很多产品可以实现服务网关这一功能, 如 Nginx. Apache. Zuul 以及 Spring CloudGateway 等。Spring Cloud 集成了 Zuul 和 Gateway,我们可以很方便地实现服务网关这一功能。

第 10 章 功能开发

通过前几章的学习,我们已经搭建好了博客网站的基本框架。本章我们将正式开始网站的功能开发。

第三部分(高级篇)

=========

SpringCloud 实战演练文档 K8S+实战+笔记+项目教程转发+评论,关注我私信回复"笔记"即可免费获取

第 11 章 服务间通信: Spring Cloud Netflix Ribbon 和 Spring Cloud OpenFeign

一个大型的 系统由多个微服务模块组成,我们一-般 可以通过内部接口调用的形式(服务 A 提供一个接口,服务 B 通过 HTTP 请求调用服务 A 的接口)实现各模块之间的通信。为了简化开发,SpringCloud 集成了 Spring Cloud Netlix Ribbon 和 Spring Cloud OpenFeign,两个组件都支持通过 HTTP 请求不同的服务。本书将简要介绍 Spring Cloud Netflix Ribbon,借此引出 Sping Cloud OpenFeign,并详细介绍其用法。

第 12 章 服务链路追踪: Spring Cloud Sleuth
【这里想说,因为自己也走了很多弯路过来的,所以才下定决心整理,收集过程虽不易,但想到能帮助到一部分自学java 的人,心里也是甜的!有需要的伙伴请点㊦方】↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

以上是关于2022 年最新基于 Spring Cloud 的微服务架构分析,mysql 面试笔试题的主要内容,如果未能解决你的问题,请参考以下文章

Spring Cloud 2022 正式发布!我的天,OpenFeign​ 要退出历史舞台了?!

spring Cloud(初级版)笔记(最新最详细)周阳老师2021年6月更新

spring Cloud(初级版)笔记(最新最详细)周阳老师2021年6月更新

spring Cloud(初级版)笔记(最新最详细)周阳老师2021年6月更新

Spring Cloud 系列之 Gateway 服务网关

Spring Cloud 2022 正式发布!我的天,OpenFeign​ 要退出历史舞台了?!