eureka

创建Spring Config工程

北慕城南 提交于 2020-03-21 19:59:09
1、初始化工程 https://start.spring.io/ 选config server Eureka Discovery 2、导入IDE改改 入口类上加@EnableConfigServer @EnableDiscoveryClient application.yml server: port: 1027 spring: application: name: vishnu-config cloud: config: server: git: uri: https://gitee.com/frankawp/vishnu-config eureka: instance: prefer-ip-address: true lease-renewal-interval-in-seconds: 5 lease-expiration-duration-in-seconds: 20 client: serviceUrl: defaultZone: http://localhost:1026/eureka registry-fetch-interval-seconds: 10 把配置文件传到这个git上。 vishnu-userinfo-dev.yml 启动后在 localhost:1027/vishnu-userinfo/dev 上可以看到这个配置文件就对了 先启动eureka

【微服务架构】SpringCloud之Feign(五)

非 Y 不嫁゛ 提交于 2020-03-21 15:39:55
Feign简介 Feign 是一个声明web服务客户端,这便得编写web服务客户端更容易,使用Feign 创建一个接口并对它进行注解,它具有可插拔的注解支持包括Feign注解与JAX-RS注解,Feign还支持可插拔的编码器与解码器,Spring Cloud 增加了对 Spring MVC的注解,Spring Web 默认使用了HttpMessageConverters, Spring Cloud 集成 Ribbon 和 Eureka 提供的负载均衡的HTTP客户端 Feign. 声明式REST客户端:Feign 先要启动 eureka_register_service 工程(注册中心)和 biz-service-0 工程(服务生产者) 创建一个maven工程eureka_feign_client pom.xml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version> 1.4 . 3

微服务系列之 Consul 服务注册中心

假如想象 提交于 2020-03-20 11:52:42
3 月,跳不动了?>>> 原文链接: https://mrhelloworld.com/posts/spring/spring-cloud/consul-service-registry/   Netflix Eureka 2.X https://github.com/Netflix/eureka/wiki 官方宣告停止开发,但其实对国内的用户影响甚小,一方面国内大都使用的是 Eureka 1.X 系列,并且官方也在积极维护 1.X https://github.com/Netflix/eureka/releases。 The existing open source work on eureka 2.0 is discontinued. The code base and artifacts that were released as part of the existing repository of work on the 2.x branch is considered use at your own risk. Eureka 1.x is a core part of Netflix's service discovery system and is still an active project. 翻译: 有关 eureka 2.0 的现有开源工作已停止。在 2.x

Spring Cloud微服务架构从入门到会用(二)—服务注册中心Eureka

倖福魔咒の 提交于 2020-03-19 16:47:09
3 月,跳不动了?>>> 因为微服务各个服务之间是需要相互调用的,而且各个应用独立部署,我们不能在每个应用中写上需要调用的服务的ip地址和端口号,而且如果被调用者有很多我们改怎么选择,所以需要一个微服务注册中心,当我们需要调用的时候,由注册中心告诉我们被调用方的ip是什么,所以有了Eureka。 Eureka 是 Netflix 开发的,一个基于 REST 服务的,服务注册与发现的组件。 这里我们创建一个多module的maven工程,eureka作为其中一个module,且各个module没有任何依赖,都是单体应用。 这里我们采用各个组件的版本: Spring Boot : 2.2.5.RELEASE Spring Cloud : Hoxton.SR3 Jdk : 1.8 1. 创建spring-cloud-example工程 这里我们创建一个普通的maven项目,项目名为:spring-cloud-example,创建成功之后,把src和下边的文件夹都删掉。这个大工程主要是用来放各个module的,本身没有任何代码。 2. 创建server-eureka 2.1 创建SpringBoot moudule 输入对应的Group和Artifact,点击下一步下一步,直到完成创建。 2.2 引入eureka依赖 在server-eureka的pom

学习微服务的服务消费者——ribbon和restTemplate

北慕城南 提交于 2020-03-18 20:16:00
3 月,跳不动了?>>> 微服务会把一个单个大项目拆分成多个独立的小服务,这些小服务之间的调用采用的是http restful,spring cloud提供了ribbon+restTemplate 。ribbon是一个负载均衡的客户端。 1.首先接着上篇博客的服务,启动eureka-server工程,启动eureka-client-say-hi工程,它的端口为8792,然后更改端口由8792-》8793,并启动,发现注册中心8792为Down了 此时点击EditConfiguration 将Single instance only前面对勾去掉;然后启动两个实例 此时发现eureka-server注册了2个实例,这就相当于一个小的集群。 2.新建一个服务消费者 build.gradle文件 buildscript { ext { springBootVersion = '2.0.4.RELEASE' } repositories { mavenCentral() } dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}") } } apply plugin: 'java' apply plugin: 'eclipse' apply plugin

Eureka服务注册与发现和Ribbon负载均衡究竟怎么讲才清楚?

别等时光非礼了梦想. 提交于 2020-03-18 20:04:10
3 月,跳不动了?>>> Eureka服务注册与发现 Eureka简介 在介绍Eureka前,先说一下CAP原则 CAP原则又称CAP定理,指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得,Eureka遵循的事AP原则。 关于Eureka Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中,以实现SpringCloud的服务发现功能。 SpringCloud 封装了Netflix公司开发的Eureka模块来实现服务注册和发现(请对比Zookeeper)。Eureka Server 作为服务注册功能的服务器,它是服务注册中心。而系统中的其他微服务,使用 Eureka 的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块(比如Zuul)就可以通过 Eureka Server 来发现系统中的其他微服务,并执行相关的逻辑。 补充:AWS域是什么呢

SpringCloud 使用SpringCloudConfig搭建远程配置中心

北城余情 提交于 2020-03-18 19:46:33
3 月,跳不动了?>>> @[toc] SpringCloud 使用SpringCloudConfig配置远程配置中心 前言 随着服务数量越来越多,模块越来越多我们的各种服务的配置文件也越来越多,同时多个服务在项目中采用配置文件的方式,越来越显得力不从心,往往一次更改配置文件很是麻烦,这时候SpringCloudConfig出现,他的出现让我们集中配置配置文件,服务端集中管理,客户端一次读取,同时采用更改推送的方式,即时同步更新配置文件,可谓方便至极,极大的解放了长修改多个配置文件生产力。 远程git仓库 首先需要注册一个远程存储配置文件的存储仓库,用来存储各种配置文件。 新建一个git仓库 然后新建一个mysql的配置文件 一个测试 一个dev 然后提交到Github 点击红色区域获取git链接 内容如下 # 数据库驱动: driverClassName=com.mysql.jdbc.Driver # 数据库链接地址: url=jdbc:mysql://101.10.10.10:3306/db_app?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8 #数据库用户名: username=root # 数据库密码: password=root 配置注册中心 导入config-server依赖 <!--

eureka 自我保护机制

╄→尐↘猪︶ㄣ 提交于 2020-03-18 19:27:31
3 月,跳不动了?>>> @[toc] eureka 自我保护机制 如果出现下面红色框内 信息,说明eureka 开启了自我保护机制。 在默认情况下eureka会自动开启自我保护机制 关闭自我保护机制呢。 yml文件中配置 eureka: # 禁用eureka 自我保护机制 false 表示关闭 默认是ture 表示 开启 server: enable-self-preservation: false 来源: oschina 链接: https://my.oschina.net/u/3983909/blog/3197619

Spring cloud eureka 服务注册

你离开我真会死。 提交于 2020-03-18 19:25:04
3 月,跳不动了?>>> @[toc] Spring cloud 简介 Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。 Spring Cloud组成编辑 Spring Cloud的子项目,大致可分成两类,一类是对现有成熟框架”Spring Boot化”的封装和抽象,也是数量最多的项目;第二类是开发了一部分分布式系统的基础设施的实现,如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。对于我们想快速实践微服务的开发者来说,第一类子项目就已经足够使用,如: Spring Cloud Netflix   是对Netflix开发的一套分布式服务框架的封装,包括服务的发现和注册,负载均衡、断路器、REST客户端、请求路由等。 Spring Cloud Config   将配置信息中央化保存,

一文解读微服务架构的服务与发现—Spring Cloud

旧城冷巷雨未停 提交于 2020-03-17 22:55:45
一、为什么需要服务发现 简单来说,服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务,而微服务在这个基础上要更彻底地去耦合(不再共享DB、KV,去掉重量级ESB),并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈,而Spring Cloud就是其中的佼佼者。 DevOps是英文Development和Operations的合体,他要求开发、测试、运维进行一体化的合作,进行更小、更频繁、更自动化的应用发布,以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚,也方便运维和管理。这个理念与微服务理念不谋而合。 接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。 1.1 从使用nginx说起 最初的服务化解决方案是给提供相同服务提供一个统一的域名,然后服务调用者向这个域名发送HTTP请求,由Nginx负责请求的分发和跳转。 这种架构存在很多问题: Nginx作为中间层,在配置文件中耦合了服务调用的逻辑,这削弱了微服务的完整性,也使得Nginx在一定程度上变成了一个重量级的ESB。 服务的信息分散在各个系统,无法统一管理和维护。每一次的服务调用都是一次尝试,服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。 无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率