基于SpringCloud分布式架构
本文内容纲要：
-基于SpringCloud分布式架构
-为什么要使用分布式架构
-分布式基础组件
-Eureka
-SpringCloudConfig
-NetflixZuul（网关）
-SpringCloudBus
-Feign
-NetflixHystrix（熔断）
-MQ（消息中间件）
-分布式事务
-完整的分布式架构
-总结
-单体服务与分布式服务区别
-什么时候使用分布式/集群？
-使用分布式注意事项
-关于组件停更消息
基于SpringCloud分布式架构
为什么要使用分布式架构
- SpringCloud专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖
- 分布式/版本化配置
- 服务注册和发现
- 路由
- Service-to-Service调用
- 负载均衡
- 断路器
- 分布式消息传递
这是分布式的优点，这样看起来可能比较抽象，举个例子来说，对于单体服务来说，如果我想更新订单中的某个功能，我是不是需要重启整个服务。
这个时候就会导致整个项目都处于不可用状态，或者在处理订单的时候由于程序代码写的有问题，导致死锁了，这个时候也会导致整个服务处于宕机专改，容错率很差。
但是分布式不同，如上图所示，订单服务、售后服务、用户服务都是独立的服务，如果需要更新订单服务或者订单服务发生死锁，受影响的只会是订单服务，售后服务与用户服务还是可以正常工作的，这就是分布式相对单体来说最大的优势之一。
分布式基础组件
SpringCloudConfig：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。
SpringCloudBus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与SpringCloudConfig联合实现热部署。
Eureka：云端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Zuul：Zuul是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul相当于是设备和Netflix流应用的Web网站后端所有请求的前门。
Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
Consul：封装了Consul操作，Consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
SpringCloudforCloudFoundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
SpringCloudSleuth：日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。
SpringCloudDataFlow：大数据操作工具，作为SpringXD的替代产品，它是一个混合计算模型，结合了流数据与批量数据的处理方式。
SpringCloudSecurity：基于SpringSecurity的安全工具包，为你的应用程序添加安全控制。
SpringCloudZookeeper：操作Zookeeper的工具包，用于使用Zookeeper方式的服务发现和配置管理。
SpringCloudStream：数据流操作开发包，封装了与Redis、Rabbit、Kafka等发送接收消息。
SpringCloudCLI：基于SpringBootCLI，可以让你以命令行方式快速建立云组件。
Ribbon：提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。
Turbine：Turbine是聚合服务器发送事件流数据的一个工具，用来监控集群下Hystrix的Metrics情况。
Feign：Feign是一种声明式、模板化的HTTP客户端。
SpringCloudTask：提供云端计划任务管理、任务调度。
SpringCloudConnectors：便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。
SpringCloudCluster：提供Leadership选举，如：Zookeeper，Redis，Hazelcast，Consul等常见状态模式的抽象和实现。
SpringCloudStarters：SpringBoot式的启动项目，为SpringCloud提供开箱即用的依赖管理。
我们常用的组件：
- SpringCloudConfig
- SpringCloudBus
- Hystrix
- Eureka
- Zuul
- Ribbon
- Feign
Eureka
Eureka属于SpringCloudNetflix下的组件之一，主要负责服务的注册与发现，何为注册与发现？
在刚刚我们分析的分布式中存在这一个问题，那就是订单服务与用户服务被独立了，那么他们怎么进行通信呢？比如在订单服务中获取用户的基础信息，这个时候我们需要怎么办？
如果按照上面的架构图，直接去数据库获取就可以了，因为服务虽然独立了，但是数据库还是共享的，所以直接查询数据库就能得到结果，如果我们将数据库也拆分了呢？这个时候我们该怎么办呢？
有人想到了，服务调用，服务调用是不是需要IP和端口才可以，那问题来了，对于订单服务来说，我怎么知道用户服务的IP和端口呢？在订单服务中写死吗？如果用户服务的端口发生改变了呢？
这个时候Eureka就出来了，他就是为了解决服务的通信问题，每个服务都可以将自己的信息注册到Eureka中，比如IP、端口、服务名等信息，这个时候如果订单服务想要获取用户服务的信息，只需要去Eureka中获取即可。
请看下图：
这就是Eureka的主要功能，也是我们使用中的最值得注意的，他让服务之间的通信变得更加的简单灵活。
SpringCloudConfig
SpringCloudConfig为分布式系统中的外部配置提供服务器和客户端支持。使用ConfigServer，您可以在所有环境中管理应用程序的外部属性。
客户端和服务器上的概念映射与SpringEnvironment和PropertySource抽象相同，因此它们与Spring应用程序非常契合，但可以与任何以任何语言运行的应用程序一起使用。
随着应用程序通过从开发人员到测试和生产的部署流程，您可以管理这些环境之间的配置，并确定应用程序具有迁移时需要运行的一切。
服务器存储后端的默认实现使用Git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。可以轻松添加替代实现，并使用Spring配置将其插入。
简单点来说集中来管理每个服务的配置文件，将配置文件与服务分离，这么多的目的是什么？
举个简单的栗子，我们配置文件中肯定会存在数据库的连接信息，Redis的连接信息，我们的环境是多样的，有开发环境、测试环境、预发布环境、生产环境。
每个环境对应的连接信息肯定是不相同的，难道每次发布的时候都要去修改一下服务中的配置文件？
我能不能将这些变动较大的配置集中管理，不同环境的管理者分别对他们进行修改，就不需要再服务中做改动了，Config就做到了。
这就是Config的大致架构，所有的配置文件都集中交给Config管理，拿Config怎么管理这些配置文件呢？
你可以将每个环境的配置文件存放再一个位置，比如Lgitlab、SVN、本地等等，Config会根据根据你设置的位置读取配置文件进行管理，然后其他服务启动的时候直接到Config配置中心获取对应的配置文件即可。
这样开发人员只需要关注-dev的配置文件，测试人员只需要关注-test的配置文件，完全和服务解耦，你值得拥有。
NetflixZuul（网关）
路由在微服务体系结构的一个组成部分。例如，/可以映射到您的Web应用程序，/api/users映射到用户服务，并将/api/shop映射到商店服务。Zuul是Netflix的基于JVM的路由器和服务器端负载均衡器。
Netflix使用Zuul进行以下操作：
- 认证-洞察
- 压力测试
- 金丝雀测试
- 动态路由
- 服务迁移
- 负载脱落
- 安全
- 静态响应处理
- 主动/主动流量管理
我们在日常开发过程中并不会使用那么多，基本上就是认证、动态路由、安全等等，我画了一张关于网关的架构图，请看：
注意：Nginx只能为我们做反向代理，不能做到权限认证，网关不但可以做到代理，也能做到权限认证、甚至还能做限流，所以我们要做分布式项目，少了他可不行。
SpringCloudBus
application.yml
spring:
datasource:username:rootpassword:123456url:jdbc:mysql://localhost:3306/testdriver-class-name:com.mysql.cj.jdbc.Driver
比如上面这行配置大家都应该很熟悉，这是数据库的连接信息，如果它发生改变了怎么办呢？
我们都知道，服务启动的时候会去Config配置中心拉取配置信息，但是启动完成之后修改了配置文件我们应该怎么办呢，重启服务器吗？
我们可以通过SpringCloudBus来解决这个问题，SpringCloudBus将轻量级消息代理链接到分布式系统的节点。然后可以将其用于广播状态更改（例如，配置更改）或其他管理指令。
我们可以通过SpringCloudBus来解决这个问题，SpringCloudBus将轻量级消息代理链接到分布式系统的节点。然后可以将其用于广播状态更改（例如，配置更改）或其他管理指令。
这个需要我们有一点的MQ基础，不管是RabbitMQ还是Kafka，都可以。
Bus的基本原理就是：配置文件发生改变时，Config会发出一个MQ，告诉服务，配置文件发生改变了，并且还发出了改变的哪些信息，这个时候服务只需要根据MQ的信息做实时修改即可。
这是一个很简单的原理，理解起来可能也不会怎么难，画个图来理解一下：
大致流程就是这样，核心就是通过MQ机制实现不重启服务也能做到配置文件的改动，这方便了运维工程师，不用每次修改配置文件的时候都要去重启一遍服务的烦恼。
Feign
Feign是一个声明式的Web服务客户端。这使得Web服务客户端的写入更加方便要使用Feign创建一个界面并对其进行注释。
它具有可插入注释支持，包括Feign注释和JAX-RS注释。Feign还支持可插拔编码器和解码器。
SpringCloud增加了对SpringMVC注释的支持，并使用SpringWeb中默认使用的HttpMessageConverters。
SpringCloud集成Ribbon和Eureka以在使用Feign时提供负载均衡的HTTP客户端。
Feign基于Rest风格，简单易懂，他的底层是对HttpClient进行了一层封装，使用十分方便。
NetflixHystrix（熔断）
Hystrix支持回退的概念：当电路断开或出现错误时执行的默认代码路径。要为给定的@FeignClient启用回退，请将Fallback属性设置为实现回退的类名。
我们可以改造一下刚刚的调用架构：
在这里我部署了一台备用服务器，当用户服务宕机了之后，订单服务进行远程调用的时候可以进入备用服务，这样就不会导致系统崩溃。
MQ（消息中间件）
我现在这里有一个需求，修改密码，修改密码需要发送短信验证码，发送短信在短信服务中，修改密码在用户服务中，这个时候就会出现服务调用。
而且我们知道，发送短信一般都是调用第三方的接口，那比如阿里的，既然牵扯到调用，那么就会存在很多不确定因素，比如网络问题。
假如，用户再点击发送短信验证码到时候用户服务调用短信服务，但是在短信服务中执行调用阿里的接口花费了很长的时间。
这个时候就会导致用户服务调短信服务超时，会返回给用户失败，但是，短信最后又发出去了，这种问题怎么解决呢？
我们可以通过消息中间件来实现，使用异步讲给用户的反馈和发送短信分离，只要用户点了发送短信，直接返回成功，然后再启动发送验证码，60秒重发一下，就算发送失败，用户还可以选择重新发送。
MQ不但可以解耦服务，它还可以用来削峰，提高系统的性能，是一个不错的选择。
分布式事务
既然我们使用了分布式架构，那么有一点是我们必须要注意的，那就是事务问题。
如果一个服务的修改依赖另外一个服务的操作，这个时候如果操作不慎，就会导致可怕的后果。
举个例子，两个服务：钱包服务（用于充值提现）、交易钱包服务（用于交易），我现在想从钱包服务中转1000元到交易钱包服务中，我们应该如何保证他们数据的一致性呢？
我这里有两种方案，第一种是通过MQ来保证一致性，另外一种就是通过分布式事务来确保一致性。
MQ确保一致性
- 生成一个订单表，记录着转入转出的状态。
- 向MQ发送一条确认消息。
- 开启本地事务，执行转出操操作，并且提交事务。
交易钱包服务：接收MQ的消息，进行转入操作（此操作需要Ack确认机制的支持）。
系统中会一直定时扫描订单中状态，没有成功的就做补偿机制或者重试机制，这个不是唯一要求。
以上就是MQ确保分布式事务的大致思路，不是唯一，仅供参考。
Seata（分布式事务）
Seata有三个基本组成部分：
- 事务协调器（TC）：维护全局事务和分支事务的状态，驱动全局提交或回滚。
- 事务管理器TM：定义全局事务的范围：开始全局事务，提交或回滚全局事务。
- 资源管理器（RM）：管理分支事务正在处理的资源，与TC进行对话以注册分支事务并报告分支事务的状态，并驱动分支事务的提交或回滚。
Seata管理的分布式事务的典型生命周期：
- TM要求TC开始一项新的全球交易。TC生成代表全局事务的XID。
- XID通过微服务的调用链传播。
- RM将本地事务注册为XID到TC的相应全局事务的分支。
- TM要求TC提交或回滚XID的相应全局事务。
- TC驱动XID对应的全局事务下的所有分支事务以完成分支提交或回滚。
完整的分布式架构
完整的分布式架构如下图：
这就是一套分布式基本的架构，请求从浏览器发出，经过Nginx反向代理到Zuul网关。
网关经过权限校验、然后分别转发到对应的服务中，每个服务都有自己独立的数据库，如果需要跨库查询的时候就需要用到分布式的远程调用（Feign）。
虽然这里我将服务拆分了，但是有一点需要注意的是网关，网关承载着所有的请求，如果请求过大会发生什么呢？
服务宕机，所以一般情况下，网关都是集群部署，不止网关可以集群，其他的服务都可以做集群配置，比如：注册中心、Redis、MQ等等都可以。
那我们将这个流程图再改良一下：
现在这套架构就是比较程数的一套了，不管是性能还是稳定能，都是杠杠的，技术选择性的会也开得差不多了，最后技术总监做了一个总结。
总结
单体服务与分布式服务区别
| 区别 | 传统单体架构 | 分布式服务架构 |
|---|---|---|
| 新功能开发 | 需要时间 | 容易开发和实现 |
| 部署 | 不经常且容易部署 | 经常发布，部署复杂 |
| 隔离性 | 故障影响范围大 | 故障影响范围小 |
| 架构设计 | 难度小 | 难度级数增大 |
| 系统性能 | 响应时间快，吞吐量小 | 响应时间慢，吞吐量大 |
| 系统运维 | 运维简单 | 运维复杂 |
| 新手上手 | 学习曲线大(业务逻辑) | 学习曲线大(构架逻辑) |
| 技术 | 技术单一且封闭 | 技术多样且开放 |
| 测试和查错 | 简单 | 复杂 |
| 系统扩展性 | 扩展性差 | 扩展性很好 |
| 系统管理 | 重点在于开放成本 | 重点在于服务治理和调度 |
什么时候使用分布式/集群？
总结如下几点：
- 单机无法支持的时候。
- 想要更好的隔离性（功能与功能）。
- 想要更好用户体验的时候。
- 想要更好的扩展性。
- 想要更快的响应，更搞得吞吐量。
使用分布式注意事项
虽然现在分布式技术已经十分成熟，但是里面的坑不是一点两点，比如：==如何保证分布式事务的一致性、如何保证服务调用的幂等性、如何保证消息的幂等性、如何设置熔断（服务的降级），如何保证服务的健壮性等等，==这些都是一直需要关注的问题，只有解决了这些问题，你的分布式架构才能真正的立于不败之地。
关于组件停更消息
目前注册中心Eureka、网关Zuul，Feign都相继停更了，停更不代表不能使用，只是除了Bug可能不会主动修复，所以这个时候我们可能就需要选择另外的组件了。
注册中心可以使用Consul、Nacos，Zookeeper，网关则可以通过Gateway替换，OpenFeign替换Fiegn。
所以也没必要听到组件停更的消息就担心Cloud会不会凉，放心，它至少最近几年是不会凉的。
本文内容总结：基于SpringCloud分布式架构，为什么要使用分布式架构，分布式基础组件，Eureka，SpringCloudConfig，NetflixZuul（网关），SpringCloudBus，Feign，NetflixHystrix（熔断），MQ（消息中间件），分布式事务，完整的分布式架构，总结，单体服务与分布式服务区别，什么时候使用分布式/集群？，使用分布式注意事项，关于组件停更消息，
原文链接：https://www.cnblogs.com/burningmyself/p/12941807.html