"微服务" 架构 与 Spring Cloud
目录:
- ["微服务" 架构 与 Spring Cloud](#"微服务" 架构 与 Spring Cloud)
-
- [1. 认识架构](#1. 认识架构)
-
- ["单体" 架构](#"单体" 架构)
- ["SOA" 架构](#"SOA" 架构)
- ["微服务" 架构](#"微服务" 架构)
- [2. "微服务架构" 的功能 :](#2. "微服务架构" 的功能 :)
-
- [① 微服务架构的 "自动化部署"](#① 微服务架构的 "自动化部署")
- [② 服务 "集中化管理"](#② 服务 "集中化管理")
- [③ 支持 "熔断机制"](#③ 支持 "熔断机制")
- [3. 初识 Spring Cloud](#3. 初识 Spring Cloud)
-
- [3.1 Spring Cloud 概述](#3.1 Spring Cloud 概述)
- [3.2 Spring Cloud 特点](#3.2 Spring Cloud 特点)
- [3.3 Spring Cloud 微服务架构 的 "组件" :](#3.3 Spring Cloud 微服务架构 的 "组件" :)
-
- [(1) Spring Cloud Confg](#(1) Spring Cloud Confg)
- [(2) Spring Cloud Netflix](#(2) Spring Cloud Netflix)
- [(3) Spring Cloud Bus](#(3) Spring Cloud Bus)
- [(4) Spring Cloud Stream](#(4) Spring Cloud Stream)
- [(5) Spring Cloud Sleuth](#(5) Spring Cloud Sleuth)
- [3.4 Spring Cloud 的版本号](#3.4 Spring Cloud 的版本号)
- [3.5 Spring Cloud与 Spring Boot 的兼容性](#3.5 Spring Cloud与 Spring Boot 的兼容性)
作者简介 ：一只大皮卡丘，计算机专业学生，正在努力学习、努力敲代码中! 让我们一起继续努力学习！
该文章参考学习教材 为：
《Spring Cloud微服务架构开发》 黑马程序员 / 编著文章以课本知识点 + 代码为主线，结合自己看书学习过程中的理解和感悟 ，最终成就了该文章
文章用于本人学习使用 ， 同时希望能帮助大家。
欢迎大家点赞👍 收藏⭐ 关注💖哦！！！
（侵权可联系我，进行删除，如果雷同，纯属巧合）
- 互联网的飞速发展 给人们的工作和生活带来了翻天覆地的变化，人们在享受互联网 带来的便捷 同时，也对互联网产品 提出了 更为严格的要求 。而 传统架构下的 互联网产品，** 面对复杂的业务需求** ，在 降低业务之间 耦合性 、快速部署项目 、轻松持续改进项目 上都已 显得力不从心 。为了解决上述问题，微服务架构 应运而生。
- Spring Cloud 是一套完整 的 微服务架构解构 和 解决方案。
1. 认识架构
"单体" 架构
一个典型的单体架构就是将** 所有业务场景的 ① 表示层 、② 业务逻辑层 和 ③ 数据访问层 放在 一个 "project工程"** 中，最终经过 编译 、打包 ，部署 在 一台 服务器上。
例如，开发 一个进销存的系统，我们可以 将项目打包成war包 并 部署到 服务器上 。这样的 一个 war 包涵盖了很多模块，如下图所示 ：
如上图所示的 单体架构 ，随着业务越来越复杂 ，应用程序需要增加 的 功能越来越多 ，单体架构的 代码量越来越大 ，代码可读性 、可维护性 和 扩展性 会 下降 。同时，使用 单体架构 带来的 隐患会比较多 ，同时由于 系统过于庞大以及 关联较多，应用中的** 任何一个 Bug** ( 漏洞、错误 )都有可能导致整个系统宕机。
"SOA" 架构
针对 传统的单体架构存在 的问题，人们设计出了一种 SOA 架构。
( SOA 架构 ： 是一种 "面向服务 " 的架构方式 ，将原来 "单体架构 " 按照"功能" 细分 为不同的 "子系统" )
SOA 架构 是一个 面向服务 的 架构 。它是一个 组件模型 。SOA架构将应用程序 的 不同功能单元 ( 称为 服务 ) 进行 拆分 ，这些 服务 通过 定义良好的接口和** 契约 "联系起来"** 。 接口 是采用 中立的方式进行 定义的，它 独立于实现服务的硬件平台 、操作系统和编程语言 。这使构建在 各种各样的系统 中的 服务 可以 使用一种统一 和 通用 的方式进行 交互。
SOA 架构 将原来的 单体架构 "按照功能细分" 为 不同的子系统 。SOA架构如下图所示 ：
由上图可知 ，一个完整的项目会分为** 多个模块** ，数据库 分为 主库 与 从库 两种，并且 "主库" 与 "从库" 是 数据同步 的。这样的 SOA架构 "解决" 了 单体式架构所遗留下 的 问题。
但 S0A架构本身也** 存在一些缺点** 。S0A架构一般使用某种集中式管理 ，比如会有审查委员会 、主架构师 或架构委员会 等部门来严格定义每个系统组件应当做什么 、如何执行 ，相同类型的功能 可能会在多个组件中分别定义 和记录 ，每个组件 使用的语言 或者工具集 可以是统一的 ，也可以不是 。
在 SOA架构 中，系统和服务 的界定比较模糊，而且 服务的接口协议不固定 ，且 种类繁多 ，不利于系统维护。
"微服务" 架构
学习了 单体架构和 SOA架构，我们可以知道，系统中的** 模块与模块之间直接相互访问或 某个模块本身的错误都有可能 影响整个系统的使用**。在大数据 以及高并发 的环境下，系统架构 面对更加严苛的挑战 。为解决这些问题 ，微服务架构 就诞生了。
微服务架构的基本思想 在于考虑围绕着业务领域组件 来创建应用 ，这些应用可独立地 进行开发 、管理 和部署。在分散的组件 中使用微服务云架构 和平台 ，使部署、管理和服务功能交互 变得更加简单。
微服务架构是一种将单一应用 程序作为一套小型服务开发 的方法。每种应用程序 都在其自己的进程中运行 ，并与轻量级机制 [通常是HTTP资源 的应用程序接口 (Application Programming Imterface，API) ] 进行通信 。这些服务是围绕业务功能构建的，可以通过全自动部署机制 进行独立部署。
相比单体架构 和 SOA架构 ，如何理解微服务架构 的集中化管理 ? 因为 微服务架构的** 每个业务功能都是一个 独立的项目** ，各个项目 之间的 耦合性很低 ，所以开发人员可以使用不同的编程语言编写程序 、使用不同的存储系统计算存储数据 。前面提到的进销存系统 ，如果使用微服务架构来开发 ，可以采用下图所示的结构 :
从上图可以看出 ，微服务架构中** 每个服务都有自己独立** 的 数据库 ，数据库之间 没有任何联系 。这样的 好处 是，随着业务的不断扩张 ，不同服务与服务 之间 不需要提供数据库集成 ，而是提供 API相互调用 。独立的数据库 使系统的维护变得简单 ，性能明显提高 ，迁移 也比较方便 。在微服务架构中，数据的存储不仅可以使用关系型数据库，还可以使用非关系型数据库。一个典型的微服务架构系统，每个服务对应的数据库可能各不相同，建议大家根据业务需求选择合适的数据库。
微服务架构是** 直接通过 HTTP 进行通信的，也可以采用消息队列** 来通信 ，如采用 RabbitMQ 、Kafka 等进行通信 。微服务采用不同的编程语言 ，使用不同的存储技术 ，进行自动化部署减少了人为控制 ，降低了出错概率。
2. "微服务架构" 的功能 :
- 微服务 的概念源于 2014年3月 Martin Fowler( 马丁·福勒)所写的一篇文章"Microservices" (微服务 )。文中表达了一种观念，微服务架构 是一种架构模式 ，它提倡将单一应用程序 划分成一组小的服务 ，服务之间互相协调 、互相配合 ，为用户提供最终价值。
- 微服务架构是一种架构风格 ，一个大型复杂软件应用 由多个微服务架构 组成。系统中的 各个微服务架构可 被独立部署 ，各个微服务架构之间是** 松耦合的。每个微服务架构仅关注于完成一项任务并很好地完成该任务。在所有情况下，每项任务代表着一个小的业务能力** 。微服务架构的功能如下 。
① 微服务架构的 "自动化部署"
- 微服务架构 中，系统 会被拆分为 若干个微服务架构 ，每个微服务架构 又是一个 独立的应用程序 。单体架构 中的应用程序只需要部署一次 ，而微服务架构 中 有多少 服务 就需要部署多少次 。随着服务数量的增加 ，部署的难度 就会增加 。业务的 粒度划分得越细 ，微服务 架构的** 数量就越多** 。因此就出现了 自动化部署技术 ，例如 Docker 容器自动化部署技术方便 了微服务架构项目下 各模块在服务器上 的 部署。
② 服务 "集中化管理"
- 微服务架构系统是按照 "** 业务单元** " 来 划分的，** 服务数量越多** ，管理起来 越复杂。在这里，微服务架构提供了集中化管理组件 ： Spring Cloud Config ，可以在 Spring Cloud Config 配置文件中统一配置服务 ， 这个操作** 很大程度上方便了对 项目的集中化管理**。
③ 支持 "熔断机制"
- 微服务架构 就是 分布式的。在分布式系统 中，服务之间 是相互依赖 的，如果一个服务出现了故障 或者网络延迟 ，在高并发 的情况下，就会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽 ，最终使得该服务不可用。
- 由于服务相互依赖 ，这样可能会导致整个服务的不可用 ，这就是"雪崩"效应 。熔断机制 是应对"雪崩"效应 的一种微服务架构链路保护机制 。我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护 ; 股票交易中，如果股票指数过高，就也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。当一条链路 的某个微服务架构不可用或者** 响应时间太长时** ，会进行 服务的降级 ，进而调用熔断该节点的微服务架构，快速返回错误 的 响应信息 ；当 检测到该节点微服务架构** 调用响应正常后** ，恢复调用链路。
3. 初识 Spring Cloud
3.1 Spring Cloud 概述
- Spring Cloud 是一个基于 Spring Boot 实现的 "微服务开发" 架构 。它利用 Spring Boot 的 开发便利性巧妙地简化了 分布式系统 的 开发 。
例如 配置管理 、服务发现 、断器使用 、智能路由 、控制总线等操作，都可以使用Spring Boot 做到 一键启动 和 部署。- 可以说，Spring Cloud 将 Spring Boot 框架 进行 再封装 ，屏蔽掉 了 复杂的配置 和 实现原理，最终给开发者 留出了一套 简单易懂 、易部署 和 易维护 的 分布式系统开发工具包。
3.2 Spring Cloud 特点
① 组件丰富，功能齐全
Spring Cloud 拥有 Spring 这个强大后盾，框架的源码也是开源的，而且开发者在不断完善 Spring Cloud 下的组件，其中包括 Eureka服务注册发现中心 ，主要负责完成微服务架构中 的服务管理功能 ; Spring Cloud Confg分布式配置中心 ，可以实现动态修改配置文件 ; Hystrix熔断器 ，通过熔断机制控制服务 和第三方库的节点，从而对延迟和故障提供更强大的容错能力。这些组件基本覆盖了日常开发的各个方面
② 开箱即用，快速启动
Spring Cloud 是基于 Spring Boot 开发 的，Spring Boot 具有 快速构建 Spring应用 、直接嵌入服务器 、自动化配置 的优点，Spring Cloud 继承 了 Spring Boot 快速构建 和 自动化配置的优点有开箱即用、快速启动的特点。
③ 模块部署方便，项目维护难度降低
Spring Cloud 采用 模块化开发 ，按照项目功能 将项目拆分为不同的模块 ，每个模块独立开发运行 ，模块之间不会互相影响 。模块开发完成后，每个模块部署时可以使用 Docker 进行 自动化部署 ，使得项目部署更加方便 。维护时只需要维护具体的模块，不需要改动其他模块的代码，从而降低了模块后期维护的成本。
④ 项目扩展性和稳定性较好
基于 Spring Cloud 的 微服务架构 中，每个模块基本** 都是一个 Spring Boot 项目** ，它们都有独立的数据库 ，模块下 的功能是横向开发 的。如果需要扩展新的功能 ，就可以新建该功能对应的独立数据库以及新的模块，不需要在之前的模块上修改 ，这样项目 扩展更方便 ，项目稳定性更好。
⑤ 具有容错处理机制
项目实际开发 中会因为网络连接失败 、超时 、服务器硬件故障 等原因 导致其中某个模块无法正常运行 ，从而 导致整个项目发生异常 ，所以 容错机制变得尤为重要。SpringCloud 提供了** Hystrix 组件** ，该组件专门用于 处理容错 ，从而能保证某个模块出错后 系统有其他备用模块 或者善后处理。
3.3 Spring Cloud 微服务架构 的 "组件" :
Spring Cloud 是 一系列框架的 有序集合，为开发人员构建** 微服务架构提供了完整的解决方案** 。Spring Cloud 根据分布式服务协调 治理的需求 成立了许多 "子项目" ，每个项目 通过特定的组件去实现。
基于 Spring Cloud 的 微服务架构 如下图所示 ：
Spring Cloud 包含的 常用组件以及** 模块** 的 具体内容如下所示。
(1) Spring Cloud Confg
Spring Cloud Confg : 分布式配置中心 ，负责把配置 放到远程服务器上，集中化管理集群配置 。目前支持 ① 本地存储、** ② Git** 和 ③ Subversion。
(2) Spring Cloud Netflix
Spring Cloud Netflix : 核心组件 ，负责 对多个 Netflix 0SS 开源套件进行** 整合**。
- Eureka : 服务注册发现中心 ，基于REST服务 的分布式中间件 ，主要用于服务管理。
- Hystrix : 熔断器 ，容错管理工具 ，旨在通过 熔断机制控制服务 和 第三方库的节点 , 从而对 延迟 和 故障 提供 更强大的容错能力''。
- Ribbon : 云端负载均衡器 。支持多种 负载均衡策略 ，可配合服务发现 和 熔断器使用 ，在客户端 实现负载均衡。
- Feign : 一个 REST 客户端 ，基于 Ribbon 和 Hystrix 的声明式服务调用组件。
- Zuul : 服务网关 ，为微服务架构集群提供代理 、过滤 、路由等功能。
(3) Spring Cloud Bus
Spring Cloud Bus : 事件 、消息总线 ，用于在 集群 (例如配置变化事件) 中传播状态变化 ，可 与 Spring Cloud Confg 联合实现热部署。
(4) Spring Cloud Stream
Spring Cloud Stream : 数据流操作开发包 ，可与 Redis 、RabbitMO 、Kalka 等架构进行消息发送与接收。
(5) Spring Cloud Sleuth
Spring Cloud Sleuth : 服务追踪框架 ，可以与 Zipkin 、Apache Htrace 和 ELK 等数据分析、服务跟踪系统进行整合 ，为跟踪服务 、解决问题提供了便利。
3.4 Spring Cloud 的版本号
Spring Cloud 的 版本号 :
① SNAPSHOT : 快照版本 ，可能会被修改。
② M( MileStone ) : 里程碑版本 ，M1 表示第一个里程碑版本 。一般同时标注 PRE，表示预览版本。③ SR (Service Release ) : 正式版本 。如果正式版有多个 ，就使用数字标识 不同的正式版本，例如SR1 表示第一个正式版本，同时一般会标记 GA(GenerallyAvailable) ，表示 稳定版本。
3.5 Spring Cloud与 Spring Boot 的兼容性
通过前面的学习知道 Spring Cloud 是基于Spring Boot开发的。** Spring Boot** 专注于 快速、方便集成 单个微服务架构 ，而 Spring Cloud 是 关注全局的服务治理框架 。SpringCloud 依赖于 Spring Boot。
由于 Spring Cloud 和 Spring Boot 都发布了多个版本 ，选择这些版本时 需要考虑兼容性 ，两者的兼容关系如下表所示 ：
Spring Cloud版本 Spring Boot版本 Greenwich版本 兼容 Spring Boot 2.1.x Finchley 版本 兼容 Spring Boot 2.0.x Dalston版本 和 Edgware 版本 兼容 Spring Boot 1.5.x Camden 版本 兼容 Spring Boot 1.4.x Brixton 版本 兼容 Spring Boot 1.3.x Angel版本 兼容 Spring Boot 1.2.x 在实际操作 中，选择Spring Boot与 Spring Cloud 版本时，没有限制必须使用某一版本 ，一般标注 GA (稳定 )的 版本都可以使用 。但有 一点要注意 ，Spring Cloud 版本 一定要 与 Spring Boot 版本兼容 ，以 兼容为第一要务。