Spring Cloud Gray 是一套开源的微服务灰度路由解决方案，它由 spring-cloud-gray-client，spring-cloud-gray-client-netflix 和 spring-cloud-tray-server，spring-cloud-gray-webui 组成。
spring-cloud-gray-client 定义了一套灰度路由决策模型，灰度信息追踪模型，以及和 spring-cloud-gray-server的基本通信功能。
spring-cloud-gray-client-netflix 在 spring-cloud-gray-client 的基础上集成了微服务注册中心 eureka，扩展ribbon 的负载均衡规则，提供了对 zuul、feign、RestTemplate 的灰度路由能力，并且无缝支持 hystrix 线程池隔离。
spring-cloud-gray-server 负责灰度决策、灰度追踪等信息的管理以及持久化。
spring-cloud-gray-webui 提供操作界面。
SpringCloudGray 能做什么
1. 金丝雀测试
先发布1台实例，用于测试验证，指定测试的流量进入这台实例，其它流量依然进入其它正常的实例。优势在于发布成本小，快速测试，并且不影响正常用户体验影响，即使测试不通过，也只需回滚这一台实例，用户无感知。
2. 灰度放量
通过金丝雀测试后，可以逐渐放量到新的版本上。例如，根据userId或者ip放5%的流量到其中一台灰度实例上，观察一段时间没异常，可调整放入20%的流量，如果一台实例扛不住，可再发一台或多台实例。将发布产生的风险保持在可控范围内。
3. 切断实例流量
当线上出现问题，可将某台实例的流量切断，保留现场，设置指定的请求进入实例，在线调试并且不影响其它用户。
4. 数据透传
借助灰度追踪的能力，在网关处记录用户请求的最初的数据，可以将之透传到请求完整的调用链中。
5. 借助“破窗”能力，实例蓝绿发布
首次上灰度时，会存在两种环境，一种是已经依赖了灰度客户端的环境，另一种是正常运行的当前环境。假如微服务的负载均衡是由 ribbon 实现，那么当前环境会请求路由到实例状态为 UP 的实例上，而依赖了灰度客户端的环境，则可以通过"破窗"能力，跟灰度路由结合，可以将匹配灰度策略的请求路由到实例状态为 STARTING 的实例上，不匹配灰度策略的请求路由到实例状态为 UP 的实例上。
设计思想
在微服务架构中，接口的调用通常是服务消费方按照某种负载均衡策略去选择服务实例；但这无法满足线上更特殊化的一些路由逻辑，比如根据一次请求携带的请求头中的信息路由到某一个服务实例上。Spring Cloud Gray 正是为此而创建。
在Spring Cloud Gray 中定义了几个角色灰度客户端(gray-client)、灰度管控端(gray-server)、注册中心。
注册中心 负责服务的注册和发现。
灰度客户端 灰度的客户端是指依赖了spring-cloud-gray-client的服务，一般是指服务消费方。
灰度管控端 负责灰度信息的管理、持久化等维护工作。
灰度客户端会从灰度管控端拉取一份灰度信息的清单，并在内存中维护这份清单信息，清单中包含服务，服务实例，灰度策略，灰度追踪字段等。当请求达到网关时，网关就会在灰度追踪中将需要透传的信息记录下来，并将传递给转发的服务实例，后面的接口调用也会按照同样的逻辑将追踪信息透传下去，从而保证所有一个请求在微服务调用链中的灰度路由。
如下图所示：
项目扩展
项目已经实现了灰度的内核，如果要与其它的注册中心或者负载均衡中间件集成，只需实现相应的 plugin 即可，spring cloud gray 已经提供了 eureka、ribbon、feign、zuul 以及 spring cloud gateway 和 spring cloud stream 的 plugin，添加相应的 plugin 依赖即可。
版本支持
目前有三个分支，对 spring cloud 的支持分别如下
| 项目版本 | srpingcloud版本 | springboot版本 |
|---|---|---|
| A.1.1.0 | Edgware.SR6 | 1.5.22.RELEASE |
| B.0.0.1 | Finchley.SR4 | 2.0.9.RELEASE |
| C.0.0.1-SNAPHOST | Greenwich.SR2 | 2.1.7.RELEASE |
-
转载： https://www.appblog.cn/2020/09/16/Spring%20Cloud%20Gray%20%E9%85%8D%E7%BD%AE%E5%8F%82%E6%95%B0/ 2020博客地址汇总 2019年博客汇总 管控端 gray.server.discovery Property Name Default Value Remarks evictionEnabled t
-
Spring Cloud Stream Kafka 官方网页 Apache Kafka 主要用途 消息中间件 流式计算处理 日志 下载地址：Apache Kafka 执行脚本目录 /bin windows 在其单独的目录 快速上手 下载并且解压kafka压缩包 运行服务 以Windows为例，首先打开cmd： 1. 启动zookeeper： bin\windows\zookeeper-serve
-
Zuul基本使用 @EnableEurekaClient @EnableDiscoveryClient Nginx+Lua Lua：控制规则（A/B Test） Spring Cloud 学习技巧： 善于定位应用：Feign、ConfigServer、Eureka、Zuul、Ribbon定位应用，配置方式是不同 增加@EnableZuulProxy @SpringBootApplication
-
spring cloud config在分布式系统中提供了服务端和客户端支持来提供外部化的配置。配置服务器有一个中心配置仓库，来管理应用程序所有环境的外部配置属性。spring cloud config很适合与Spring应用程序配合使用,可以被用于任何应用程序。随着应用程序通过部署管道从开发到测试到生产管理这些环境之间的配置,确保应用程序拥有他们所需要的一切运行时迁移。服务器的默认实现存储后端使
-
null null
-
我在微服务之间的通信上遇到了麻烦。我有许多spring boot应用程序，它们之间有许多请求HTTP和AMQP（RabbitMQ）。在本地（在dev中），我使用没有Docker图像的Eureka（Netflix Oss）。
-
“在微服务之间添加的同步依赖关系越多，例如查询请求，客户端应用程序的总体响应时间就越差。 “这是真的吗？我认为在同步通信中，我们比异步通信更直接地得到反馈。例如，假设一个用户向微服务a发送http请求，微服务a又异步地向另一个微服务B发送请求，并异步地等待它的答复。如果微服务B关闭，那么用户将等待到超时才能得到响应，而在同步通信中，他将立即得到响应。
-
我们有一个使用Spring boot编写的微服务，它有自己的NoSQL数据存储。我们正在开发功能，希望删除一些旧数据（数量为50万个文档），并希望根据数据存储中存在的特定类型的记录定期（每天一次）删除这些数据。 拥有一个每天运行一次并进行删除的调度程序是正确的方法吗？另外，由于它是一个微服务，并且它的几个实例将运行，我们如何控制这个调度程序仅在一个实例上运行？
-
在单体架构时，因为服务不会经常和动态迁移，所有服务地址可以直接在配置文件中配置，所以也不会有服务发现的问题。但是对于微服务来说，应用的拆分，服务之间的解耦，和服务动态扩展带来的服务迁移，服务发现就成了微服务中的一个关键问题。 服务发现分为客户端服务发现和服务端服务发现两种，架构如下图所示。 这两种架构都各有利弊，我们拿客户端服务发现软件Eureka和服务端服务发现架构Kubernetes/SkyD
-
基本 Nest 微服务是一种使用与HTTP不同的传输层的应用程序。 安装 首先，我们需要安装所需的软件包： $ npm i --save @nestjs/microservices 概述 通常，Nest支持一系列内置的传输器。它们基于 请求-响应 范式，整个通信逻辑隐藏在抽象层之后。多亏了这一点，您可以轻松地在传输器之间切换，而无需更改任何代码行。我们不支持具有基于日志的持久性的流平台，例如 Ka
-
我读了一些文章，看了一些视频，但在为这些微服务提供服务方面，没有找到具体的建议。我的理解是，他们应该使用自己的应用程序服务器。 我的问题是它们应该部署在不同的服务器上，还是没关系。 当它们在同一台服务器（计算机）上提供服务时，不会有端口冲突吗？
-
我有两个微服务，例如A和B。微服务B有剩余的enpoint，必须只能从微服务A访问。如何限制微服务之间的访问？如果可能的话，最佳做法是什么？ 我正在使用Spring Cloud Security（oAuth2， jwt）。