spring-cloud day01-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_73967798/article/details/132831220

微服务的架构特征

- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责

- 自治：团队独立、技术独立、数据独立，独立部署和交付

- 面向服务：服务提供统一标准的接口，与语言和技术无关

- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

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

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

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

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

单体架构&分布式架构

- 单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统

- 分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝

- 微服务：一种良好的分布式架构方案

①优点：拆分粒度更小、服务更独立、耦合度更低

②缺点：架构非常复杂，运维、监控、部署难度提高

- SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件

服务拆分原则

- 不同微服务，不要重复开发相同业务

- 微服务数据独立，不要访问其它微服务的数据库

- 微服务可以将自己的业务暴露为接口，供其它微服务调用

案例1-cloud-demo

cloud-demo：父工程，管理依赖

- order-service：订单微服务，负责订单相关业务

- user-service：用户微服务，负责用户相关业务

要求：

- 订单微服务和用户微服务都必须有各自的数据库，相互独立

- 订单服务和用户服务都对外暴露Restful的接口

- 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库

导入后查询user和order数据

案例需求

修改order-service中的根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。

案例实现

我们需要在order-service中向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口。

大概的步骤是这样的：

- 注册一个RestTemplate的实例到Spring容器

- 修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User

- 将查询的User填充到Order对象，一起返回

首先需要在order的启动项中定义RestTemplate，

在service中发起http请求，并把数据封装在user成员变量中

同时启动user和order的启动项，发送查询

提供者与消费者

**服务提供者**：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）

**服务消费者**：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

但是，服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。

如果服务A调用了服务B，而服务B又调用了服务C，服务B的角色是什么？

- 对于A调用B的业务而言：A是服务消费者，B是服务提供者

- 对于B调用C的业务而言：B是服务消费者，C是服务提供者

因此，服务B既可以是服务提供者，也可以是服务消费者。

Eureka

提出问题

- order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？

- 有多个user-service实例地址，order-service调用时该如何选择？

- order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

回答问题

问题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

搭建eureka-server

1. 1. 在cloud-demo父工程下，创建一个子模块：

1.2. 在其pom文件中引入依赖

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

1.3. 编写启动类

package cn.itcast.eureka;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
//一定要添加一个@EnableEurekaServer注解，开启eureka的注册中心功能：
@EnableEurekaServer  
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class, args);
    }
}

1.4. 在resource中创建 application.yml文件

server:
  port: 10086 # 服务端口
spring:
  application:
    name: eureka-server #eureka 的服务名称
eureka:
  client:
    service-url: #eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

1.5. 启动服务

eureka服务注册

2.1. 在user-service的pom文件中引入依赖

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

2.2. 配置user和order中的yaml文件

spring:
  application:  #顶格写
    name: orderservice #根据插入的项目改名
eureka:  #顶格写
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

2.3.增加实例列表

凡是加依赖和配置地址就是服务的注册

eureka服务拉取

3.1. 修改orderservice的代码，修改访问路径，用服务名代替ip，端口

3.2. 在order-service项目中的启动类orderapplication中的resttemplate添加负载均衡器

String url = "http://user-server/user/"+order.getUserId();

//user-server为user中yml的配置端口名

Ribbon负载均衡

负载均衡原理

源码跟踪

基本流程如下：

- 拦截我们的RestTemplate请求http://userservice/user/1

- RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service

- DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表

- eureka返回列表，localhost:8081、localhost:8082

- IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081

- RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求

负载均衡策略

自定义负载均衡策略（两种方式）

1. 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：（全局配置）

2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：（一个微服务）

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

Nacos

Nacos的依赖

提前在nacos的bin目录下打开cmd---执行 startup.cmd -m standalone 语句

1. 在父工程中加入nacos依赖

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.5.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

在子工程中替换eureka

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2. 在user和order中更改yml中的配置

注销eureka，增加nacos配置

在nacos中查看user和order

服务分级存储模型

一个**服务**可以有多个**实例**，例如我们的user-service

Nacos就将同一机房内的实例划分为一个**集群**

微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。

给user-service配置集群

1. 在user中的yml中加入配置

2.重启user，重启后在更改yml，nacos显示

同集群优先的负载均衡

1. 首先在order的yml中加入HZ集群

2. 在order中yml添加语句

user-service:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

权重配置

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。

因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。

权重配置在0---1之间配置

**注意**：如果权重修改为0，则该实例永远不会被访问

环境隔离

- nacos中可以有多个namespace

- namespace下可以有group、service等

- 不同namespace之间相互隔离，例如不同namespace的服务互相不可见

1. 在nacos中创建命名空间

2. 在yml中添加语句，命名空间的id

不同的namespace不可见

然后再启动user发现无法运行，因为order已经跟user不在一个环境空间了，实现环境隔离！

Nacos与Eureka的区别

Nacos的服务实例分为两种l类型：

- 临时实例（默认）：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。（心跳检测）

- 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

```yaml
spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

- Nacos与eureka的共同点

- 都支持服务注册和服务拉取

- 都支持服务提供者心跳方式做健康检测

- Nacos与Eureka的区别

- Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式

- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除

- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式