Nepxion Discovery是一款对Spring Cloud的服务注册发现的增强中间件，其功能包括多版本灰度发布，黑/白名单的IP地址过滤，限制注册等，支持Eureka、Consul和Zookeeper。现有的Spring Cloud微服务可以方便引入该插件，代码零侵入，使用者只需要做如下简单的事情：
引入相关Plugin Starter依赖到pom.xml
必须为微服务定义一个版本号（version），在application.properties或者yaml的metadata里
必须为微服务自定义一个便于为微服务归类的Key，例如组名（group）或者应用名（application），在application.properties或者yaml的metadata里，便于远程配置中心推送和灰度界面分析
使用者只需要关注相关规则推送。可以采用如下方式之一
通过远程配置中心推送规则
通过控制台界面推送规则
通过客户端工具（例如Postman）推送推测
功能
实现对基于Spring Cloud的微服务和Zuul网关的支持
具有极大灵活性 - 支持在任何环节做过滤控制和版本灰度发布
具有极小限制性 - 只要开启了服务注册发现，程序入口加了@EnableDiscoveryClient
实现服务注册层面的控制
基于黑/白名单的IP地址过滤机制禁止对相应的微服务进行注册
基于最大注册数的限制微服务注册。一旦微服务集群下注册的实例数目已经达到上限，将禁止后续的微服务进行注册
实现服务发现层面的控制
基于黑/白名单的IP地址过滤机制禁止对相应的微服务被发现
基于版本配对，通过对消费端和提供端可访问版本对应关系的配置，在服务发现和负载均衡层面，进行多版本访问控制
实现灰度发布
通过规则改变，实现灰度发布
通过版本切换，实现灰度发布
实现通过XML进行上述规则的定义
实现通过事件总线机制（EventBus）的功能，实现发布/订阅功能
对接远程配置中心，默认集成阿里巴巴的Nacos，异步接受远程配置中心主动推送规则信息，动态改变微服务的规则
结合Spring Boot Actuator，异步接受Rest主动推送规则信息，动态改变微服务的规则
结合Spring Boot Actuator，动态改变微服务的版本
在服务注册层面的控制中，一旦禁止注册的条件触发，主动推送异步事件，以便使用者订阅
实现通过Listener机制进行扩展
使用者可以自定义更多的规则过滤条件
使用者可以对服务注册发现核心事件进行监听
实现支持Spring Boot Actuator和Swagger集成
实现独立控制台，支持对规则和版本集中管理，未来考虑界面实现
实现支持未来扩展更多的服务注册中心
实现图形化的灰度发布功能
架构
简单描述一下，本系统的核心模块“基于版本控制的灰度发布”，从网关（Zuul）开始的灰度发布操作过程
灰度发布前
假设当前生产环境，调用路径为网关(V1.0)->服务A(V1.0)->服务B(V1.0)
运维将发布新的生产环境，部署新服务集群，服务A(V1.1)，服务B(V1.1)
由于网关(1.0)并未指向服务A(V1.1)，服务B(V1.1)，所以它们是不能被调用的
灰度发布中
新增用作灰度发布的网关(V1.1)，指向服务A(V1.1)->服务B(V1.1)
灰度网关(V1.1)发布到服务注册发现中心，但禁止被服务发现，网关外的调用进来无法负载均衡到网关(V1.1)上
在灰度网关(V1.1)->服务A(V1.1)->服务B(V1.1)这条调用路径做灰度测试
灰度测试成功后，把网关(V1.0)指向服务A(V1.1)->服务B(V1.1)
灰度发布后
下线服务A(V1.0)，服务B(V1.0)，灰度成功
灰度网关(V1.1)可以不用下线，留作下次版本上线再次灰度发布
架构图
兼容
版本兼容情况
Spring Cloud F版，请采用4.x.x版本，具体代码参考master分支
Spring Cloud C版、D版和E版，请采用3.x.x版本，具体代码参考Edgware分支
4.x.x版本由于Swagger和Spring Boot 2.x.x版本的Actuator用法有冲突，故暂时不支持Endpoint功能，其他功能和3.x.x版本一致
中间件兼容情况
Consul
Spring Cloud F版，最好采用Consul的1.2.1服务器版本（或者更高），从https://releases.hashicorp.com/consul/1.2.1/获取
Spring Cloud C版、D版和E版，必须采用Consul的0.9.3服务器版本（或者更低），从https://releases.hashicorp.com/consul/0.9.3/获取
Zookeeper
Spring Cloud F版，必须采用Zookeeper的3.5.x服务器版本（或者更高）
Spring Cloud C版、D版和E版，最好采用Zookeeper的3.5.0以下服务器版本（或者更低）
Eureka
跟Spring Cloud版本保持一致
-
Nepxion Discovery 项目的 github 地址为：https://github.com/Nepxion/Discovery。以下分析基于: Nepxion Discovery 版本号：6.4.0-SNAPSHOT Discovery【探索】微服务框架，基于Spring Cloud Discovery服务注册发现、Ribbon负载均衡、Feign和RestTemplate调用等组件全
-
在进行微服务调用的时候，不管是服务之间(A 服务调用 B 服务)还是服务内部调用(服务 A 某个方法进行里有异步)都存在异步调用。但是 Nepxion Discovery 在进行参数传递的时候很多情况是使用的是基于 ThreadLocal。 1、Discovery Agent 简介 ThreadLocal 的作用是提供线程内的局部变量，在多线程环境下访问时能保证各个线程内的ThreadLocal变
-
在之前的文章中只是简单的讲解了一下 Nepxion Discovery 服务注册添加元数据到注册中心里面以及服务注册与发现 Listener 的扩展。其实在服务发现的时候 Nepxion Discovery 进行了自己的扩展才能做到通过 restful header 传入以及配置中心配置的灰度参数再获取到某个服务的列表的时候，才能够选择灰度合适的服务实例。要理解 Nepxion Discovery
-
最近公司项目在做架构升级，升级为 Spring Cloud，我们希望能够做到服务的灰度发布，根据访问量逐渐切换用新版本替换老版本，并且能够做到代码零入侵的，毕竟每次发布要修改代码真的不是什么好的体验，而且容易引出其它的非代码级别的错误导致无法发布成功。但是 Spring Cloud 在这一方面好像没有提供什么方案。因此我们在网上大范围的查找，终于找到了一款服务我们需求的灰度发布工具Nepxion
-
一、Nepxion Discovery Spring Cloud灰度发布神器 二、Nepxion Discovery 灰度发布初体验 三、Nepxion Discovery 项目结构简介 四、Nepxion Discovery 之 Spring Cloud 服务注册抽象 五、Nepxion Discovery 之 服务注册发现增强 六、Nepxion Discovery 之 Spring Clou
-
https://github.com/Nepxion/Discovery/tree/002e957bc8677e69c706ec77c2a98e35bc419402 https://gitee.com/gengzi/Nepxion-Discovery https://blog.csdn.net/ankeway/article/details/89329152 https://www.iqiyi.c
-
微服务治理过程中，经常会涉及注册启动的服务到第三方集群，比如 consul / etcd 等等，本章以 Swoft 框架中使用 swoft-consul 组件，实现服务注册与发现为例。 服务注册 无论是 http / rpc / ws 服务，启动的时候只需监听 SwooleEvent::START 事件，即可把启动的服务注册到第三方集群。 注册服务 本章这里以启动 http server 注册服务
-
服务注册与发现是所有的分布式服务都会涉及到的,常见的有zookeeper 、eureka、consul、etcd。 Uragano目前支持consul和zookeeper,推荐使用consul,因为它安装配置简单，支持多数据中心，支持k/v存储，可以扩展为配置中心。不推荐用zookeeper，因为CAP理论，zk是选择CP而不是AP，所以不适合做服务发现，以后会考虑集成eureka。 题外话：特别
-
1、前言 本文通过创建 provider-service、consumer-service 两个微服务，并通过 feign 接口调用来演示 Spring Cloud 整合 Consul。阅读本文需要前置知识： Spring Boot Spring Cloud Spring Cloud Feign 2、搭建 provider-service 服务 2.1、创建 maven 模块 创建provider
-
本文向大家介绍SpringBoot的服务注册与发现示例，包括了SpringBoot的服务注册与发现示例的使用技巧和注意事项，需要的朋友参考一下 微服务 实践“微服务”自然要学习如何做服务注册与发现 基于SpringBoot来进行微服务的学习，自然选择了与之息息相关的SpringCloud;当然可以选择其他的技术进行，比如dubbo 也可以用zookeeper来实现服务注册与发现，至于zookeep
-
在进行服务拆分之后，服务的数量会变得非常多，而每个服务又可能会有非常多的集群节点来提供服务，那么为保障系统的正常运行，必然需要有一个中心化的组件完成对各个服务的整合，即将分散于各处的服务进行汇总，汇总的信息可以是提供服务的组件名称、地址、数量等，每个组件拥有一个监听设备，当本组件内的某个服务的状态变化时报告至中心化的组件进行状态的更新。服务的调用方在请求某项服务时首先到中心化组件获取可提供该项服务
-
本文向大家介绍springcloud干货之服务注册与发现（Eureka），包括了springcloud干货之服务注册与发现（Eureka）的使用技巧和注意事项，需要的朋友参考一下 使用Eureka实现服务治理 作用：实现服务治理（服务注册与发现） 简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。而Spring Cloud Netflix项
-
本文向大家介绍Dubbo服务注册与发现的流程图？相关面试题，主要包含被问及Dubbo服务注册与发现的流程图？时的应答技巧和注意事项，需要的朋友参考一下 该图来自 Dubbo 官网，供你参考，如果你说你熟悉 Dubbo, 面试官经常会让你画这个图，记好了。 流程说明： Provider(提供者)绑定指定端口并启动服务 指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存
-
注册服务 Frontier带有一些非常基本的基础层服务，也包括了大部分的注册商(registrar)。注册商由3个部分组成。 GlobalRegistrar将名称（字符串）关联到帐户（地址）。 HashReg将散列关联到哈希（将任何对象映射到“内容”哈希)。 UrlHint将内容哈希值关联到提示内容的位置。只有在内容存储不是内容寻址的情况下才需要，否则内容哈希已经是内容地址。如果使用它，则从URL