SpringCloud-1-基础组件（Eureka，Ribbon，Consul）

李钟意·

已于 2022-08-29 11:27:05 修改

阅读量444

点赞数

文章标签： spring cloud java

于 2022-07-27 10:55:21 首次发布

本文链接：https://blog.csdn.net/m0_60875109/article/details/125906224

版权

本文介绍了微服务基础知识，包括系统架构的演变、分布式核心知识和常见微服务框架。重点讲解了SpringCloud，包括其核心组件、Eureka服务注册与发现的原理及实践，探讨了Eureka的高可用集群和自我保护机制。此外，还讨论了Eureka的替代方案Consul，阐述了Consul的基本使用、服务注册与发现。最后，通过Ribbon学习了服务调用和负载均衡策略。

摘要由CSDN通过智能技术生成

2.3.1 SpringCloud中的核心组件

2.3.2 SpringCloud的体系结构

2.3 SpringCloud的架构

2.3.1 SpringCloud中的核心组件

3.5.2 RestTemplate方法介绍

3.5.3 通过RestTemplate调用微服务

4.1 Eureka Server 高可用集群

4.1.1 搭建 Eureka Server高可用集群

4.2 Eureka中的常见问题

4.2.4 自我保护

4.3 Eureka源码解析

4.3.1 SpringBoot中的自动装载

5.2.2 consul与Eureka的区别

6.4.2 客户端负载均衡与服务端负载均衡

6.5.2 在消费者appllication.yal中配置

6.6 Ribbon中负载均衡的源码解析

1 微服务基础知识

1.1 系统架构的演变

随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

1.1.1 单体应用架构

Web 应用程序发展的早期，大部分 web 工程 ( 包含前端页面 ,web 层代码 ,service 层代码 ,dao 层代码 ) 是所有的功能模块, 打包到一起并放在一个 web 容器中运行。比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个web 容器中运行的系统就叫做单体架构。

优点：

所有的功能集成在一个项目工程中。项目架构简单，前期开发成本低，周期短，小型项目的首选。

缺点：

全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。技术栈受限。

1.1.2 垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

优点：

项目架构简单，前期开发成本低，周期短，小型项目的首选。通过垂直拆分，原来的单体项目不至于无限扩大。不同的项目可采用不同的技术。

缺点：

全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

1.1.3 分布式SOA架构

1.1.3.1 什么是 SOA

SOA 全称为 Service-Oriented Architecture ，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件( 服务 ) 进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

通过上面的描述可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合。

1.1.3.2 SOA 架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求

优点：抽取公共的功能为服务, 提高开发效率。对不同的服务进行集群化部署解决系统压力。基于ESB/DUBBO 减少系统耦合。

缺点：抽取服务的粒度较大，服务提供方与调用方接口耦合度较高。

1.1.4 微服务架构

优点：

通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降。

微服务遵循单一原则。微服务之间采用Restful 等轻量协议传输。

缺点：

微服务过多，服务治理成本高，不利于系统维护。

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

1.1.5 SOA与微服务的关系

SOA （ Service Oriented Architecture ）面向服务的架构”: 他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

微服务架构 : 其实和 SOA 架构类似 , 微服务是在 SOA 上做的升华，微服务架构强调的一个重点是 “ 业务需要彻底的组件化和服务化” ，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

1.2 分布式核心知识

1.2.1 分布式中的远程调用

在微服务架构中，通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分：序列化和通信协议。常见的序列化协议包括json 、 xml 、 hession 、 protobuf 、 thrift 、 text 、 bytes 等，目前主流的远程调用技术有基于HTTP 的 RESTful 接口以及基于 TCP 的 RPC 协议。

（ 1 ） RESTful 接口

REST ，即 Representational State Transfer 的缩写，如果一个架构符合 REST 原则，就称它为 RESTful 架构。

总结一下什么是 RESTful 架构：

每一个URI代表一种资源；
客户端和服务器之间，传递这种资源的某种表现层；
客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

（ 2 ） RPC 协议

RPC （ Remote Procedure Call ）一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC 框架负责屏蔽底层的传输方式（ TCP 或者UDP）、序列化方式（ XML/JSON/ 二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

（ 3 ）区别与联系

1 、 HTTP 相对更规范，更标准，更通用，无论哪种语言都支持 http 协议。如果你是对外开放 API ，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful 。

2 、 RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

1.2.2 分布式中的CAP原理

现如今，对于多数大型互联网应用，分布式系统（ distributed system ）正变得越来越重要。分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。CAP理论由 Eric Brewer 在 ACM 研讨会上提出，而后 CAP 被奉为分布式领域的重要理论。分布式系统的CAP理论，首先把分布式系统中的三个特性进行了如下归纳：

Consistency（一致性）：数据一致更新，所有数据的变化都是同步的。
Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运行。

通过学习 CAP 理论，我们得知任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：

CA ：放弃分区容错性，加强一致性和可用性，其实就是传统的关系型数据库的选择。
AP ：放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此。
CP ：放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用。

需要明确一点的是，在一个分布式系统当中，分区容忍性和可用性是最基本的需求，所以在分布是系统中，我们的系统最当关注的就是A （可用性） P （容忍性），通过补偿的机制寻求数据的一致性。

1.3 常见微服务框架

1.3.1 SpringCloud

SpringCloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。 Spring Cloud 并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

1.3.2 ServiceComb

Apache ServiceComb 是业界第一个Apache微服务顶级项目，是一个开源微服务解决方案,致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案，融合SDK框架级、0侵入ServiceMesh场景并支持多语言。

1.3.3 ZeroC ICE

ZeroC IceGrid 是 ZeroC 公司的杰作，继承了 CORBA 的血统，是新一代的面向对象的分布式系统中间件。作为一种微服务架构，它基于RPC 框架发展而来，具有良好的性能与分布式能力。

2 SpringCloud概述

2.1 微服务中的相关概念

2.1.1 服务注册与发现

服务注册 ：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机 IP 和提供服务的Port ，以及暴露服务自身状态以及访问协议等信息。

服务发现 ：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

2.1.2 负载均衡

负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性和可靠性。

2.1.3 熔断

熔断这一概念来源于电子工程中的断路器（Circuit Breaker ）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

2.1.4 链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪

2.1.5 API网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：客户端需要调用不同的url 地址，增加难度再一定的场景下，存在跨域请求的问题每个微服务都需要进行单独的身份认证针对这些问题，API 网关顺势而生。

API 网关直面意思是将所有 API 调用统一接入到 API 网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而 API 网关更专注于安全、流量、路由等问题。

2.2 SpringCloud的介绍

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。 Spring Cloud 并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

2.3 SpringCloud的架构

2.3.1 SpringCloud中的核心组件

Spring Cloud 的本质是在 Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文目录（Application Context ）进行了功能增强。既然 Spring Cloud 是规范，那么就需要去实现，目前 Spring Cloud 规范已有 Spring 官方， Spring Cloud Netflflix ， Spring Cloud Alibaba 等实现。通过组件化的方式，Spring Cloud 将这些实现整合到一起构成全家桶式的微服务技术栈。

2.3.2 SpringCloud的体系结构

从上图可以看出 Spring Cloud 各个组件相互配合，合作支持了一套完整的微服务架构。

注册中心负责服务的注册与发现，很好将各服务连接起来
断路器负责监控服务之间的调用情况，连续多次失败进行熔断保护。
API网关负责转发所有对外的请求和服务
配置中心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息
链路追踪技术可以将所有的请求数据记录下来，方便我们进行后续分析
各个组件又提供了功能完善的dashboard监控平台,可以方便的监控各组件的运行状况

2.3 SpringCloud的架构

2.3.1 SpringCloud中的核心组件

Spring Cloud 的本质是在 Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文（Application Context ）进行了功能增强。既然 Spring Cloud 是规范，那么就需要去实现，目前Spring Cloud 规范已有 Spring 官方， Spring Cloud Netflflix ， Spring Cloud Alibaba 等实现。通过组件化的方式，Spring Cloud 将这些实现整合到一起构成全家桶式的微服务技术栈。

Spring Cloud Netflflix 组件

Spring Cloud Alibaba组件

Spring Cloud原生及其他组件

3 案例搭建

使用微服务架构的分布式系统 , 微服务之间通过网络通信。我们通过服务提供者与服务消费者来描述微服务间的调用关系。

服务提供者：服务的被调用方，提供调用接口的一方。

服务消费者：服务的调用方，依赖于其他服务的一方。

我们以电商系统中常见的用户下单为例，用户向订单微服务发起一个购买的请求。在进行保存订单之前需要调用商品微服务查询当前商品库存，单价等信息。在这种场景下，订单微服务就是一个服务消费者，商品微服务就是一个服务提供者。

3.1 数据库表

资料中提供了案例中所需要的数据库表与实体类。

用户表

CREATE TABLE `tb_user` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `username` varchar(40) DEFAULT NULL COMMENT '用户名',
 `password` varchar(40) DEFAULT NULL COMMENT '密码',
 `age` int(3) DEFAULT NULL COMMENT '年龄',
 `balance` decimal(10,2) DEFAULT NULL COMMENT '余额',
 `address` varchar(80) DEFAULT NULL COMMENT '地址',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

商品表

CREATE TABLE `tb_product` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `product_name` varchar(40) DEFAULT NULL COMMENT '名称',
 `status` int(2) DEFAULT NULL COMMENT '状态',
 `price` decimal(10,2) DEFAULT NULL COMMENT '单价',
 `product_desc` varchar(255) DEFAULT NULL COMMENT '描述',
 `caption` varchar(255) DEFAULT NULL COMMENT '标题',
 `inventory` int(11) DEFAULT NULL COMMENT '库存',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8

订单表

CREATE TABLE `tb_order` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `user_id` int(11) DEFAULT NULL COMMENT '用户id',
 `product_id` int(11) DEFAULT NULL COMMENT '商品id',
 `number` int(11) DEFAULT NULL COMMENT '数量',
 `price` decimal(10,2) DEFAULT NULL COMMENT '单价',
 `amount` decimal(10,2) DEFAULT NULL COMMENT '总额',
 `product_name` varchar(40) DEFAULT NULL COMMENT '商品名',
 `username` varchar(40) DEFAULT NULL COMMENT '用户名',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

注意：mysql创建数据库时设置字符集编码为utf8mb4，排序规则为utf8mb4_unicode_ci

create database test default character set utf8mb4 collate utf8mb4_unicode_ci;

最低0.47元/天解锁文章