一篇文章带你入门springCloud
目录
[一、单体架构（ALL IN ONE）](#一、单体架构（ALL IN ONE）)
一、单体架构（ALL IN ONE）
单体项目 就是所有模块都在一个项目中，开发和部署比较简单，但无法应对高并发的场景。
**关键名词：**域名、IP、节点（服务器）、应用
二、集群架构
主要用于**解决高并发情景，**但依旧存在一些问题
问题1：在集群架构中，对于应用中某个模块进行升级，我们需要对整个项目进行重新的下线，打包，部署。维护和升级比较麻烦。
问题2：某模块需要新语言编写，多语言团队的问题。
**关键名词：**集群、副本、路由、负载均衡、扩缩容（增加/减少节点）
区别于分布式：分布式是将一个系统应用进行拆分，即每个节点上功能不同。而集群则是多个节点上复制同一个应用，即每个节点的功能相同。
三、分布式架构
分布式系统：分布式系统是由多个独立的服务器（节点）通过网络连接，协同完成同一个任务的系统
微服务 ：微服务是将复杂应用拆分为多个小型，独立服务的架构风格，微服务必然是分布式系统。
**关键名词：**微服务（自治）、副本、负载均衡、单点故障、远程调用、服务熔断、服务雪崩、分布式事务
每个微服务独立部署，数据库也相应的进行垂直拆分。如此实现数据隔离，由于模块在不同的服务器上单独部署，通过统一的API规范进行相互调用。由此语言无关的情况也可以被解决（松耦合的API通信，具有技术栈无关性）
注意： 每个微服务要避免部署在同一个服务器节点上，否则会出现单点故障隐患
当某台服务器上的订单业务需要调用用户信息时，就会向用户服务所在节点发送一个HTTP请求。这个就叫做**RPC（Remote Produce Call 远程调用）**其中HTTP+JSON只是RPC调用的方式之一。
远程调用期间，如何获取到目标服务的位置呢？这依赖到两个机制：服务注册和服务发现 。这两个机制一般由注册中心提供。
在服务注册和服务发现的过程中，也会用到负载均衡的技术，在压力过大的情况下，路由到不同的节点。
此外，注册中心还能承担 配置中心 的工作。例如：用户相关的配置文件发生变化时，在没有配置中心的情况下我们需要将所有节点上的用户服务下线，重新打包并部署，虽然完成了模块化升级，还是不够方便。
所以，我们可以把所有配置都存放在配置中心，让配置中心去统一管理配置，这样如果我们需要修改配置，只需要修改配置中心即可，配置中心会主动将变更推送到相应的服务。
我们再设想一种情景调用链：用户服务------调用------订单服务------调用------支付服务。此时订单服务发生了卡顿，导致了整个调用链发生了卡顿。在高并发的情境下，百万级别的请求积压在某个服务节点上，就会造成服务雪崩 （由于某个个别的服务发生故障，进而造成整个调用链甚至整个系统的崩溃），此时我们需要引入服务熔断的概念。
服务熔断 ：当请求发生卡顿时，快速返回失败信号，及时释放资源，防止请求挤压。其分为三个状态流转。
-
闭合状态：调用方正常调用服务，监控错误率和超时率
-
打开状态：当错误率超过预设阈值，此时熔断机制触发，所有对该服务的调用都会返回降级结果（如"服务暂时不可用'）
-
半打开状态：打开状态维持一段时间以后，进入半打开状态。允许少量请求试探调用该服务，若试探成功，恢复至闭合状态。若失败，则继续保持打开状态。
那么从用户发起调用后，整个集群的架构是如何实现呢？
这样分布式系统的架构就基本介绍完成了。
针对于最开始提到的名词，目前有一系列标准的解决方案：
-
微服务：SpringBoot
-
注册中心/配置中心：SpringCloud Alibaba Nacos
-
网关：SpringCloud Gateway
-
远程调用：SpringCloud OpenFeign
-
服务熔断：SpringCloud Alibaba Sentinel
-
分布式事务：SpringCloud Alibaba Seata