spring cloud如何在任意地方获取fegin 客户端实例

Spring Cloud项目的既定目标在于为Spring开发人员提供一整套易于使用的工具集，从而保证其轻松构建起自己需要的分布式系统方案。为了实现这一目标，Spring Cloud以Netflix OSS堆栈为基础将大量实现堆栈加以整合并打包。这些堆栈而后可以通过大家所熟知的各类基于注释的配置工具、Java配置工具以及基于模板的编程工具实现交付。下面就让我们一起了解Spring Cloud当中的几类常见组件。 Spring Cloud Config Server Spring Cloud Config Server能够提供一项具备横向扩展能力的集中式配置服务。它所使用的数据被保存在一套可插拔库层当中，后者目前能够支持本地存储、Git以及Subversion。通过利用一套版本控制系统作为配置存储方案，开发人员能够轻松实现版本与审计配置的内容调整。 如何利用Spring Cloud构建起自我修复型分布式系统 配置内容会以Java属性或者YAML文件的形式体现。该Config Server会将这些文件合并为环境对象，其中包含易于理解的Spring属性模型以及作为REST API存在的配置文件。任何应用程序都能够直接调用该REST API当中所包含的配置数据，但我们也可以将智能客户端绑定方案添加到Spring Boot应用程序当中，并由后者自动将接收自Config Server的配置信息分配至任意本地配置当中。 Spring Cloud Bus Spring Cloud Config Server是一套强大的配置分发机制，能够在保障一致性的前提下将配置内容分发到多个应用程序实例当中。然而根据其设计思路的限定，我们目前只能在应用程序启动时对其配置进行更新。在向Git中的某一属性发送新值时，我们需要以手动方式重启每个应用程序进程，从而保证该值被切实纳入应用当中。很明显，大家需要能够在无需重启的前提下完成对应用程序配置内容的更新工作。 如何利用Spring Cloud构建起自我修复型分布式系统 Spring Cloud Bus的任务正是为应用程序实例添加一套管理背板。它目前依靠将一套客户端绑定至一组AMQP交换与队列当中来实现，但这一后端在设计上也实现了可插拔特性。Spring Cloud Bus为我们的应用程序带来了更多管理端点。在图二中，我们可以看到一个面向greeting属性的值被发送至Git当中，而后一条请求被发送至应用A中的/bus/refresh端点。该请求会触发以下三个事件： 应用A从Config Server处请求获取最新版本的配置内容。任意注明了@RefreshScope的Spring Bean都会被重新初始化并载入新的配置内容。 应用A向AMQP交换机制发送一条消息，表明其已经收到更新指示。 通过监听AMQP队列而被纳入Cloud Bus的应用B与应用C会获取到上述消息，并以与应用A同样的方式实现配置更新。 现在我们已经有能力在无需重启的情况下对应用程序配置进行更新了。