perguntas da entrevista do springcloud alibaba

O que é Nacos?

Um produto de código aberto do Alibaba, é uma solução abrangente para descoberta de serviços, gerenciamento de configuração e governança de serviços na arquitetura de microsserviços.

(usado para implementar o centro de configuração e registro de serviço)

Apresentando os recursos do Nacos

Descoberta de serviço e monitoramento de integridade de serviço (facilita o registro e descoberta de outros serviços por meio de interfaces DNS ou HTTP e também fornece verificações de integridade de serviços em tempo real para evitar solicitações a hosts ou instâncias de serviço não íntegras).

A descoberta de serviço baseada em DNS e baseada em RPC é suportada. Depois que o provedor de serviços registra o serviço usando SDK nativo, OpenAPI ou um agente TODO independente, o consumidor do serviço pode usar DNS TODO ou HTTP&API para localizar e descobrir o serviço.
A Nacos fornece verificações de integridade em tempo real nos serviços, evitando solicitações para hosts ou instâncias de serviço não íntegras. O Nacos suporta verificações de integridade da camada de transporte (PING ou TCP) e da camada de aplicação (como HTTP, MySQL, definida pelo usuário). Para a verificação de integridade de serviços em ambientes de nuvem complexos e ambientes de topologia de rede (como VPC, redes de borda etc.), o Nacos fornece dois modos de verificação de integridade: modo de relatório do agente e detecção ativa do servidor. A Nacos também fornece um painel de verificação de integridade unificado para ajudá-lo a gerenciar a disponibilidade e o tráfego do serviço com base no status de integridade.

Serviço de configuração dinâmica

Gerencie a configuração de aplicativos e a configuração de serviços para todos os ambientes de forma centralizada, externalizada e dinâmica.
Elimina a necessidade de reimplantar aplicativos e serviços quando a configuração muda, tornando o gerenciamento de configuração mais eficiente e ágil.
O gerenciamento centralizado da configuração facilita a implementação de serviços sem estado e facilita o dimensionamento elástico de serviços sob demanda.
Fornece uma interface do usuário simples e fácil de usar (amostra de demonstração do console) para ajudar a gerenciar todas as configurações de serviço e aplicativo.
A Nacos também fornece uma série de recursos de gerenciamento de configuração prontos para uso, incluindo rastreamento de versão de configuração, versão canary, configuração de reversão com um clique e rastreamento de status de atualização de configuração do cliente, que pode gerenciar com mais segurança as alterações de configuração em ambientes de produção e reduzir o risco de alterações de configuração.

Serviço de DNS dinâmico

O serviço DNS dinâmico oferece suporte a roteamento ponderado, o que facilita a implementação de balanceamento de carga de camada intermediária, políticas de roteamento mais flexíveis, controle de tráfego e serviços simples de resolução de DNS para a intranet do data center. Os serviços de DNS dinâmico também facilitam a implementação de descoberta de serviço baseada em protocolo DNS, eliminando o risco de acoplamento a APIs de descoberta de serviço proprietárias do fornecedor.
A Nacos disponibiliza algumas APIs DNS simples TODO, o nome de domínio associado ao serviço de gestão e a lista de IP:PORT disponíveis

Serviços e seu gerenciamento de metadados

Gerencie todos os serviços e metadados no data center da perspectiva da construção da plataforma de microsserviços, incluindo o gerenciamento da descrição do serviço, ciclo de vida, análise de dependência estática do serviço, status de integridade do serviço, gerenciamento de tráfego de serviço, políticas de roteamento e segurança e SLA de serviço E o mais importante estatísticas métricas.

descoberta de serviço

Na arquitetura de microsserviços, um processo de negócios requer vários microsserviços para concluir o processamento de negócios por meio de chamadas de interface de rede.O consumidor do serviço obtém o endereço do provedor de serviços do registro de serviço para fazer chamadas remotas. Esse processo é chamado de descoberta de serviço.

Processo de descoberta de serviço:
a própria instância de serviço não registra o endereço de rede do produtor de serviço e todas as instâncias de serviço contêm clientes de descoberta de serviço.

Quando cada serviço for iniciado, ele informará sua própria localização de rede ao centro de descoberta de serviços. Um registro de serviço será formado dentro do centro de descoberta de serviço.O registro de serviço é a parte central da descoberta de serviço e é um banco de dados contendo os endereços de rede de todas as instâncias de serviço.

O cliente de descoberta de serviço sincroniza periodicamente o registro de serviço do centro de descoberta de serviço e o armazena em cache no cliente.

Quando um serviço precisa ser solicitado, a instância de serviço localiza o endereço de rede do serviço de destino por meio do registro. Se houver vários endereços de rede para o serviço de destino, um algoritmo de balanceamento de carga será usado para selecionar uma instância de serviço de várias instâncias de serviço e, em seguida, uma solicitação será enviada.

Para resumir, em um ambiente de microsserviço, como o endereço de rede da instância em execução do serviço está mudando constantemente e o número de instâncias do serviço está mudando dinamicamente, é impossível usar um arquivo de configuração fixo para registrar o endereço de rede do provedor de serviços, e a descoberta dinâmica de serviços deve ser usada.Mecanismos são usados ​​para alcançar a conscientização mútua entre os microsserviços. Cada instância de serviço relatará seu próprio endereço de rede, de modo que o centro de serviço forme um registro de serviço completo e cada instância de serviço obterá o endereço de rede do serviço de destino por meio do centro de descoberta de serviço, realizando assim o mecanismo de descoberta de serviço.

Processo de implementação:

O provedor de serviço se cadastra no registro de serviço e o
consumidor de serviço obtém o endereço do serviço do registro e
faz uma chamada remota

Comparação de produtos de descoberta de serviços

Atualmente, existem muitos centros de descoberta de serviços no mercado: Nacos, Eureka, Consul e Zookeeper.

Comparar itens Nave Eureca Cônsul Funcionário do zoológico
Protocolo de conformidade Suporta modelos AP e CP Modelo AP modelo CP modelo CP
Exame de saúde TCP/HTTP/MYSQL/Client Beat Batida do cliente TCP/HTTP/gRPC/Cmd Mantenha vivo
estratégia de balanceamento de carga peso/metadados/seletor Fita Fábio -
Proteção contra avalanches Tenho Tenho Nenhum Nenhum
Sair automaticamente da instância Apoio, suporte Apoio, suporte não suporta Apoio, suporte
acordo de acesso HTTP/DNS HTTP HTTP/DNS TCP
Suporte de monitoramento Apoio, suporte Apoio, suporte Apoio, suporte Apoio, suporte
Vários centros de dados Apoio, suporte Apoio, suporte Apoio, suporte não suporta
Sincronizar entre registros Apoio, suporte não suporta Apoio, suporte não suporta
Integração SpringCloud Apoio, suporte Apoio, suporte Apoio, suporte não suporta
Integração Dubbo Apoio, suporte não suporta não suporta Apoio, suporte
integração k8s Apoio, suporte não suporta Apoio, suporte não suporta

Modelo de dados de descoberta de serviço

Design de isolamento de namespace

Namespace é usado para isolar a granularidade do locatário.Um dos cenários comuns de namespace é o isolamento de diferentes ambientes, como o isolamento de recursos (como configurações e serviços) entre ambientes de desenvolvimento e teste e ambientes de produção.

Da perspectiva de um locatário (usuário), se houver vários conjuntos de ambientes diferentes, nesse momento, namespce diferente poderá ser criado de acordo com o ambiente especificado para obter o isolamento de vários ambientes. Se houver três ambientes diferentes para desenvolvimento, teste e produção, o uso de um conjunto de clusters nacos pode criar os três namespaces diferentes a seguir, respectivamente.

Da perspectiva de vários inquilinos (usuários), cada inquilino (usuário) pode ter seu próprio namespace, e os dados de configuração e os dados de serviço registrados de cada inquilino (usuário) pertencerão ao seu próprio namespace. Implemente o isolamento de dados entre vários inquilinos.

gerenciamento de namespace

O namespace é usado para isolar vários ambientes (como desenvolvimento, teste, produção) e o valor da mesma configuração (como fonte de dados de banco de dados) para cada aplicativo em ambientes diferentes é diferente. Portanto, devemos planejar o processo real de P&D e o ambiente dos projetos corporativos. Se uma empresa de software tiver três ambientes para desenvolvimento, teste e produção, devemos estabelecer três namespaces para esses três ambientes.

Depois que todos os namespaces forem estabelecidos, todas as páginas sob os módulos de gerenciamento de configuração e gerenciamento de serviços conterão botões de guia para alternar namespaces (ambientes);

Perceber:

Namesace é public, que é um espaço reservado de nacos. Se você precisar criar seu próprio namespace, não use o mesmo nome que public, e nomeie-o com um nome com semântica específica em um cenário de negócios real, para não tornar é difícil distinguir qual namespace literalmente.

Ao escrever um programa para obter um conjunto de configurações, o parâmetro de namespace especificado deve ser preenchido com o ID do namespace, não com o nome

modelo de dados

O modelo de dados extraído pela Nacos após anos de experiência de produção no Alibaba é um modelo de três camadas de instância de cluster de serviço, que pode atender basicamente o armazenamento de dados e gerenciamento de serviços em todos os cenários.

Serviço: Funções de software fornecidas externamente, acessando interfaces predefinidas através da rede.

Instância: Um processo com um endereço de rede acessível (IP:Porta) que fornece um ou mais serviços. Quando um serviço é iniciado, uma instância de serviço é gerada.

Meta informações: informações de descrição de dados Nacos (como configuração e serviço), como versão do serviço, peso, estratégia de recuperação de desastres, estratégia de balanceamento de carga, configuração de autenticação, vários rótulos personalizados (rótulo),

Do escopo da ação, ela é dividida em: metainformações de nível de serviço, metainformações de cluster e metainformações de instância.

Cluster: Uma coleção de instâncias de serviço. As instâncias de serviço formam um cluster padrão. O cluster pode ser dividido de acordo com os requisitos. A unidade de divisão pode ser um cluster virtual. Somente instâncias do mesmo cluster podem perceber umas às outras.

Por meio da configuração de Namespace, Service, and Cluster (DEFAULT), o aplicativo descreve em qual ambiente (como o ambiente de desenvolvimento) o serviço se registra com qual cluster.
Exemplo:
Especifique o id do namespace: a1f8e863-3117-48c4-9dd3-e9ddc2af90a8 (preste atenção para definir o id do namespace de acordo com seu próprio ambiente)
Especifique o nome do cluster: DEFAULT significa o cluster padrão, você pode deixá-lo em branco

spring:
application:
name: transaction-service
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 #
Namespace de endereço do registro: a1f8e863-3117-48c4-9dd3-e9ddc2af90a8 #Development environment
cluster-name: DEFAULT #Default cluster , Não preencher

Use Nacos como centro de configuração

Além de realizar o registro e a descoberta de serviços, a Nacos também integra as funções do centro de configuração. Através da função de gerenciamento de configuração do Nacos, podemos armazenar centralmente todas as configurações em todo o sistema de arquitetura no Nacos. Os benefícios disso também são mencionados na introdução do Spring Cloud Config nos tutoriais anteriores, principalmente nos seguintes pontos:

A configuração separada de vários ambientes permite direitos de gerenciamento mais flexíveis e maior segurança.
A embalagem do aplicativo é mais pura, de modo a realizar as características de um pacote e várias operações.
Configure a atualização dinâmica (você pode adicionar a anotação @RefreshScope à classe que lê a configuração para obter a atualização dinâmica)
e configure a reversão (você pode visualizar os registros de modificação do arquivo de configuração na versão histórica e pode escolher a versão correspondente para reverter ).
Gerenciamento de configuração Nacos, o nível básico usa DataId e Group para localizar o conteúdo de configuração, além de adicionar muitas outras funções de gerenciamento.

Princípio de implementação do centro de configuração distribuído

O aplicativo local lê o arquivo do centro de configuração distribuído na nuvem (uma conexão persistente é estabelecida ao lê-lo pela primeira vez)
Após o aplicativo local ler o arquivo de configuração, tanto o jvm local quanto o disco rígido armazenarão uma cópia em cache.
Aplicado localmente ao lado do servidor do centro de configuração distribuído para manter uma conexão longa
quando nosso arquivo de configuração é alterado (avaliado pelo número da versão | MID). Notifique o aplicativo local sobre o resultado da mudança para atualizar o arquivo de configuração a tempo.

Para gerenciamento de configuração do Nacos, um conjunto de configuração pode ser localizado por meio de Namespace, grupo e ID de dados.

Conjunto de configuração (ID de dados):
No sistema, um arquivo de configuração geralmente é um conjunto de configuração e um conjunto de configuração pode conter várias informações de configuração do sistema, como: um conjunto de configuração pode conter fontes de dados, pools de threads, níveis de log, etc. item de configuração. Cada conjunto de configurações pode definir um nome significativo, que é o ID do conjunto de configurações, ou seja, o ID de dados.

Item de configuração:

O conteúdo de configuração contido no conjunto de configurações é o item de configuração. Ele representa um parâmetro configurável específico e seu intervalo, geralmente na forma de chave=valor. Como normalmente configuramos o nível de saída do log do sistema (logLevel=INFO|WARN|ERROR) é um item de configuração.

Grupo de configuração (Grupo): Um
grupo de configuração é um agrupamento de conjuntos de configuração, representado por uma string significativa (como Compra ou Negociação). Diferentes grupos de configuração podem ter o mesmo conjunto de configuração (ID de dados). Ao criar uma configuração no Nacos, se o nome do grupo de configuração não for preenchido, o nome do grupo de configuração será DEFAULT_GROUP por padrão. Cenários comuns de agrupamento de configuração: Pode ser usado para distinguir diferentes projetos ou aplicações.Por exemplo, o conjunto de configurações do sistema de gestão de alunos pode definir um grupo como: GRUPO_ESTUDANTE.

Namespace (Namespace):
O namespace pode ser usado para isolamento de configuração de diferentes ambientes. Por exemplo, o ambiente de desenvolvimento, ambiente de teste e ambiente de produção podem ser isolados porque suas configurações podem ser diferentes, ou usuários diferentes podem ser isolados.Diferentes desenvolvedores usam os mesmos nacos para gerenciar suas próprias configurações, que podem ser isoladas por namespace. Grupos de configuração ou conjuntos de configuração com o mesmo nome podem existir em namespaces diferentes.

Uso de prática comum:

Nacos define abstratamente os conceitos de Namespace, Group e Data ID. O que esses conceitos representam depende do que pensamos deles, como:

Namespace: representa diferentes ambientes, como ambientes de desenvolvimento, teste e produção;

Grupo: representa um projeto;

DataId: Muitas vezes há vários projetos em cada projeto, e cada conjunto de configuração (DataId) é o arquivo de configuração principal de um projeto

SpringCloud LoadBalancer (doravante referido como SCL)

A solução original de balanceamento de carga do lado do cliente do SpringCloud Ribbon foi abandonada e substituída pelo SpringCloud LoadBalancer.
As chamadas internas de microsserviço no Spring Cloud são solicitações HTTP por padrão, principalmente por meio das três APIs a seguir:

  1. RestTemplate: API http síncrona

  2. WebClient: API http reativa assíncrona

  3. Encapsulamento de cliente de três partes, como openfeign,
    se a dependência spring-cloud-loadbalancer for adicionada ao projeto e a configuração estiver habilitada, o recurso de balanceador de carga será adicionado automaticamente ao bean relevante.

  4. Para RestTemplate, o Interceptor é adicionado automaticamente a todos os beans RestTemplate anotados com @LoadBalanced para adicionar recursos de balanceador de carga.

  5. Para WebClient, ReactorLoadBalancerExchangeFilterFunction é criado automaticamente e podemos adicionar o recurso de balanceador de carga adicionando ReactorLoadBalancerExchangeFilterFunction.

  6. Para clientes de terceiros, geralmente não precisamos configurar nada adicionalmente.

(spring cloud 2020) Round robin integrado, estratégia de balanceamento de carga aleatório, estratégia round robin padrão.

As estratégias de balanceamento de carga de nível de serviço podem ser especificadas por meio da anotação LoadBalancerClient

@LoadBalancerClient(valor = “provedor de demonstração”, configuração = RandomLoadbalancerConfig.class)

public class RandomLoadbalancerConfig {
	@Bean
	public ReactorLoadBalancer<ServiceInstance> reactorServiceInstanceLoadBalancer(Environment environment,
			LoadBalancerClientFactory loadBalancerClientFactory) {
		String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
		return new RandomLoadBalancer(
				loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
	}
}

Estratégia de balanceamento de carga personalizada

Como pode ser visto acima, a estratégia de balanceamento de carga suportada pelo SCL ainda é menor que a do Ribbon, e os próprios desenvolvedores precisam implementá-la.Felizmente, o SCL fornece uma API conveniente para fácil expansão e uso. Aqui está uma demonstração da personalização de uma estratégia de balanceamento de carga em escala de cinza com base nos metadados do registro.

Definir política de balanceamento de carga em escala de cinza

@Slf4j
public class GrayRoundRobinLoadBalancer extends RoundRobinLoadBalancer {

	private ObjectProvider<ServiceInstanceListSupplier> serviceInstanceListSupplierProvider;

	private String serviceId;

	@Override
	public Mono<Response<ServiceInstance>> choose(Request request) {
		ServiceInstanceListSupplier supplier = serviceInstanceListSupplierProvider
				.getIfAvailable(NoopServiceInstanceListSupplier::new);
		return supplier.get(request).next().map(serviceInstances -> getInstanceResponse(serviceInstances, request));
	}

	Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances, Request request) {

		// 注册中心无可用实例 抛出异常
		if (CollUtil.isEmpty(instances)) {
			log.warn("No instance available {}", serviceId);
			return new EmptyResponse();
		}

		DefaultRequestContext requestContext = (DefaultRequestContext) request.getContext();
		RequestData clientRequest = (RequestData) requestContext.getClientRequest();
		HttpHeaders headers = clientRequest.getHeaders();

		String reqVersion = headers.getFirst(CommonConstants.VERSION);
		if (StrUtil.isBlank(reqVersion)) {
			return super.choose(request).block();
		}

		// 遍历可以实例元数据,若匹配则返回此实例
		for (ServiceInstance instance : instances) {
			NacosServiceInstance nacosInstance = (NacosServiceInstance) instance;
			Map<String, String> metadata = nacosInstance.getMetadata();
			String targetVersion = MapUtil.getStr(metadata, CommonConstants.VERSION);
			if (reqVersion.equalsIgnoreCase(targetVersion)) {
				log.debug("gray requst match success :{} {}", reqVersion, nacosInstance);
				return new DefaultResponse(nacosInstance);
			}
		}
		// 降级策略,使用轮询策略
		return super.choose(request).block();
	}
}

Injete a estratégia de balanceamento de carga em escala de cinza
@LoadBalancerClient(value = “demo-provider”, configuration = GrayRoundLoadbalancerConfig.class) para o cliente

Otimizando a injeção de estratégia de balanceamento de carga
Conforme mencionado acima, é muito inconveniente injetar manualmente todas as estratégias de carga personalizadas por meio do LoadBalancerClient. Podemos nos referir à lógica de injeção em lote de LoadBalancerClients para construir nosso próprio BeanRegistrar

public class GrayLoadBalancerClientConfigurationRegistrar implements ImportBeanDefinitionRegistrar {

	@Override
	public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) {
		Field[] fields = ReflectUtil.getFields(ServiceNameConstants.class);

		// 遍历服务名称,注入支持灰度策略的负载均衡器
		for (Field field : fields) {
			Object fieldValue = ReflectUtil.getFieldValue(ServiceNameConstants.class, field);
			registerClientConfiguration(registry, fieldValue, GrayLoadBalancerClientConfiguration.class);
		}
	}
}

Acho que você gosta

Origin blog.csdn.net/liuerchong/article/details/123926745
Recomendado
Clasificación