springcloud微服务入门

news2024/11/14 19:23:19

1.架构的演变

目前我们接触的比较多的是单体架构，指的是将所有功能集中在一个项目中开发，打成一个包部署。

这样的架构优点在于，架构简单，把各个功能集中在一起方便操作管理，部署成本也比较低
但是缺点也是很明显，耦合度高！对于大型的互联网项目来说，功能庞杂，各个模块代码量巨大，这样的项目各个模块都集中在一起，极其不容易维护和修改

所以才有了分布式架构，所谓分布式架构指的是，将项目的每一个模块都分成一个个独立的项目，在这个模块就只干这个模块的事情，别的都不用管，这样分成的一个小项目就叫做服务。
优点是非常明显的，降低了服务的耦合度，有利于每一个模块的升级拓展。
但是也有缺点我们需要知道，如下图所示：

由于我的每一个模块之间都没有联系了，所以如果在用户功能中需要订单模块的程序，我们怎么来调用？放在单体架构里，我们直接可以调用订单模块的service层的接口，但是在分布式架构中怎么实现？
大型项目拆分的服务数量巨大，服务之间在互相调用的时候，怎么知道每个服务的地址？
当有服务挂掉的时候，别的服务怎么知道这个服务的健康状态，从而停止调用？

针对上面的这些问题，市场上应用比较多的分布式架构是微服务
微服务是一种经过良好架构设计的分布式架构方案，特征如下：

单一职责：微服务拆分力度更小，每一个服务都对应唯一的业务能力，避免重复开发
面型服务：刚刚在上面说到的，服务与服务之间怎么实现相互调用，每一个微服务对外暴露业务接口，从而满足服务之间的相互调用
自治：数据独立，每一个服务都有一个独立的数据库，以防某个服务出错导致整体数据被污染

微服务这种方案需要技术框架来落地，国内知名的便是springcloud和阿里巴巴的dubbo

2.微服务架构的基本模式

一个微服务项目，肯定得把项目中的许多模块都拆分出来，从而形成一个服务集群。
大型项目服务庞杂，维护起来极其不容易，所以得有一个注册中心来统一管理每一个服务的信息。
同样的每一个服务的配置也是由配置中心来统一管理的。
服务众多，需要有一个服务网关来统一管理每一个服务的地址，方便用户来调用。

3.服务拆分和远程调用

3.1.一个微服务的demo

这个demo中包含两个模块，用户模块user-service和订单模块order-service，之前说过一个项目中被拆分出来的服务，就是一个独立的项目，在代码中就是这样体现的。

3.2.远程调用的实现

假如现在order-serivce服务需要调用user-service服务，该怎么实现远程调用呢？上面不是说了在微服务中服务调用的时候可以对外暴露接口，从而完成服务之间的调用，在代码中怎么实现呢？

user-service对外的接口是localhost:8081/user/{id}，当我们用浏览器访问这个地址时就能拿到user数据库中的数据，而现在我们不是用浏览器来访问地址，而是用order-service来访问这个地址

那么order-service这个服务怎么来访问这个地址呢？spring给我们提供了一个RestTemplate类用来专门进行RestFul类型的API调用

3.2.1.创建RestTemplate类

在配置类中注册RestTemplate类的bean对象：

3.2.2.远程调用

在order-service服务中的service层中，注入RestTemplate对象，利用其提供的getForObject方法进行远程调用

3.2.3. 结果

4.Eureka

4.1.Eureka原理分析

之前在远程调用的时候，调用user-service服务的地址是采用硬编码的形式，但是等到服务一多，这样就会很麻烦，所以要用注册中心，将地址统一管理
刚刚在微服务架构的基本模式中提到的注册中心，该功能的实现就需要用到Eureka这项技术

以刚刚远程调用为例子，order-service服务要远程调用user-service服务，所以user-service是服务的提供者，order-service是服务的消费者
eureka分为两个角色，一个是eureka-server，用来管理服务信息，一个是eureka-client，用来表示服务的提供者和消费者
当服务提供者注册服务信息之后，该服务的相关信息就会被保存在eureka-server的注册中心里，这时，服务消费者就可以从注册中心里拉取服务提供者的信息，拉取到之后，通过负载均衡技术来选取要调用的端口。
其中，有一个心跳续约的机制，每隔30秒之后服务提供者会向注册中心发送一次信息，来确保注册中心中的服务都是存活的，若是有服务挂掉，也会通知注册中心及时删除。

4.2.搭建eureka服务

要想使用eureka，就得和拆分模块一样，在项目中单独创建一个eureka服务

引入依赖：

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        <version>3.1.2</version>
    </dependency>

创建启动类：

@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication {

    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class,args);
    }
}

这里的启动类得加一个eureka的开关注解，@EnableEurekaServer，表示开启了eureka服务

配置eureka：

server:
  port:
    10086

spring:
  application:
    name: eurekaServer  # eureka的服务名称

eureka:
  client:
    service-url:      # eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

注意：

这里需要明确一点，eureka自己也是一个微服务，也就是说eureka也会把自己注册到eureka-server的注册中心，这是为了eureka集群之间的通信，所以在配置信息的时候，得把eureka本身的地址信息也添上。

4.3.结果

启动项目之后，进入配好的地址，就会有eureka提供的可视化界面，如下：

4.4.eureka服务注册

上面创建好了eureka服务，接下来我们要把服务提供者和消费者注册到eureka服务中

引入依赖：

  <!--eureka客户端依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
            <version>3.1.2</version>
        </dependency>

配置信息：

在服务的配置文件中配置以下信息：

eureka:
  client:
    service-url:   # eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka


spring:
  application:
    name: userService   # 服务的名称

配置完成之后，刷新一下eureka的可视化界面，就能看见已经注册好的服务，如下：

4.5.eureka服务发现

刚刚在上面把服务的提供者和消费者全部注册到eureka服务中了，接下来来进行拉取，也就是完成服务消费者从eureka注册中心里拉取已经注册进去的服务提供者，也就是4.1图中的第二步

将服务消费者service层中的url中的ip和端口修改成要拉取的服务提供者的服务名称

未修改之前的url路径的端口是写死的，如果要拉取的服务一变多，那么这样硬编码的格式非常不好，所以我们把它改成更为灵活的服务名称，如下：

在服务消费者RestTemplate类上添加负载均衡注解

这样就完成的服务的拉取和负载均衡

5.负载均衡原理浅讲

由于小编对这一块也不是很了解，所以只做大概的讲解:

RestTemplate发起请求之后，会被LoadBalancerInterceptor拦截器拦截，然后经过对这个请求的处理，拿到请求路径中的服务名称userService，用这个服务名称去eureka的注册中心查找对应的服务，然后通过负载均衡拉取其中一个端口，如下图所示：