由于springSecurity后续课程需要微服务技术支持,所以暂停一下,先学习微服务,之后再将博客改造成微服务架构,之后再继续将springSecurity最后10节的内容学习完毕

初识微服务

随着互联网的发展,各类网站的发展速度也随着加快,单独的服务已经满足不了这种复杂的网络程序,服务的架构方式也从原来的单体架构逐渐的演变成了微服务的架构方式,下面就来了解一下这两种架构方式之间的区别

单体架构

将业务的所有功能集中在一个项目中开发,打成一个包部署。

image-20220729121953666

优点:架构简单,部署成本低

缺点:耦合度太高,维护困难

分布式架构

根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务。

image-20220729122113242

优点:

  • 降低服务耦合
  • 有利于服务升级和拓展

缺点:

  • 服务调用关系错综复杂

分布式架构虽然降低了服务耦合,但是服务拆分时也有很多问题需要思考:

  • 服务拆分的粒度如何界定?
  • 服务之间如何调用?
  • 服务的调用关系如何管理?

人们需要制定一套行之有效的标准来约束分布式架构。

微服务

微服务的架构特征:

  • 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责
  • 自治:团队独立、技术独立、数据独立,独立部署和交付
  • 面向服务:服务提供统一标准的接口,与语言和技术无关
  • 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题

image-20220729122212576

微服务的上述特性其实是在给分布式架构制定一个标准,进一步降低服务之间的耦合度,提供服务的独立性和灵活性。做到高内聚,低耦合。

因此,可以认为微服务是一种经过良好架构设计的分布式架构方案

但方案该怎么落地?选用什么样的技术栈?全球的互联网公司都在积极尝试自己的微服务落地方案。

其中在Java领域最引人注目的就是SpringCloud提供的方案了。

springboot为springcloud提供了一系列的自动装配方案,让微服务的实现方式更加的简单

服务的拆分原则

这里我总结了微服务拆分时的几个原则:

  • 不同微服务,不要重复开发相同业务
  • 微服务数据独立,不要访问其它微服务的数据库
  • 微服务可以将自己的业务暴露为接口,供其它微服务调用

image-20220729122432242

在idear中开发微服务,原则是按照模块进行划分,各模块之间,互相不影响,每一个模块都有自己独立的数据库,而且数据库之间不能互相访问,如果一个数据库需要使用另一个数据库的服务,就需要借助相关的api进行实现

微服务例子

image-20220729122813262

在一个工程里面创建两个不同的模块,每一个模块都代表着一个服务,都具备了单体应用的所有实现

image-20220729122931328

在service中启动这两个服务之后,访问相对应的api就能获得我们需要的数据,不同的微服务应该使用独立的端口,不然端口会冲突

image-20220729123141946

访问对应的api查询对应的数据库,就能返回对应的数据

image-20220729123241869

这里的user应该为null的,但是这里我调用了user 里面提供的接口,从另一个微服务里面获取到了user,这也就是下面要解释到的,怎么让各个微服务之间互相调用

  1. springcloud给我们提供了一个api,如果我们想要从一个微服务里面调用其他微服务的功能,我们就可以使用这个api

        @Bean
        public RestTemplate restTemplate(){
            return new RestTemplate();
        }
    

    向容器里面注入一个对象

  2. 在service里面调用对应的方法

    image-20220729123708249

​ 这样我们就可以将获取到的user对象封装到order中去

注意:该方法的使用者,必须是我服务的消费者,所谓的消费者就是使用者,而另一个则是微服务的提供者

image-20220729124003584

大家可以发现,这样写可以实现对应的功能,但是如果后期需要进行服务的修改,那就必须更改源代码,然后重新编译,这样对于大型项目来说是非常麻烦和耗时的,所以接下来出现的技术就是用来解决这个问题的

Eureka注册中心

image-20220729124319770

当然注册中心的功能不止这一个

image-20220729124413400

问题1:order-service如何得知user-service实例地址?

获取地址信息的流程如下:

  • user-service服务实例启动后,将自己的信息注册到eureka-server(Eureka服务端)。这个叫服务注册
  • eureka-server保存服务名称到服务实例地址列表的映射关系
  • order-service根据服务名称,拉取实例地址列表。这个叫服务发现或服务拉取

问题2:order-service如何从多个user-service实例中选择具体的实例?

  • order-service从实例列表中利用负载均衡算法选中一个实例地址
  • 向该实例地址发起远程调用

问题3:order-service如何得知某个user-service实例是否依然健康,是不是已经宕机?

  • user-service会每隔一段时间(默认30秒)向eureka-server发起请求,报告自己状态,称为心跳
  • 当超过一定时间没有发送心跳时,eureka-server会认为微服务实例故障,将该实例从服务列表中剔除
  • order-service拉取服务时,就能将故障实例排除了

注意:一个微服务,既可以是服务提供者,又可以是服务消费者,因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端

手动实现eureka

1.因为eureka本身也是一个微服务,所以我们需要另外创建一个模块,来管理这个微服务

2.创建完成之后需要引入对应的包

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

3.编写启动类

4.编写配置文件

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka

5.服务的端口,名称,地址,这些都是将来需要交给eureka管理的,也是前提

6.启动eureka

打开浏览器访问可以发现

image-20220729125105111

对应的服务和健康状况就已经显示出来了

那我们如何将另外的那两个微服务交给eureka去管理呢?

  1. 引入依赖(客户端的依赖)

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    
  2. 配置文件

    添加对应的服务名,和告诉我服务eureka在哪里

    spring:
      application:
        name: userservice
    eureka:
      client:
        service-url:
          defaultZone: http://127.0.0.1:10086/eureka
    

    所有微服务都是这样配置,配置完成之后,就可以将所有微服务交给eureka

    image-20220729125620940