вопросы на интервью springcloud алибаба

Каталог статей

Что такое Накос?

Продукт Alibaba с открытым исходным кодом представляет собой комплексное решение для обнаружения сервисов, управления конфигурацией и управления сервисами в микросервисной архитектуре.

(используется для реализации центра конфигурации и реестра служб)

Представляем функции Nacos

Обнаружение служб и мониторинг работоспособности служб (упрощает регистрацию служб и обнаружение других служб через интерфейсы DNS или HTTP, а также обеспечивает проверку работоспособности служб в режиме реального времени для предотвращения запросов к неработоспособным хостам или экземплярам службы).

Поддерживается обнаружение служб на основе DNS и RPC. После того как поставщик услуг зарегистрирует службу с помощью собственного SDK, OpenAPI или независимого агента TODO, потребитель службы может использовать DNS TODO или HTTP&API для поиска и обнаружения службы.
Nacos обеспечивает проверку работоспособности сервисов в режиме реального времени, предотвращая запросы к неработоспособным хостам или экземплярам сервисов. Nacos поддерживает проверки работоспособности транспортного уровня (PING или TCP) и прикладного уровня (например, HTTP, MySQL, определяемые пользователем). Для проверки работоспособности сервисов в сложных облачных средах и средах с топологией сети (таких как VPC, пограничные сети и т. д.) Nacos предлагает два режима проверки работоспособности: режим отчетов агента и активное обнаружение сервера. Nacos также предоставляет единую панель проверки работоспособности, которая поможет вам управлять доступностью услуг и трафиком в зависимости от состояния работоспособности.

Служба динамической настройки

Управляйте конфигурацией приложений и конфигурацией служб для всех сред централизованно, внешне и динамически.
Устраняет необходимость повторного развертывания приложений и служб при изменении конфигурации, что делает управление конфигурацией более эффективным и гибким.
Централизованное управление конфигурацией упрощает внедрение служб без сохранения состояния и упрощает гибкое масштабирование служб по запросу.
Предоставляет простой и удобный в использовании пользовательский интерфейс (демонстрационный образец консоли), помогающий управлять всеми конфигурациями служб и приложений.
Nacos также предоставляет ряд готовых функций управления конфигурацией, включая отслеживание версий конфигурации, канареечный выпуск, откат конфигурации одним щелчком мыши и отслеживание состояния обновления конфигурации клиента, что позволяет более безопасно управлять изменениями конфигурации в производственных средах и сокращать риск изменения конфигурации.

Служба динамического DNS

Служба динамической DNS поддерживает взвешенную маршрутизацию, что упрощает реализацию балансировки нагрузки среднего уровня, более гибких политик маршрутизации, управления трафиком и простых служб разрешения DNS для внутренней сети центра обработки данных. Динамические службы DNS также упрощают реализацию обнаружения служб на основе протокола DNS, устраняя риск привязки к API-интерфейсам обнаружения служб, принадлежащим поставщикам.
Nacos предоставляет несколько простых DNS API TODO, связанное доменное имя службы управления и список доступных IP:PORT.

Службы и управление их метаданными

Управление всеми службами и метаданными в центре обработки данных с точки зрения создания микросервисной платформы, включая управление описанием службы, жизненным циклом службы, анализом статической зависимости службы, состоянием службы, управлением трафиком службы, политиками маршрутизации и безопасности, а также соглашением об уровне обслуживания службы. статистика показателей.

обнаружение службы

В микросервисной архитектуре бизнес-процесс требует, чтобы несколько микросервисов выполняли бизнес-обработку через вызовы сетевого интерфейса.Потребитель услуг получает адрес поставщика услуг из реестра услуг для выполнения удаленных вызовов.Этот процесс называется обнаружением услуг.

Процесс обнаружения службы:
сам экземпляр службы не записывает сетевой адрес поставщика службы, и все экземпляры службы содержат клиентов обнаружения службы.

Когда каждая служба запускается, она сообщает о своем сетевом расположении в центр обнаружения служб. Внутри центра обнаружения служб будет сформирован реестр служб.Реестр служб является основной частью обнаружения служб и представляет собой базу данных, содержащую сетевые адреса всех экземпляров служб.

Клиент обнаружения служб периодически синхронизирует реестр служб из центра обнаружения служб и кэширует его на клиенте.

Когда службу необходимо запросить, экземпляр службы находит целевой сетевой адрес службы через реестр. Если для целевой службы имеется несколько сетевых адресов, используется алгоритм балансировки нагрузки для выбора одного экземпляра службы из нескольких экземпляров службы, а затем отправляется запрос.

Подводя итог, можно сказать, что в среде микросервисов, поскольку сетевой адрес работающего экземпляра службы постоянно меняется, а количество экземпляров службы меняется динамически, невозможно использовать фиксированный файл конфигурации для записи сетевого адреса поставщика службы. необходимо использовать динамическое обнаружение сервисов.Для достижения взаимной осведомленности между микросервисами используются механизмы. Каждый экземпляр службы будет сообщать о своем собственном сетевом адресе, так что центр обслуживания формирует полный реестр служб, и каждый экземпляр службы получает сетевой адрес целевой службы через центр обнаружения служб, тем самым реализуя механизм обнаружения служб.

Процесс реализации:

Поставщик услуг регистрируется в реестре услуг, а
потребитель услуг получает адрес услуги из реестра и
совершает удаленный вызов.

Сравнение продуктов обнаружения услуг

В настоящее время на рынке существует множество центров обнаружения сервисов: Nacos, Eureka, Consul и Zookeeper.

Сравните товары	Неф	Эврика	Консул	Работник зоопарка
Протокол соответствия	Поддержка моделей AP и CP	Модель точки доступа	СР модель	СР модель
медицинское обследование	TCP/HTTP/MYSQL/Клиент Бит	Клиентский ритм	TCP/HTTP/gRPC/Cmd	Сохранить жизнь
стратегия балансировки нагрузки	вес/метаданные/селектор	Лента	Фабио	-
Лавинная защита	Иметь	Иметь	никто	никто
Автоматический выход из экземпляра	поддерживать	поддерживать	не поддерживается	поддерживать
соглашение о доступе	HTTP/DNS	HTTP	HTTP/DNS	TCP
Поддержка мониторинга	поддерживать	поддерживать	поддерживать	поддерживать
Несколько центров обработки данных	поддерживать	поддерживать	поддерживать	не поддерживается
Синхронизация между реестрами	поддерживать	не поддерживается	поддерживать	не поддерживается
Интеграция с SpringCloud	поддерживать	поддерживать	поддерживать	не поддерживается
Интеграция с даббо	поддерживать	не поддерживается	не поддерживается	поддерживать
интеграция с k8s	поддерживать	не поддерживается	поддерживать	не поддерживается

Модель данных обнаружения служб

Дизайн изоляции пространства имен

Пространство имен используется для изоляции арендаторов.Одним из распространенных сценариев использования пространства имен является изоляция различных сред, например изоляция ресурсов (например, конфигураций и служб) между средами разработки и тестирования и производственными средами.

С точки зрения арендатора (пользователя), если существует несколько наборов разных сред, то в это время можно создать разные пространства имен в соответствии с указанной средой, чтобы добиться изоляции нескольких сред. Если есть три разные среды для разработки, тестирования и производства, то с помощью набора кластеров nacos можно построить следующие три разных пространства имен соответственно.

С точки зрения нескольких арендаторов (пользователей) у каждого арендатора (пользователя) может быть свое собственное пространство имен, а данные конфигурации и данные зарегистрированных служб каждого арендатора (пользователя) будут принадлежать его собственному пространству имен.Реализовать изоляцию данных между несколькими арендаторами.

управление пространством имен

Пространство имен используется для изоляции нескольких сред (например, разработки, тестирования, производства), и значение одной и той же конфигурации (например, источника данных базы данных) для каждого приложения в разных средах различно. Следовательно, мы должны планировать фактический процесс НИОКР и среду корпоративных проектов. Если у компании-разработчика программного обеспечения есть три среды для разработки, тестирования и производства, то мы должны установить три пространства имен для этих трех сред.

После установки всех пространств имен все страницы модулей управления конфигурацией и управления службами будут содержать кнопки вкладок для переключения пространств имен (окружений);

Уведомление:

Namesace является общедоступным, что является зарезервированным пространством nacos.Если вам нужно создать собственное пространство имен, не используйте то же имя, что и общедоступное, и назовите его именем с определенной семантикой в реальном бизнес-сценарии, чтобы не сделать трудно различить, какое пространство имен буквально.

При написании программы для получения набора конфигурации указанный параметр пространства имен должен быть заполнен идентификатором пространства имен, а не именем

модель данных

Модель данных, полученная Nacos после многолетнего производственного опыта в Alibaba, представляет собой трехуровневую модель сервис-кластер-экземпляр, которая в основном может соответствовать хранению данных и управлению сервисами во всех сценариях.

Сервис: программные функции, предоставляемые извне, с доступом к предопределенным интерфейсам через сеть.

Экземпляр: процесс с доступным сетевым адресом (IP:порт), который предоставляет одну или несколько служб.При запуске службы создается экземпляр службы.

Метаинформация: информация описания данных Nacos (например, конфигурация и служба), такая как версия службы, вес, стратегия аварийного восстановления, стратегия балансировки нагрузки, конфигурация аутентификации, различные настраиваемые метки (метка),

По сфере действия он делится на: метаинформацию об уровне обслуживания, метаинформацию кластера и метаинформацию экземпляра.

Кластер: набор экземпляров службы. Экземпляры службы образуют кластер по умолчанию. Кластер может быть дополнительно разделен в соответствии с требованиями. Единицей разделения может быть виртуальный кластер. Только экземпляры в одном кластере могут воспринимать друг друга.

С помощью конфигурации пространства имен, службы и кластера (ПО УМОЛЧАНИЮ) приложение описывает, в какой среде (например, среде разработки) служба регистрируется в каком кластере.
Пример:
Укажите идентификатор пространства имен: a1f8e863-3117-48c4-9dd3-e9ddc2af90a8 (обратите внимание на установку идентификатора пространства имен в соответствии с вашей собственной средой)
Укажите имя кластера: ПО УМОЛЧАНИЮ означает кластер по умолчанию, вы можете оставить это поле пустым

spring:
application:
name: transaction-service
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 #
Пространство имен адресов реестра: a1f8e863-3117-48c4-9dd3-e9ddc2af90a8 # Имя
кластера среды разработки: DEFAULT # Кластер по умолчанию, Не заполнять

Используйте Nacos в качестве центра конфигурации

Помимо реализации регистрации и обнаружения сервисов, Nacos также интегрирует функции центра конфигурации. Благодаря функции управления конфигурацией Nacos мы можем централизованно хранить все конфигурации всей архитектурной системы в Nacos. Преимущества этого также упоминаются во введении к Spring Cloud Config в предыдущих руководствах, в основном в следующих пунктах:

Раздельная конфигурация с несколькими средами обеспечивает более гибкие права управления и более высокий уровень безопасности.
Упаковка приложения более чистая, чтобы реализовать характеристики одного пакета и нескольких операций.
Настройте динамическое обновление (вы можете добавить аннотацию @RefreshScope к классу, который считывает конфигурацию для достижения динамического обновления)
и настройте откат (вы можете просмотреть записи модификации файла конфигурации в исторической версии, и вы можете выбрать соответствующую версию для отката ). ).
Управление конфигурацией Nacos, базовый уровень использует DataId и Group для поиска содержимого конфигурации, в дополнение к добавлению многих других функций управления.

Принцип реализации распределенного центра конфигурации

Локальное приложение читает файл облачного распределенного центра конфигурации (при первом чтении устанавливается постоянное соединение)
.После того, как локальное приложение читает файл конфигурации, и локальная jvm, и жесткий диск кэшируют копию.
Локально применяется к серверной части распределенного центра конфигурации для поддержания длительного соединения
при изменении нашего конфигурационного файла (судя по номеру версии | MID). Сообщите локальному приложению о результате изменения, чтобы вовремя обновить файл конфигурации.

Для управления конфигурацией Nacos набор конфигурации можно найти через пространство имен, группу и идентификатор данных.

Набор конфигурации (идентификатор данных):
в системе файл конфигурации обычно представляет собой набор конфигурации, а набор конфигурации может содержать различную информацию о конфигурации системы, например: набор конфигурации может содержать источники данных, пулы потоков, уровни журналов, и т.п. пункт конфигурации. Каждый набор конфигурации может определять значимое имя, которое является идентификатором набора конфигурации, то есть идентификатором данных.

Элемент конфигурации:

Содержимое конфигурации, содержащееся в наборе конфигурации, является элементом конфигурации. Он представляет собой конкретный настраиваемый параметр и его диапазон, обычно в виде ключ=значение. Поскольку мы обычно настраиваем уровень вывода журнала системы (logLevel=INFO|WARN|ERROR), это элемент конфигурации.

Группа конфигурации (группа): Группа
конфигурации — это группа наборов конфигурации, представленная значимой строкой (например, "Купить" или "Торговать"). Разные группы конфигурации могут иметь один и тот же набор конфигурации (идентификатор данных). При создании конфигурации на Nacos, если имя группы конфигурации не заполнено, по умолчанию имя группы конфигурации будет DEFAULT_GROUP. Общие сценарии группировки конфигурации: Может использоваться для различения различных проектов или приложений.Например, набор конфигурации системы управления студентами может определить группу как: STUDENT_GROUP.

Пространство имен (Namespace):
пространство имен можно использовать для изоляции конфигурации различных сред. Например, среда разработки, тестовая среда и производственная среда могут быть изолированы, поскольку их конфигурации могут различаться, или разные пользователи могут быть изолированы.Разные разработчики используют одни и те же nacos для управления своими собственными конфигурациями, которые могут быть изолированы пространством имен. Группы конфигурации или наборы конфигурации с одним и тем же именем могут существовать в разных пространствах имен.

Использование обычной практики:

Nacos абстрактно определяет концепции пространства имен, группы и идентификатора данных. То, что представляют эти концепции, зависит от того, что мы о них думаем, например:

Пространство имен: представляет различные среды, такие как среды разработки, тестирования и производства;

Группа: представляет проект;

DataId: часто в каждом проекте есть несколько проектов, и каждый набор конфигурации (DataId) является основным файлом конфигурации проекта.

SpringCloud LoadBalancer (далее SCL)

Исходное решение балансировки нагрузки SpringCloud на стороне клиента Ribbon было заброшено и заменено SpringCloud LoadBalancer.
Внутренние вызовы микросервисов в Spring Cloud по умолчанию являются HTTP-запросами, в основном через следующие три API:

RestTemplate: синхронный http API
WebClient: асинхронный реактивный HTTP API
Трехсторонняя инкапсуляция клиента, например openfeign,
если в проект добавлена зависимость spring-cloud-loadbalancer и конфигурация включена, функция балансировки нагрузки будет автоматически добавлена в соответствующий компонент.
Для RestTemplate Interceptor автоматически добавляется ко всем bean-компонентам RestTemplate с аннотацией @LoadBalanced для добавления функций балансировки нагрузки.
Для WebClient ReactorLoadBalancerExchangeFilterFunction создается автоматически, и мы можем добавить функцию балансировки нагрузки, добавив ReactorLoadBalancerExchangeFilterFunction.
Для сторонних клиентов нам вообще ничего дополнительно настраивать не нужно.

(весеннее облако 2020 г.) Встроенный циклический перебор, стратегия случайной балансировки нагрузки, стратегия циклического перебора по умолчанию.

Стратегии балансировки нагрузки на уровне службы можно указать с помощью аннотации LoadBalancerClient.

@LoadBalancerClient (значение = «демо-провайдер», конфигурация = 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);
	}
}

Пользовательская стратегия балансировки нагрузки

Как видно из вышеизложенного, стратегия балансировки нагрузки, поддерживаемая SCL, все же меньше, чем у Ribbon, и разработчикам необходимо реализовать ее самостоятельно.К счастью, SCL предоставляет удобный API для легкого расширения и использования. Вот демонстрация настройки стратегии балансировки нагрузки в градациях серого на основе метаданных реестра.

Определение политики балансировки нагрузки в оттенках серого

@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();
	}
}

Внедрить стратегию балансировки нагрузки в градациях серого
@LoadBalancerClient(value = «demo-provider», configuration = GrayRoundLoadbalancerConfig.class) для клиента

Оптимизация внедрения стратегии балансировки нагрузки
Как упоминалось выше, очень неудобно вручную внедрять все персонализированные стратегии нагрузки через LoadBalancerClient. Мы можем обратиться к логике пакетного внедрения LoadBalancerClients для создания собственного 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);
		}
	}
}