Evolución de la arquitectura de microservicios

Evolución de la arquitectura de microservicios

Conozca los microservicios

Evolución de la arquitectura de servicios

Arquitectura monolítica: concentre todas las funciones comerciales en un proyecto de desarrollo e impleméntelas como un paquete.

ventaja:

• arquitectura sencilla
• Bajo costo de implementación

defecto:

• Alto grado de acoplamiento

Arquitectura distribuida: el sistema se divide según las funciones comerciales y cada módulo comercial se desarrolla como un proyecto independiente, llamado servicio.

ventaja:

• Reducir el acoplamiento de servicios
• Propicio para la mejora y expansión del servicio.

Preguntas a considerar:

• Granularidad dividida del servicio
• Cómo mantener la dirección del clúster de servicios
• Cómo implementar llamadas remotas entre servicios
• Cómo percibir el estado de salud del servicio

microservicios

• Responsabilidad única: la granularidad dividida del microservicio es menor y cada servicio corresponde a una capacidad comercial única, lo que puede lograr una responsabilidad única y evitar el desarrollo repetido.
• Orientado a servicios: los microservicios exponen las interfaces comerciales al mundo exterior.
• Autonomía: equipo independiente, tecnología independiente, datos independientes, implementación independiente
• Fuerte aislamiento: las llamadas de servicio están aisladas, son tolerantes a fallas, se degradan y se evitan problemas en cascada

Comparación de tecnología de microservicios

Necesidades del negocio

Nube de primavera

Sitio web oficial: https://spring.io/projects/spring-cloud

División de servicios y llamadas remotas

Notas sobre la división de servicios:

• No desarrolles el mismo negocio repetidamente para diferentes microservicios
• Los datos del microservicio son independientes, no acceda a la base de datos de otros microservicios.
• Los microservicios pueden exponer su negocio como interfaces para que otros microservicios llamen

Análisis de métodos de llamadas remotas:

Servicio de llamada remota

Usando la clase RestTemplate

Clase de inicio principal

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

servicio

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
    
    
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        Long userId = order.getUserId();
        String url = "http://userservice/user/"+userId;
        User user = restTemplate.getForObject(url, User.class);
        order.setUser(user);
        // 4.返回
        return order;
    }

proveedor y consumidor

• Proveedor de servicios: un servicio llamado por otros microservicios en una empresa.
• Consumidor de servicios: llame a otros servicios en una empresa

centro de registro eureka

Problemas con las llamadas de servicio.

• ¿Cómo obtienen los consumidores de servicios la información de dirección de los proveedores de servicios?

• • El proveedor de servicios registra su propia información con eureka cuando comienza
  • eureka guarda esta información
  • El consumidor extrae información del proveedor de eureka según el nombre del servicio.

• Si hay varios proveedores de servicios, ¿cómo deberían elegir los consumidores?

• • El consumidor del servicio utiliza el algoritmo de equilibrio de carga para seleccionar un servicio de la lista de servicios.

• Cómo conocen los consumidores el estado de salud de los proveedores de servicios

• • El proveedor de servicios enviará una solicitud de latido a EurekaServer cada 30 segundos para informar el estado de salud.
  • Eureka actualizará la información de la lista de servicios de registro y, si el latido es anormal, se eliminará.
  • Los consumidores pueden obtener la información más reciente.

El papel de Eureka

Los pasos para construir el servicio EurekaServer son los siguientes:

Introducir dependencias

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

Agregue la anotación @EnableEurekaServer

Agregar el archivo de configuración application.yml

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

Configurar el servicio Eureka

Introducir dependencias

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

Agregue la anotación @EnableEurekaServer

Agregar el archivo de configuración application.yml

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

Complete el servicio pull en order-service

1. Modifique el código de OrderService, modifique la ruta URL de acceso y reemplace la IP y el puerto con el nombre del servicio:

    public Order queryOrderById(Long orderId) {
    
    
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        Long userId = order.getUserId();
        String url = "http://userservice/user/"+userId;
        User user = restTemplate.getForObject(url, User.class);
        order.setUser(user);
        // 4.返回
        return order;
    }

2. Agregue anotaciones de equilibrio de carga a RestTemplate en la clase de inicio OrderApplication del proyecto de servicio de pedidos:

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

Principio de equilibrio de carga de la cinta

proceso

Código fuente

Estrategia de equilibrio de carga

Cambiar las reglas de equilibrio de carga

• Método de código: en la clase OrderApplication en order-service, defina una nueva IRule:

    @Bean
    public IRule randomRule(){
    
    
        return new RandomRule();
    }

• Método del archivo de configuración: en el archivo application.yml de order-service, agregar una nueva configuración también puede modificar las reglas:

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

Hambre cargada

Ribbon adopta la carga diferida de forma predeterminada, es decir, LoadBalanceClient se creará solo cuando se acceda por primera vez y el tiempo de solicitud será muy largo. La carga de hambre se creará cuando el proyecto comience para reducir el tiempo que lleva la primera visita. Habilite la carga de hambre a través de la siguiente configuración:

ribbon:
	eager-load:	
  	enabled: true # 开启饥饿加载
  	clients: userservice # 指定对userservice这个服务饥饿加载

centro de registro de nacos

Sitio web oficial: https://nacos.io/zh-cn/docs/v2/quickstart/quick-start.html

Registro de servicio a nacos.

confiar

En el proyecto principal (si se vuelve popular, primero impórtelo en dependencias para actualizar maven y luego impórtelo en dependencyManagement)

<dependencyManagement>
  <dependencies>
    <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>
  </dependencies>
</dependencyManagement>

subproyecto

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

aplicación.yml

spring:
  application:
    name: orderservice
  cloud:
    nacos:
      server-addr: localhost:8848

modelo de almacenamiento jerárquico del servicio nacos

Problema de llamadas de servicio entre clústeres

  cloud:
    nacos:
      server-addr: localhost:8848
    	# 集群配置
      discovery:
        cluster-name: HZ #集群名称

centro de control de nacos

Equilibrio de carga basado en clúster

1. Modifique application.yml en order-service y configure el clúster en HZ:

userservice:
  ribbon:
  	# 优先同区域再随机
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule

Equilibrio de carga basado en el peso.

En la implementación real, ocurrirá el siguiente escenario:

• Existen diferencias en el rendimiento de los dispositivos servidores. Algunas instancias están ubicadas en máquinas con mejor rendimiento, mientras que otras son deficientes. Esperamos que las máquinas con mejor rendimiento puedan atender más solicitudes de los usuarios.

Nacos proporciona una configuración de peso para garantizar un acceso frecuente: cuanto mayor sea el peso, mayor será la frecuencia de acceso.

Si ocurre un error 500, entonces:

Espacio de nombres de aislamiento del entorno

La capa más externa de almacenamiento de servicios y almacenamiento de datos en Nacos es algo llamado espacio de nombres, que se utiliza para el aislamiento más externo.

configuración

configuración yml

spring:
  cloud:
      nacos:
        server-addr: localhost:8848
        discovery:
          cluster-name: HZ
      	# 命名空间配置
          namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb

Análisis detallado del centro de registro de nacos.

Configurar una instancia no efímera

spring:
  cloud:
      nacos:
        server-addr: localhost:8848
        discovery:
          cluster-name: HZ
          namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb
          ephemeral: false

Lo que Nacos y eureka tienen en común

• Ambos admiten el registro de servicios y la extracción de servicios.
• Todos los métodos de latidos del corazón de los proveedores de servicios de soporte para pruebas de salud.

La diferencia entre Nacos y Eureka

• Nacos admite que el servidor detecte activamente el estado del proveedor: las instancias temporales usan el modo de latido y las instancias no temporales usan la detección activa.
• Se eliminarán las instancias temporales con latidos anormales, mientras que las instancias no temporales no se eliminarán.
• Nacos admite el modo de envío de mensajes para cambios en la lista de servicios y la lista de servicios se actualiza de manera oportuna

spring:
  cloud:
      nacos:
        server-addr: localhost:8848
        discovery:
          cluster-name: HZ
          namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb
          ephemeral: false

Lo que Nacos y eureka tienen en común

• Ambos admiten el registro de servicios y la extracción de servicios.
• Todos los métodos de latidos del corazón de los proveedores de servicios de soporte para pruebas de salud.

La diferencia entre Nacos y Eureka

• Nacos admite que el servidor detecte activamente el estado del proveedor: las instancias temporales usan el modo de latido y las instancias no temporales usan la detección activa.
• Se eliminarán las instancias temporales con latidos anormales, mientras que las instancias no temporales no se eliminarán.
• Nacos admite el modo de envío de mensajes para cambios en la lista de servicios y la lista de servicios se actualiza de manera oportuna
• El clúster de Nacos usa el modo AP de forma predeterminada. Cuando hay instancias no temporales en el clúster, se usa el modo CP; Eureka usa el modo AP.