Проект: первый шаг, конфигурация JWT

Есть три класса алгоритмов: HS, RS, EC.

Два сценария:

1. Если создание токена и проверка токена происходят в одном проекте, можно использовать способ keystore. См. swak-test проект KeyStoreTest.

• Создание keystore файла: файл может быть размещён в classpath каталоге или файловой системе, при конфигурации указывается путь хранения.
• Правила загрузки keystore:
  • classpath конфигурация: непосредственно помещается в каталог src/main/resources, при упаковке будет включён в пакет. Затем в коде устанавливается имя keystore.
  • Файловая система: конфигурация вида file:path.

2. Если для создания токена и проверки токена требуются разные проекты, можно использовать алгоритмы RS и EC. См. swak-test проекты RsaTest.java, EcTest.java и RsaReadOnlyTest.java. Поддерживаются конфигурации с публичным и приватным ключами. Для создания токена требуется настроить публичный и приватный ключи. Для расшифровки токена нужен только публичный ключ.

Проект: введение

Springboot-vertx — это демонстрационный проект на основе SWAK, который демонстрирует следующие аспекты:

• Базовая структура запуска;
• Конфигурация API, например, AdminApi, AnnoApi, ParamApi и UserApi;
• Проверка прав доступа API;
• Передача параметров;
• Использование возвращаемых значений;
• Тестирование проекта с использованием наследования AppRunnerTest;
• Настройка сервиса UserServiceImpl.

Пользовательский запуск проекта

Все знакомы с четырьмя основными характеристиками springboot и автоматизированной конфигурацией. Автор также любит их, но не хочет использовать слишком много start.jar для включения компонентов. Поэтому автор сделал простую настройку spring.factories в swak.factories. Метод изменения также прост, подробности см. в swak-starter. Все знакомые компоненты находятся в com.swak.config и получены из запуска. AppConfiguration.java — конфигурация запуска на уровне проекта, AppRunner.java — точка входа для запуска, выполняет метод main. Выполняется аннотация com.swak.ApplicationBoot, которая импортирует конфигурацию запуска из swak.factories. Если это веб-среда (зависимость от jar имеет связанные классы vertx), то будет создан ReactiveServerApplicationContext, иначе будет создан AnnotationConfigApplicationContext. После создания ReactiveServerApplicationContext запускается ReactiveServer, и vertx начинает инициализацию. Vertx зависит от следующего: (swak-vertx) ReactiveServer → MainVerticle → ServiceVerticle (несколько) → HttpVerticle (один экземпляр). Это простое объяснение, которое будет дополнено позже.

Конфигурация API, обработка параметров, проверка прав доступа и обработка возвращаемых значений

Конфигурация осуществляется через аннотации, аналогично springmvc. Аннотации включают PageController, RestController, PostMapping и GetMapping. PageController и RestController не имеют больших различий, они просто указывают, что этот контроллер предназначен для отображения страниц. Наиболее важным классом в API является HandlerAdapter, который связывает api path с Router в vertx, вызывает метод api, обрабатывает параметры, обрабатывает возвращаемые значения и т. д.

Введение в простой реактивный HTTP-сервер

Что такое реактивность? Проще говоря, это обратный вызов, после завершения обработки IO вызывается зарегистрированный метод. Таким образом, потоку не нужно ждать завершения IO, чтобы продолжить выполнение последующего кода. Vertx называют java-версией node.js, многопоточной версией node.js. SWAK основан на vertx и имеет простую упаковку, позволяя нам использовать vertx так же, как springmvc. Реактивная разработка не сложна, сложно понять, какой код выполняется в каком потоке. Раньше, когда мы разрабатывали ssm-проекты, один запрос соответствовал одному потоку, от начала до конца, нам в основном не приходилось учитывать текущий поток, выполнять ли это долго. Я думаю, что самая большая особенность реактивной разработки заключается в том, что она может произвольно (просто пример) переключать потоки во время запроса и ответа. Например, в этом примере выполнение Controller происходит в потоке eventloop netty, а выполнение UserServiceImpl — в рабочем потоке vertx. Ниже приводится простое объяснение этого процесса выполнения. Ключевым моментом vertx является его внутренний Eventbus. Его можно представить как карту, где ключом является интерфейс, а значением — объект класса реализации. Когда Controller вызывает service, фактически отправляется сообщение в Eventbus, содержащее тип интерфейса service. Eventbus получает соответствующий объект класса реализации и выполняет его в соответствующем потоке, возвращая результат через Eventbus в виде сообщения.

Причины появления двух интерфейсов в проекте UserService и UserServiceAsync

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

Некоторые соображения по разработке реактивных систем

Раньше мы предпочитали разделять систему на три уровня при разработке ssm: Controller, service и dao. Сейчас всё так же. Разница в том, что Controller выполняется в потоке eventloop, а service и dao выполняются в рабочем потоке, как и раньше. Controller вызывает service асинхронно, отправляя сообщения. Код контроллера: @RestController(path = "/api/user", value = "userApi") public class UserApi {

@VertxReferer
private UserServiceAsync userService;

/**
 * Получить пользователя
 *
 * @param subject
 * @return
 */
@GetMapping("/get")
public CompletableFuture<Result> get(Subject subject) {
	return userService.get(subject.getIdAsLong()).thenApply(res -> Result.success(res));
}

}

Сервисный код, такой же, как и ранее, с использованием декларативных транзакций spring и т.д. @VertxService public class UserServiceImpl implements UserService {

@Override
public User get(Long id) {
	return new User().setId(id);
}

}

Java jdbc является синхронным выполнением, spring transaction зависит от текущего потока, поэтому не следует переключать поток в service. Другие io, такие как redis и http-клиент, используют асинхронные клиенты на основе netty.