升级微服务架构2:服务注册

  微服务架构中,服务是最小的可伸缩的独立部署的单位,同一个服务提供可以有多个实例,这些实例都会注册到服务注册中心(Eureka Server)上进行统一的管理及调用的负载均衡。
  因Spring Cloud的是已Java为主要开发语言,本文会先讲Java语言的服务怎么注册到服务中心,然后按照这个逻辑移植到.net版本上。

  1.创建java版服务,并注册到服务中心

  1.1创建一个Eureka Client的Maven项目

  操作模式和上一篇使用Maven创建Eureka Server一样,模块名:userservice(用户服务)

  Eureka Client和web添加依赖:  

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

  创建Spring Boot 启动类并加上注解@SpringBootApplication和@EnableEurekaClient

  

  创建一个User实体,一个UserController类并注解为RestController,写一个返回用列表的方法。  

@RestController
@RequestMapping("/user")
public class UserController {

    @RequestMapping("/getall")
    public List<User> getAll(){
        ArrayList<User> list=new ArrayList<>();
        User user1=new User();
        user1.setAge(10);
        user1.setName("小明");
        user1.setDeleted(false);

        User user2=new User();
        user2.setAge(12);
        user2.setName("小红");
        user2.setDeleted(true);

        list.add(user1);
        list.add(user2);
        return list;
    }

  1.2配置服务中心

  服务配置信息:

server:
  port: 7771 #服务端口

eureka:
  client:
    registerWithEureka: true #是否注册
    fetchRegistry: true #启用客户端缓存
    serviceUrl:
      defaultZone: http://peer1:8881/eureka/,http://peer2:8882/eureka/ #注册到两个服务中心

spring:
  application:
    name: userservice #服务名

  启动该服务,刷新下服务中心,可以看到userservice已经注册成功

  

  访问userservice获取用户的方法,成功返回Json数据

  

  1.3启动多个userservice服务实例并注册

  IEDA修改启动配置,去掉启动仅单个实例 ,Edit Configurations->选择要修改的配置->去掉勾选Single Instance only

  

  

  修改userservice的端口为7772启动一个实例,启动成功后再修改端口为7773启动,这样就有三个实例注册到了服务中心

  

  Java版的服务注册就完成了,安装这个思路使用.net core来创建个同样的服务并注册到服务中心

  2.创建.net core服务,并注册到服务中心

  2.1创建.net core API项目 

  创建一个空解决方案MicroService,然后创建一个.net core web api项目UserService

  

  选择.net core 2.1,项目类型选择API,暂时不用HTTPS,去掉勾选

  

  在NuGet包管理器中搜索Pivotal.Discovery.Client,选择.net core版Pivotal.Discovery.ClientCore,这个组件相当于Java中的Eureka Client组件,用于服务注册,现在最新稳定版为2.0.1,非Core版本也可以,不过最近一次更新是2017年9月份了,这里选择Core版。

  

  2.2配置服务中心

  服务注册配置可参考steeltoe官方文档,和java版的Eureka Client配置大致类似  

  配置文件:   

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*",
/*服务注册配置*/
  "spring": {
    "application": {
      "name": "userservice"/*服务名*/
    }
  },
  "eureka": {
    "client": {
      "serviceUrl": "http://localhost:8881/eureka/", /*Eureka服务地址*/
      "shouldRegisterWithEureka": true,/*是否注册到Eureka Server*/
      "shouldFetchRegistry": true /*开启本地缓存*/
    },
    "instance": {
      "port": 7779 /*服务端口*/
    }
  }
}

  经实践发现Eureka配置文件中的serviceUrl只能用一个地址,多个服务中心地址不知道为什么注册不上,而且只能用localhost或IP,如127.0.0.1,使用peer1,peer2也注册不上,什么原因暂时还没去研究。

  在Program类中指定不同环境配置文件

  参考:http://steeltoe.io/docs/steeltoe-discovery/#reading-configuration-values
  如不指定配置文件会导致报错:ArgumentException: Discovery client type UNKNOWN, check configuration,原因就是找不到配置文件,配置服务发现时可加Configuration.GetSection("eureka").GetChildren().Any()来判断能否取到eureka节点的配置文件。

  

  在Startup启动类ConfigureServices方法中添加服务发现客户端配置,在Configure方法中添加使用服务发现客户端的方法

  这个类似于Spring Boot的启动类中设置Eureka Client注解一样

  

  创建一个User实体,属性和Java端一样,注意java的Getter和Setter对应的字段是小写开头,且默认is开头的序列化会去掉前面的is。

  

  同样创建一个UserController和一个getAll方法,返回用户列表。

  2.3服务启动配置并注册到服务中心

  在项目属性->调试中选择IIS Express调试,并将端口设置为服务端口7779

  

  或者直接在launchSettings.json改端口

  

  启动VS调试该服务,浏览器调用该API,http://localhost:7779/user/getall

  成功返回Json信息

  

  再刷新下Eureka Server,发现服务以及注册成功。

  

  到此.net core的微服务也已成功完成注册。

原文地址:https://www.cnblogs.com/townsend/p/9525745.html

时间: 2024-08-29 22:48:39

升级微服务架构2:服务注册的相关文章

微服务架构与服务治理

Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中涉及的配置管理.服务发现.断路器.智能路由.微代理.控制总线.全局锁.决策竞选.分布式会话和集群状态管理等操作提供了一种简单的开发方式. Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Spring Cloud Config.Spring Cloud Netflix.Spring Cloud0 CloudFoundry.Spring Cloud AW

Spring Cloud构建微服务架构-Hystrix服务降级

在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与订阅的方式互相依赖.由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟,而这些问题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会出现因等待出现故障的依赖方响应而形成任务积压,线程资源无法释放,最终导致自身服务的瘫痪,进一步甚至出现故障的蔓延最终导致整个系统的瘫痪.如果这样的架构存在如此严重的隐患,那么相较传统架构就更加

应用量化时代 | 微服务架构的服务治理之路

技术随业务而生,业务载技术而行. 近些年来,伴随数字经济的发展,在众多企业的数字化转型之路上,云原生.DevOps.微服务.服务治理等成为行业内不断被探讨的新话题.人们在理解和接受这些新型概念的同时,也不断地思考其可能的落地形态.需求是创造发生的原动力,于是一批代表性的开源技术或者框架涌现而出:Kubernetes,Spring Cloud,Service Mesh,Serverless-- 它们炙手可热,大放异彩.然而在具体落地过程中却步履维艰,磕磕绊绊. 本文试图结合企业业务的核心诉求,以应

浅谈微服务架构与服务治理的Eureka和Dubbo

前言 本来计划周五+周末三天自驾游,谁知人算不如天算,周六恰逢台风来袭,湖州附近的景点全部关停,不得已只能周五玩完之后,于周六踩着台风的边缘逃回上海.周末过得如此艰难,这次就聊点务虚的话题,一是浅谈微服务的架构设计,二是聊聊微服务中广泛用于服务治理的Eureka与RPC框架Dubbo异同点. 一.微服务的架构设计 之所以想聊一下这个话题,主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两个人之手,却不约而同的使用了相同的设计理念,项目结构非常类似.又想到就职于上家公司时接触到的项

Spring Cloud构建微服务架构—创建“服务注册中心”

创建一个基础的Spring Boot工程,命名为eureka-server,并在pom.xml中引入需要的依赖内容: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.4.RELEASE</version> <relativePath

Spring Cloud构建微服务架构-创建“服务提供方”

下面我们创建提供服务的客户端,并向服务注册中心注册自己.本文我们主要介绍服务的注册与发现,所以我们不妨在服务提供方中尝试着提供一个接口来获取当前所有的服务信息. 首先,创建一个基本的Spring Boot应用.命名为eureka-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 <parent> <groupId>org.spr

Spring Cloud构建微服务架构:服务消费(基础)

使用LoadBalancerClient 在Spring Cloud Commons中提供了大量的与服务治理相关的抽象接口,包括DiscoveryClient.这里我们即将介绍的LoadBalancerClient等.对于这些接口的定义我们在上一篇介绍服务注册与发现时已经说过,Spring Cloud做这一层抽象,很好的解耦了服务治理体系,使得我们可以轻易的替换不同的服务治理设施. 从LoadBalancerClient接口的命名中,我们就知道这是一个负载均衡客户端的抽象定义,下面我们就看看如何

Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)

动手试一试 在开始使用Spring Cloud Hystrix实现断路器之前,我们先拿之前实现的一些内容作为基础,其中包括: eureka-server工程:服务注册中心,端口:1001 eureka-client工程:服务提供者,两个实例启动端口分别为2001 下面我们可以复制一下之前实现的一个服务消费者:eureka-consumer-ribbon,命名为eureka-consumer-ribbon-hystrix.下面我们开始对其进行改在: 第一步:pom.xml的dependencies

Spring Cloud构建微服务架构 分布式服务跟踪(跟踪原理)【Dalston版】

通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一些要点. 分布式系统中的服务跟踪在理论上并不复杂,它主要包括下面两个关键点: 为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识,同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识,直到返回给请求方为止,这个唯一标识就是前文中提到的Trace ID.

Spring Cloud构建微服务架构 分布式服务跟踪(抽样收集)【Dalston版】

通过Trace ID和Span ID已经实现了对分布式系统中的请求跟踪,而这些记录的跟踪信息最终会被分析系统收集起来,并用来实现对分布式系统的监控和分析功能,比如:预警延迟过长的请求链路.查询请求链路的调用明细等.此时,我们在对接分析系统时就会碰到一个问题:分析系统在收集跟踪信息的时候,需要收集多少量的跟踪信息才合适呢? 理论上来说,我们收集的跟踪信息越多就可以更好的反映出系统的实际运行情况,并给出更精准的预警和分析,但是在高并发的分布式系统运行时,大量的请求调用会产生海量的跟踪日志信息,如果我