springboot服务注册与发现？

springboot-服务治理

由于微服务数量太多导致维护成本巨大，服务治理就是来解决这个问题。服务治理就是让服务子维护，微服务做为服务提供方主动向服务治理中心注册，服务的消费者通过服务治理中心查询需要的服务并调用，如下图：

    springcloud通过对Eureka的二次封装来实现服务治理。Eureka提供了服务端和客户端，服务端是服务注册中心，客户端完成服务的注册和发现，其关系如下：

    Eureka的架构：

注：1.微服务A向Eureka Server注册，并通过心跳机制告诉Server自己的状态。如果微服务A需要下线也要告诉Server；如果一段时间Server没有收到微服务A的心跳，那么认为微服务A已经宕机

        2.微服务B从Server中发现微服务A，然后向微服务A发起请求

        3.Server 有多个节点，一旦一个节点宕机，还能用其他的Server

        1.创建springboot工程 ,并选择Eureka Server

2. 在启动类上加注解 @EnableEurekaServer

3.增加application.yml配置文件

4.启动2台eureka server ，将自己注册到对方

    spring-boot:run -Dport=6868 -Deureka.server=

    spring-boot:run -Dport=6869 -Deureka.server=

5.通过浏览器访问，查看是否启动成功   

        eureka server 有2个，端口号是6868，6869 ，说明启动成功

    1.创建springboot工程 ,并选择Eureka Server

    2.增加application.yml配置文件

3.具体的controller、server、mapper开发省略，见springboot

4.启动2台微服务

    spring-boot:run -Dport=6801 -Deureka.server=

    spring-boot:run -Dport=6802 -Deureka.server=

5.验证微服务是否注册到eureka中

Spring Cloud Eureka服务注册中心

服务治理：Spring Cloud Eureka

Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix

Eureka做了二次封装，主要负责完成微服务架构中的服务治理功能。Spring Cloud通过为

Eureka增加了Spring Boot风格的自动化配置，我们只需通过简单引入依赖和注解配置就能

让Spring Boot构建的微服务应用轻松地与Eureka服务治理体系进行整合。

在本章中，我们将指引读者学习下面这些核心内容，并构建起用于服务治理的基础设

施。

·构建服务注册中心

·服务注册与服务发现

。Eureka的基础架构

Eureka的服务治理机制

Eureka的配置

服务治理

服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务

实例的自动化注册与发现。为什么我们在微服务架构中那么需要服务治理模块呢？微服务

系统没有它会有什么不好的地方吗？

在最初开始构建微服务系统的时候可能服务并不多，我们可以通过做一些静态配置来

完成服务的调用。比如，有两个服务A和B,其中服务A需要调用服务B来完成一个业务

操作时，为了实现服务的高可用，不论采用服务端负载均衡还是客户端负载均衡，都需

要手工维护服务的具体实例清单。但是随着业务的发展，系统功能越来越复杂，相应一下的

微服务应用也不断增加，我们的静态配置就会变得越来越难以维护。并且面对不断发展的

业务，我们的集群规模、服务的位置、服务的命名等都有可能发生变化，如果还是通过手

工维护的方式，那么极易发生错误或是命名冲突等间题。同时，对于这类静态内容的维护

为了解决微服务架构中的服务实例维护问题，产生了大量的服务治理框架和产品。这

也必将消耗大量的人力。

些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化

管理。

服务注册：在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册

中心登记自己提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告

知注册中心，注册中心按服务名分类组织服务清单。比如，我们有两个提供服务A

的进程分别运行于192.168.0.100：8000和192.168.0.101：8000位置上，

另外还有三个提供服务B的进程分别运行于192.168.0.100：9000、

192.168.0.101:9000、192.168.0.102:9000位置上。当这些进程均启动，

并向注册中心注册自己的服务之后，注册中心就会维护类似下面的一个服务清单。

另外，服务注册中心还需要以心跳的方式去监测清单中的服务是否可用，若不可用

需要从服务清单中剔除，达到排除故障服务的效果。

服务名

位置

服务A

192.168.0.100:8000、192.168.0.101:8000

服务B

192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000

服务发现：由于在服务治理框架下运作，服务间的调用不再通过指定具体的实例地

址来实现，而是通过向服务名发起请求调用实现。所以，服务调用方在调用服务提

供方接口的时候，并不知道具体的服务实例位置。因此，调用方需要向服务注册中

心咨询服务，并获取所有服务的实例清单，以实现对具体服务实例的访问。比如，

现有服务C希望调用服务A,服务C就需要向注册中心发起咨询服务请求，服务注

册中心就会将服务A的位置清单返回给服务C,如按上例服务A的情况，C便获得

了服务A的两个可用位置192.168.0.100：8000和192.168.0.101：8000。

当服务要发起调用的时候，便从该清单中以某种轮询策略取出一个位置来进行服

务调用，这就是后续我们将会介绍的客户端负载均衡。这里我们只是列举了一种简

单的服务治理逻辑，以方便理解服务治理框架的基本运行思路。实际的框架为了性

能等因素，不会采用每次都向服务注册中心获取服务的方式，并且不同的应用哦场景

在缓存和服务剔除等机制上也会有一些不同的实现策略。

将Spring Boot应用程序注册成为系统服务

将Spring Boot应用程序注册成为系统服务

在之前的文章中，我们提到了很多Spring Boot的技巧，那么当我们创建好了Spring Boot应用程序之后，怎么在生成环境中运行呢？如果只是以原始的java -jar 的方式来运行的话，不能保证程序的健壮性和稳定性，最好的办法是将程序注册成为服务来使用。

本文将会讲解如何将Spring Boot应用程序注册成为Linux和windows的服务。

首先我们需要将应用程序打包成为一个可执行的jar包，我们需要添加如下依赖：

这里的packaging我们需要选择jar。添加spring-boot-maven-plugin是为了将app打包成为可执行的jar包。

写好了应用程序，我们可以执行：

来打包应用程序，这里我们打包之后的jar包名字为：springboot-run-as-service-0.0.1-SNAPSHOT.jar。

在linux中，我们可以选择System V init script或者Systemd 配置文件，前者逐渐在被后者替代。

为了安全起见，我们需要创建一个运行用户，并给jar包赋予相应的权限：

创建一个文件链接到init.d目录，如下：

接下来我们就可以启动应用程序了：

service命令支持start, stop, restart 和 status。同时它还提供了如下的功能：

使用Systemd，我们需要在 /etc/systemd/system 创建一个your-app.service文件：

接下来我们可以使用systemctl start|stop|restart|status your-app来管理你的服务了。

Upstart是一个事件驱动的服务管理器，如果你使用Ubuntu，将会被默认安装。

我们来创建一个your-app.conf ：

在windows中，我们也有很多方式，如下：

Windows Service Wrapper 又叫 winsw是一个开源软件，winsw需要和一个配置文件your-app.xml配合使用：

Java Service Wrapper 提供了非常强大的配置，他可以让你的应用程序在windows和Linux下面使用。有兴趣的同学可以自行去学习。

更多教程请参考 flydean的博客

Spring Boot实现用户注册验证全过程

在这篇文章中，我们将使用Spring Boot实现一个基本的邮箱注册账户以及验证的过程。

我们的目标是添加一个完整的注册过程，允许用户注册，验证，并持久化用户数据。

首先，我们需要一个DTO来囊括用户的注册信息。这个对象应该包含我们在注册和验证过程中所需要的基本信息。

例2.1 UserDto的定义

请注意我们在DTO对象的字段上使用了标准的javax.validation注解——@NotBlank。

@NotEmpty: 适用于CharSequence, Collection, Map 和 Array 对象，不能是null并且相关对象的size大于0。

@NotBlank: 该注解只能作用于String类型。String非null且去除两端空白字符后的长度（trimmed length）大于0。

在下面的章节里，我们还将自定义注解来验证电子邮件地址的格式以及确认二次密码。

登录页面上的注册链接将用户带到注册页面：

例3.1 RegistrationController的定义

当RegistrationController收到请求/user/registration时，它创建了新的UserDto对象，将其绑定在Model上，并返回了注册页面registration.html。

接下来，让我们看看控制器在注册新账户时将执行的验证：

对于简单的检查，我们将使用@NotBlank来验证DTO对象。

为了触发验证过程，我们将在Controller中用@Valid注解来验证对象。

例4.1 registerUserAccount

下一步，让我们验证电子邮件地址，以保证它的格式是正确的。我们将为此建立一个自定义验证器，以及一个自定义验证注解--IsEmailValid。

下面是电子邮件验证注解IsEmailValid和自定义验证器EmailValidator:

例4.2.1 IsEmailVaild注解的定义

例4.2.2 EmailValidator的定义

现在让我们在我们的UserDto实现上使用新注解。

我们还需要一个自定义注解和验证器，以确保UserDto中的password和repeatedPassword字段相匹配。

例4.3.1 IsPasswordMatching注解的定义

请注意，@Target注解表明这是一个Type级别的注解。这是因为我们需要整个UserDto对象来执行验证。

例4.3.2 PasswordMatchingValidator的定义

现在，将@IsPasswordMatching注解应用到我们的UserDto对象。

我们要实现的第四个检查是验证该电子邮件帐户在数据库中是否已经存在。

这是在表单被验证后进行的，我们把这项验证放在了UserService。

例4.4.1 UserService

UserService依靠UserRepository类来检查数据库中是否已存在拥有相同邮箱的用户账户。当然在本文中我们不会涉及到UserRepository的实现。

然后我们继续实现RegistrationController中的持久化逻辑。

在上面的代码中我们可以发现：

1、我们创建了ModelAndView对象，该对象既可以保存数据也可以返回一个View。

2、在注册的过程中如果产生任何报错，将会返回到注册页面。

在本节内容中，我们将实现一个自定义的UserDetailsService，从持久层检查登录的凭证。

让我们从自定义UserDetailsService开始。

例6.1.1 MyUserDetailsService

然后，为了真正地能够开启自定义的MyUserDetailsService，我们还需要在SecurityConfig配置文件中加入以下代码：

限于篇幅，我们就不在这里详细展开SecurityConfig配置文件。至此我们完成了一个由Spring Boot实现的基本的用户注册过程。

以上内容为新媒号(sinv.com.cn)为大家提供！新媒号，坚持更新大家所需的互联网后端知识。希望您喜欢！