Практика полной ссылки Spring Cloud Microservice Architecture

Прочитайте оглавление:

• 1. Процесс запроса шлюза
• 2. Управление услугами Эврика
• 3. Конфигурационный центр
• 4. Мониторинг Hystrix
• 5. Ссылка для вызова службы
• 6. Ссылка на журнал ELK
• 7. Возврат в едином формате

Выбор фреймворка микросервиса Java (Dubbo и Spring Cloud?)

В настоящее время все технические компоненты Spring Cloud, используемые компанией, в основном включают те, что показаны на рисунке выше.Я должен сказать, что вся экосистема Spring Cloud действительно мощная, а также очень удобна и эффективна в использовании.

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

1. Процесс запроса шлюза

Во всей библиотеке компонентов Spring Cloud Spring Cloud Zuul является наиболее легко упускаемым из виду, но также и самым важным. Spring Cloud Zuul можно интегрировать с реестром Eureka. В настоящее время мы используем Spring Cloud Zuul для работы следующим образом:

• фильтр фильтр
• маршрутизатор
• Балансировка нагрузки ленты
• Хайстрикс взорван
• Повторить попытку

Некоторые функции входят в состав Spring Cloud Zuul, например Filter и Router, а некоторые объединяются с другими компонентами Spring Cloud, такими как Ribbon и Hystrix.

Здесь мы сосредоточимся на фильтре «Фильтр», который разделен на четыре типа фильтров:

• pre: выполняется до того, как Zuul пересылает запрос, наша текущая реализацияAccessTokenFilter, используемый для проверки авторизации oAuth2.0 JWT.
• route: Выполняется во время маршрутизации Zuul, которая в настоящее время не используется в проекте.
• post: Zuul выполняется после маршрутизации и переадресации, то есть серверная служба была успешно запрошена.Наша текущая реализация:CustomResponseFilter, который используется для инкапсуляции унифицированного формата запроса, такого как код/сообщение/данные и т. д.
• error: вышеуказанный фильтр выполняется при возникновении ошибки, наша текущая реализацияCustomErrorFilter, который используется для перехвата ошибок, возникающих при выполнении фильтра, а затем их инкапсуляции и возврата в унифицированном формате. -окончание службы.

Кроме того, существует два способа реализации проверки авторизации oAuth2.0 JWT:

• Конфигурация авторизации находится в back-end службе (каждая служба должна быть настроена как Resource Server, и открытый ключ должен быть настроен, и авторизация интерфейса настроена в аннотации), Zuul выполняет только переадресацию, а не выполняет проверку авторизации.
• Конфигурация авторизации находится в Zuul, то есть Zuul используется в качестве сервера ресурсов, и серверную службу обрабатывать не нужно.Конкретная реализация в Zuul такова.AccessTokenFilter, внутренняя логика заключается в том, чтобы вручную проанализировать JWT, затем определить, является ли он правильным, и проанализировать информацию о пользователе/область/роль, а затем сопоставить конфигурацию в карте авторизации в соответствии с текущим API запроса, если совпадение неверно , сразу выдает ошибку авторизации 401 .

В настоящее время мы используем второй метод. Оба метода имеют свои преимущества и недостатки. Ключ заключается в нашем собственном выборе. Зачем использовать второй метод? Цель состоит в том, чтобы играть роль Zuul и выполнять унифицированную авторизацию и проверку внешних шлюзов.

Что касается карты авторизации, то в ней хранится конфигурация всех сервисных интерфейсов Пример конфигурации:

private static final Map ROUTE_MAPS;
static
{
    ROUTE_MAPS = new HashMap<String, String>();
    ROUTE_MAPS.put("eureka-client/home", "read:ROLE_ADMIN");
    ROUTE_MAPS.put("eureka-client/user", "read:ROLE_ADMIN");
    ROUTE_MAPS.put("eureka-client/error", "read:ROLE_ADMIN");
}скопировать код

Это наша текущая конфигурация, представляющая собой статическую карту, которая позже будет храниться в центре конфигурации Spring Cloud Config, загружаться при запуске Zuul и динамически обновляться с помощью Spring Cloud Bus.

На самом деле о вратах Зуула можно многое сказать, и у меня будет возможность объяснить это позже.

2. Управление услугами Эврика

Eureka следует принципу AP (доступность сервисов и отказоустойчивость разделов), который идеально подходит для управления сервисами в соответствии с распределенным принципом CAP.

Узлы в кластере Eureka равны между собой, в отличие от Consul, у которого есть разделение master/worker, узлы Eureka в кластере зарегистрированы друг с другом, поэтому в кластере Eureka лучше развернуть три узла, которые наш текущий метод развертывания.

Кроме того, механизм самозащиты Эврики, вы можете обратиться кэта статья.

Существует два способа использования нагрузки для взаимных вызовов между сервисами:

• Feign: На основе декларативного, как следует из названия, необходимо определить интерфейс, точно так же, как мы обычно используем вызовы объектов.
• Ribbon: Мягкая загрузка путем внедрения обработчика загрузки в RestTemplate, а затем выбора вызова через алгоритм загрузки (получение информации о регистрации службы через Eureka).

В настоящее время мы собираемся использовать метод загрузки ленты, почему? Просто посмотрите на код ниже:

restTemplate.getForObject("http://eureka-client/hello", String.class);скопировать код

3. Конфигурационный центр

В настоящее время мы используем Spring Cloud Config в центре конфигурации.Конечно, вы также можете использовать более мощный Polly (Ctrip с открытым исходным кодом), но Config также может удовлетворить наши потребности в настоящее время, и мы используем Git для хранилища.

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

Что касается сценариев использования центра конфигурации, мы в настоящее время находимся в основном в двух местах:

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

Кроме того, следует отметить, что по умолчанию, если конфигурация в Git обновлена, клиент конфигурации не будет обновлять конфигурацию.Наше текущее решение — использовать Spring Cloud Bus для динамического обновления конфигурации (настроенной на сервере конфигурации), конкретно обработать:

• Добавьте скрипты WebHooks в Git, напримерcurl -X POST http://manager1:8180/bus/refresh, который выполняется автоматически при обновлении конфигурации в репозитории Git.
• Настройте Spring Cloud Bus на сервере Config, примите запрос на обновление конфигурации от Git, а затем используйте RabbitMQ для широковещательной рассылки, чтобы уведомить всех подписчиков Config Client о необходимости обновить информацию о конфигурации.

4. Мониторинг Hystrix

Hystrix в основном используется для обработки сервисного фьюза/понижения/изоляции.Hystrix настраивается на вызывающем абоненте.Когда вызываемый сервис недоступен, срабатывает фьюз Hystrix, и указанный метод Fallback будет выполняться для специальной обработки.

Я думал, что условием срабатывания фьюза Hystrix является то, что служба недоступна, то есть истекает время ожидания запроса службы (например, служба зависает), но я проверил это сам, и служба имеет ошибку 500, которая будет также сработает предохранитель Hystrix, и Hystrix будет автоматически проигнорирован.

В настоящее время мы используем Hystrix, в основном, в двух местах:

• Внутренний сервисный звонок: Вы можете выполнять обработку фьюзов на интерфейсе API.
• Использование шлюза Zuul: То есть, когда Zuul маршрутизирует переадресацию звонков, но есть ограничение, то есть он может фьюзить только сервисы, а не фьюзить для интерфейса API.

На приведенном выше рисунке в основном изображен процесс мониторинга Hystrix.В настоящее время мы в основном используем RabbitMQ для сбора и передачи,turbo-сервер для агрегации потоков данных и hystrix-dashboard для графического отображения.

5. Ссылка для вызова службы

Концепция ссылки вызова службы заключается в записи данных всей ссылки запроса для запроса при инициации запроса службы.

В настоящее время теоретическая основа для реализации почти всех ссылок вызова сервисов на рынке основана на статье Google Dapper, наиболее важными понятиями являются traceId и spanId.

• traceId записывает идентификатор всей служебной ссылки, созданный первым запросчиком и уникальный в служебной ссылке.
• spanId записывает идентификатор текущего сервисного блока, созданного текущей сервисной стороной.
• parentId записывает spanId службы последнего запроса.

Ниже я описываю наш текущий процесс цепочки вызовов службы:

• H5 инициирует запрос к шлюзу Zuul, Zuul создает глобальный traceId и собственный spanId, а затем переносит данные в бизнес-сервис A, и передает их в RabbitMQ с помощью Spring Cloud Sluth.
• Бизнес-сервис A получает traceId и spanId, переданные Zuul, затем устанавливает для spanId Zuul значение parentId и генерирует свой собственный spanId, затем переносит данные в бизнес-сервис B и передает их RabbitMQ с помощью Spring Cloud Sluth.
• ....

На приведенном выше рисунке подробно описан процесс всей ссылки вызова службы, а вот используемый стек технологий:

• Spring Cloud Sluth: аналогично концепции зонда SkyWalking, каждая служба настраивается, собирает данные запроса (traceId и spanId) службы, а затем используетstream-sluthиbinder-rabbitКомпонент, который передает данные запроса в RabbitMQ.
• Spring Cloud Zipkin: он в основном используется для отображения в пользовательском интерфейсе ссылки запроса.Zipkin считывает данные запроса из RabbitMQ, затем сохраняет их в ElasticSearch, а затем считывает их непосредственно из ElasticSearch при следующем отображении.
• Kibana: Kibana также может отображать данные запроса в ElasticSearch, но это не графически и требует создания конфигурации индекса.

6. Ссылка на журнал ELK

ELK может ссылаться на несколько предыдущих статей:

• Конфигурация установки Elasticsearch и Kibana для архитектуры ELK
• Конфигурация установки Logstash и Filebeat для архитектуры ELK
• Конфигурация Logstash и Filebeat использует архитектуру ELK (фильтрация коллекций)
• Сводка конфигураций установки Elasticsearch, Kibana, Logstash и Filebeat для архитектуры ELK (версия 6.2.4)

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

7. Возврат в едином формате

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

Автор: Сверчки в пастырской
Публичный аккаунт WeChat:привет архитектура
Источник:www.cnblogs.com/xishuai/
Официальная учетная запись будет время от времени делиться всеми аспектами архитектуры, включая, помимо прочего: Microservices (микросервисы), Service Mesh (сервисная сетка), DDD/TDD, Spring Облако, Dubbo, Service Fabric, Linkerd, Envoy, Istio, Conduit, Kubernetes, Docker, MacOS/Linux, Java, .NET Core/ASP.NET Core, Redis, RabbitMQ, MongoDB, GitLab, CI/CD (непрерывная интеграция/непрерывная развертывание), DevOps и многое другое.
Авторские права на эту статью принадлежат автору и блог-саду.Перепечатка приветствуется, но это заявление должно быть сохранено без согласия автора, а ссылка на исходный текст дана в видном месте на странице статьи.
Поделиться с:QQ пространство Сина ВейбоТенсент Вейбо WeChat Более