Разработка с Дарьей Матвеевой

Тестирование под различными профилями Spring

Подготовила очередной сервис для перехода на Spring Boot 3.
Тесты прошли успешно, локально сервис запускался успешно. Уже собиралась выкладывать правки на ревью.
Но просматривая файлы для коммита, вспомнила, что на тестовом стенде надо отключить Swagger, и решила проверить, что он действительно не доступен при работе под профилем test. И вот запускаю приложение - а оно не стартует. Нет спрингового бина, который требуется в кастомизированном OpenApiWebMvcResource. При чтении документации выяснилось, что нужный бин не создается при отключении свойства springdoc.api-docs.
Для фикса оказалось достаточно добавить к ресурсу аннотацию @ConditionalOnBean(SpringDocConfiguration.class), чтобы он вообще не создавался при отключенном Swagger.
Но из этой ошибки вынесла для себя важность тестирования приложения под всеми объявленными профилями. Ведь если бы не проверила этот момент локально, то баг выявился бы лишь на тестовом стенде, что потребовало бы отдельного фикса, пересборки дистрибутива, повторного развертывания, а также затронуло бы команду тестирования. А сейчас фикс получился быстрым и безболезненным. Поэтому в список необходимых проверок перед созданием MR для себя добавила также тестирование приложения под разными профилями.

Во время перевода одного из приложений на Spring Boot 3 возникла ошибка - оказалось, что в приложении добавлены в качестве зависимостей два spring boot стартера, которые содержали конфигурационные бины с одинаковыми именами.
После исправления названия одного из бинов возникла другая ошибка — Spring не мог определить, какой из бинов одинакового типа использовать. В приложении нужен был бин из стартера №1. Возможные решения:
1. Пометить бин из стартера №1 как @Primary. Тогда использоваться будет именно он.
2. Пометить бин из стартера №2 аннотацией @ConditionalOnMissingBean, чтобы он создавался только в случае, не существует первого, т.е. если не подключен первый стартер (для сервисов, которые используют только второй стартер).
3. В моем случае, оказалось возможным провести рефакторинг стартеров, и первый стартер был подключен во второй в качестве зависимости, а бин из второго стартера соответственно был удален.

#рабочее

Сейчас на рабочем проекте провожу миграцию сервисов со Spring Boot 2 на Spring Boot 3. Вот некоторые шаги этого процесса:

➖ Для начала подключить зависимость spring-boot-properties-migrator, которая позволяет анализировать файлы конфигурации (application.yml) в рантайме, и автоматически определяет устаревшие или переименованные свойства.

➖ Перейти на Java 17 с 11, т.к Spring Boot 3 не поддерживает более ранние версии.

➖ Перевести Swagger со Springfox на Springdoc. Обе эти библиотеки служат для интеграции Swagger со Spring Boot. Но Springfox уже не развивается (последний коммит в репозитории был в 2021), не совместима со Spring Boot 3 и не поддерживает OpenAPI 3.

➖ Часть диалектов hibernate устарели, т.к. в Hibernate 6 появился механизм автоматического определения диалекта на основе используемой базы данных. Поэтому больше нет нужды использовать диалекты, специфичные для конкретной версии БД, например PostgreSQL10Dialect.

➖ Поправить конфигурации стартеров. В Spring Boot 3 автоконфигурации рекомендуется объявлять в файле META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports, а не в spring.factories..

➖ Перейти на Spring Security 6. Требуется обновление кода, т.к. методы для конфигурации авторизации и аутентификации значительно изменились.

#рабочее

Pet-проект

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

▫️ Привела API в соответствие с принципами REST. Было не совсем понятно, для чего нужен тот или иной эндпойнт, из-за не очень логичного разделения методов по контроллерам. Много лишних path variables переделала в request parameters. Итоговый вариант оказался чище и понятней.

▫️ Доработала UI. Добавила datepicker-s и datetimepicker-s там, где раньше был просто текстовый ввод дат. Привела формы и таблицы во всем проекте к единому формату, а также поправила поля в формах, чтобы выглядели одинаково.

▫️ Переделала генерацию ключей для entity. Ранее использовался один генератор для всех сущностей, поэтому при ручном обновлении БД через скрипты приходилось внимательно следить, чтобы не перепутать id сущностей разных типов, иначе возникали ошибки.

▫️ Заметила, что при старте контейнера с базой данных скрипты инициализации отрабатывают довольно медленно. Оказалось, что изначально сгенерированные тестовые данные выгрузила из БД отдельными insert для каждой строки. После объединения строк инициализация пошла гораздо быстрее.

▫️ Провела также рефакторинг классов и методов, которые показались теперь излишне запутанными.

В планах — поднять зависимости до самых новых версий и отрефакторить deprecated код, появившийся за это время.

В системе, которую разрабатывает наша команда, у пользователей есть функция добавления описания различным продуктам. Появилась необходимость проанализировать, насколько осмысленно заполняются эти описания. Для этого нужно было проверить соответствующую колонку из БД Postgresql на то, являются ли ее значения комбинацией определенных строк, не несущих смысла, таких как 'описание', 'данные', 'продукт', всяких специальных символов и т.п.
Решение в лоб - просто сделать цепочку replace, заменяя каждое встреченное слово-заменитель на пустую строку, и проверить, превратилась ли все описание в пустую строку:

select id, description, replace(replace(replace....replace(description, 'описание', '')...'') ...'') = '' has_no_meaning
from product p

Но учитывая, что таких слов для проверки было более 100, это было бы весьма тяжело читать и поддерживать. Да и сам запрос немаленький, в нем рассчитываются и другие параметры.
Намного удобнее сделать проверку с использованием регулярного выражения:

select id, description, regexp_replace(description, '(описание|продукт|...|данные|-|,|\.)' , '', 'gi')) = '' has_no_meaning
from product p

Regexp_replace заменяет любое из слов, перечисленных в круглых скобках через черту, на пустую строку. Параметр g указывает на то, что заменяем все совпадения, а нет только первое встреченное, i - что игнорируем верхний/нижний регистр.
Еще удобнее не перечислять слова в теле запроса, а поместить их в отдельную таблицу. Так в будущем будет легко добавлять новые.

create table t_descr_substitute (
  substitute varchar(2000)
);
insert into t_descr_substitute (substitute)  values ('описание'); ...

Тогда запрос будет таким:

select  id, description, regexp_replace(description, a.pattern, '', 'gi') = '' has_no_meaning
from product p
join  ( select '(' + string_agg(substitute, '|') + ')' pattern from t_descr_substitute ) a on 1=1

Здесь с помощью string_agg собираем строку-паттерн для регулярного выражения и затем используем ее в функции regexp_replace.

В какой-то момент во время экспериментов показалось, что регулярные выражения не работают для этой задачи, т.к. на любое описание проверка возвращала true, как будто все описания состоят из заменителей. Оказалось, что проблема в точке. В regex выражении она означает любой символ, соответственно все описания подходили под шаблон. Стоило записать ее с обратной чертой \. и все заработало как надо.

#рабочее

HikariCP и Postgresql

Чтобы выполнить запрос в базе данных, сервер приложений должен установить с ней соединение. Это может быть затратно, т.к. надо открыть соединение через драйвер, открыть TCP-сокет, выполнить запрос, закрыть сокет, закрыть соединение. Таких подключений может быть сотни и тысячи, из-за чего лимит оперативной памяти может быстро исчерпаться.
Поэтому при обращении к БД клиенты (сервера приложений) используют пулы соединений. В случае, если в пуле есть свободное соединение, оно берется из пула. Если пул исчерпан, то запросы встают в очередь и ждут свободного соединения.

У нас на проекте в качестве сonnection pooler используется HikariCP. С базой данных Oracle приложение работало без проблем, но после перехода на Postgresql БД начала падать по непонятной причине. Оказалось, что hikari заполняет пул сразу максимальным количеством соединений, а не создает их постепенно. Поэтому все сервисы резервировали максимум соединений, и БД не выдерживала. Postgresql каждое соединение обрабатывает как отдельный процесс, а Oracle - как поток внутри общего процесса. В результате Oracle лучше держит большее число соединений.
Проблема решилась установлением корректных настроек HikariCP.

#рабочее

Появилась задача - оптимизировать сложный аналитический sql-запрос.

Первый возникший вопрос - как измерять эффективность оптимизации. Ведь при повторном выполнении запроса данные кэшируются, и запрос может выполняться на порядки быстрее, чем в первый раз. Существуют хаки для очистки кэшей - остановить Postgresql, очистить кэш ОС. Но это применимо только для локальной БД. В условиях кластера это может не сработать, да и прав на такие действия может не быть.
Остается только ориентироваться на план запроса. Основная цель - на каждом этапе минимизировать количество обрабатываемых строк. В моем случае запрос представлял собой соединение основной таблицы со многими другими, фильтрация по определенным атрибутам, а затем группировка по сущностям из основной таблицы.

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

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

2. Тут оказалось, что количество таблиц, соединяемых в основном подзапросе, оказалось больше 10. В Postgresql после определенного количества соединяемых таблиц (по умолчанию 8) оптимизатор перестает искать оптимальный план и просто обрабатывает их в порядке объявления. А таблица с наиболее селективным фильтром оказалась в конце списка таблиц, поэтому в плане сначала не было заметно никакого улучшения. Но, при перемещении этой таблицы наверх списка, селективный фильтр сработал первым и дал значительное ограничение промежуточных результатов.

3. После группировки еще раз присоединила основную таблицу, чтобы выбрать из нее атрибуты, необходимые в отчете. Так ушла необходимость "протаскивать" их наверх из основного подзапроса, и проводить по ним лишнюю группировку.

Также надо иметь в виду, что оптимизатор Postgresql строит план на основе статистики - количества строк в таблицах, селективности атрибутов, по которым идет фильтрация и т.д.. Поэтому оптимизация, проведенная на dev-стенде, может быть неактуальной для промышленных данных, и ее надо обязательно протестировать на prod-стенде.

#рабочее

Прошла обучение для того, чтобы проводить технические собеседования по Java в компанию.
Провела тестовое интервью с кандидатом под наблюдением опытного интервьюера.
Также пообщалась с другими коллегами, кто имеет большой опыт проведения собеседований.
Записала советы, как проводить интервью эффективно:

▫️ Хотя и есть стандартные вопросы, которые необходимо задать, надо в первую очередь отталкиваться от уровня кандидата. Если человек на вопрос отвечает поверхностно, спросить о нюансах использования, о деталях реализации и т.д.

▫️ Если человек не может сформулировать ответ на вопрос, но при этом у него в резюме указан большой опыт в данной области, то стоит переформулировать тот же запрос, но с точки зрения практики. Например, если кандидат не может сказать формальное определение RESTful-вебсервиса, но при этом у него опыт разработки 10+ лет, то понятно, что он их разрабатывал и понимает, что это.

▫️ Если человек не понимает вопрос, нужно переформулировать на конкретном примере.

▫️ Если человек ответил неправильно или неполно, можно явно подсказать, что хочется услышать в ответе. Тот, кто разбирается в теме, сразу поймет о чем речь, и дополнит ответ.

▫️ Важно узнать, что человек понимает сложность используемых алгоритмов/структур данных.

Возникла проблема при старте сервиса - долго не отвечают heathchecks сервиса в openshift.
Для данного сервиса healthchecks в Openshift проверяли liveness и readiness эндпойнты актуатора в Spring boot, и проблема оказалась в readiness probe.
Выяснилось, что при старте сервиса запускается продолжительный по времени метод формирования отчета, который сохраняется в БД в ожидании, когда его считает другой сервис.
Возник вопрос, насколько актуальна readiness probe для сервиса, который не принимает входящих запросов и лишь формирует отчет? Однако оказалось, что отключить ее нет возможности.
Поэтому следующим шагом стал разбор того, что происходит при старте.
Метод формирования отчета запускался с помощью аннотации:

@EventListener(AppricationReadyEvent.class)
public void generate() {
  //логика создания отчета
}

В документации к классу AppricationReadyEvent сказано:

Event published as late as conceivably possible to indicate that the application is ready to service requests.

В документации к классу ReadinessState:

"Readiness" state of the application.
An application is considered ready when it's live and willing to accept traffic. "Readiness" failure means that the application is not able to accept traffic and that the infrastructure should stop routing requests to it.

Выглядит логично, что AppricationReadyEvent должен быть опубликован после того, как readiness probe станет UP.
Посмотрим, когда выставляет статус UP.

В методе SpingApplication.run(...), после создания, инициализации и подготовки контекста идет вызов listeners.ready(...)

  public ConfigurableApplicationContext run(String... args) {
    ...
    try {
      ...
      context = createApplicationContext();
      ...
    }
    try {
      if (context.isRunning()) {
        listeners.ready(context, startup.ready());
      }
    }
    ...
  }

Здесь вызывается EventPublishingRunListener#ready, который и выставляет статус readiness probe в UP:

org.springframework.boot.context.event.EventPublishingRunListener#ready

@Override
  public void ready(ConfigurableApplicationContext context, Duration timeTaken) {
    context.publishEvent(new ApplicationReadyEvent(this.application, this.args, context, timeTaken));
    AvailabilityChangeEvent.publish(context, ReadinessState.ACCEPTING_TRAFFIC);
  }

А context.publishEvent в свою очередь вызывает

org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent

@Override
  public void multicastEvent(ApplicationEvent event, @Nullable ResolvableType eventType) {
    ...
    for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {
      if (executor != null && listener.supportsAsyncExecution()) {
        try {
          executor.execute(() -> invokeListener(listener, event));
        }...
  }

invokeListeners(...) - как раз приводит к вызову нашего метода generate, помеченного аннотацией @EventListener(AppricationReadyEvent.class)
Поэтому, пока он не завершится, readiness probe не будет переведена в статус UP.
Переопределить метод EventPublishingRunListener#ready нет возможности, поэтому было решено при старте запускать формирование отчета в новом потоке. Т.к. продолжительный метод генерации выполняется в новом потоке, в основном потоке метод generateAtStartup быстро завершается, не блокируясь, и readiness probe переводится в UP.

@Autowired
ScheduledExecutorService executorService;

@EventListener(ApplicationReadyEvent.class)
public void generateAtStartup() {
  executorService.schedule(this::generateReport, 20, TimeUnit.SECONDS);
}

private void generate() { //логика создания отчета }

#рабочее

https://dmatveeva.github.io/sql-relational-theory-1/

В статье – обзор первой главы книги “Sql и реляционная теория” Дж. Дейта.

Что такое реляционная модель и зачем она нужна разработчику?

При изучении sql реляционная модель обычно упоминается мимоходом, а основной упор делается на изучение языка sql, или даже какого-то его диалекта, например для oracle. Между тем, SQL и реляционная теория - не одно и то же, а профессионал в области баз данных должен знать реляционную теорию, т.к. вся область знания об управлении базами данных построена на ней. Разработчик может использовать БД разных вендоров, различные диалекты, но базовые принципы всегда останутся те же самые.

Продолжение заметок по миграции spring boot микросервисов с oracle на postgresql.

1. Конструкция limit в postgresql заменяет подзапрос с аналитической функцией row_number в oracle.

Postgresql:

select product_id
from product
order by create_date limit 1

Oracle:

select product_id
from ( 
  select product_id, row_number() over (order by modify_date) as rn
  from product
) t
where t.rn=1

2. Склейка строк через || в postgreql не null-безопасна в отличии от oracle. Если один из аргументов is null, то вся строка превратится в null. Поэтому лучше использовать функции concat и concat_ws.

3. Неочевидные ошибки вида Error near 'type', Error near 'precision'
Оказалось, что type и precision - это ключевые слова в postgresql, и при использовании их в качестве алиасов требуется указать as.

4. Insert и not null поля.
Cоздание сущности employee (через hibernate) работало в oracle, а в postgresql стало падать с ошибкой, что не заполнено обязательное поле is_retired.
Оказалось, что в oracle поле в таблице employee было объявлено с конструкцией on null, а в postgresql мигрировало без него, т.к. нет прямого аналога:

Oracle:

create table employee (
       is_retired numeric default on null 0 not null 
)

Postgresql:

create table employee (
       is_retired numeric not null default 0
)

А если в postgresql явно передается null, то это переопределяет default.
В итоге пришлось в коде явно прописать дефолтное значение для атрибута isRetired.

#рабочее

Продолжаю заметки по миграции spring boot микросервисов с oracle на postgres.
Во время адаптации миграции несколько раз сталкивалась с особенностями конвертации полей различных типов в двух БД.
Вот несколько примеров:

✔️ В oracle в нативном запросе есть джойн по колонкам с типами varchar and number.
Например:

create table employee ( id number )
create table tasks ( id number, employee_id varchar )

select * from employee e join tasks t on e.id = t.employee_id;

Oracle неявно делает конвертацию to_number(t.employee_id)=e.id, и если в таблице employee колонка employee_id содержит только строки, которые можно конвертировать в число, то запрос отработает нормально. Но postgres выдаст ошибку, и для решения нужно будет явно привести один тип к другому.

✔️Изначально в oracle в таблице БД есть колонка с типом number, а в коде, в сущности hibernate, она маппится на поле с типом String. В postgres колонка мигрирует с типом bigint. При работе приложения, oracle спокойно делает конвертацию, а postgres выдает ошибку на несоответствие типов.
Решение - заменить тип поля в сущности на Long.
Чуть было не пропустила эту ошибку, т.к. на первых порах писала тесты лишь для тех методов репозиториев, где объявлены нативные запросы. А она обнаружилась случайно как раз для сущности, для которой нет таких методов. После этого начала писать тесты вообще для всех сущностей и отловила не одну такую ситуацию.

✔️ В oracle в таблице БД есть колонка с типом varchar, которая маппится на поле с типом boolean. Предполагается, что в БД значения колонки 0/1.
Опять же, oracle конвертирует, а для корректной работы в postgres, нужно добавить аннотацию @Type(type="org.hibernate.type.NumericBooleanType") на поле сущности.

#рабочее

Сейчас на нашем проекте идет активный перевод существующих spring boot микросервисов с oracle на postgres. Задача разработчика - адаптировать нативные запросы, затем завести микросервис локально у себя на машине и вызвать пару эндпойнтов, чтобы убедиться в минимальной работоспособности. Затем микросервис развертывается на дев стенде и передается в тестирование QA команде.
Этот процесс осложняется тем, что микросервисы часто имеют множество зависимостей от других микросервисов, и чтобы запустить один, нужно запустить несколько других.
И вдобавок, не все сервисы содержат юнит-тесты.
Поэтому нужно было писать довольно много тестов. И очень удобно оказалось запускать их лишь для репозиториев с нативными запросами, не поднимая весь контекст спринга:

1. К тестовому классу добавила аннотацию DataJpaTest (вместо SpringBootTest, которая поднимает весь контекст)
2. DataJpaTest использует embedded in-memory БД. Чтобы подключиться к нужной базе, использовала AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
3. Ну и ActiveProfile("test"), чтобы Spring Boot подхватил параметры подключения к базе из профиля test в test-application.yml

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

#рабочее

Сейчас наша команда активно ищет новых разработчиков на Java, и я уже несколько недель участвую в собеседованиях.
Наблюдения:

▫️ Теперь понимаю, почему иногда, будучи кандидатом, получала вопросы, казавшиеся странными.
Например вопрос интервьюера, много ли вы писали кода на рабочем месте? Казалось бы, конечно, ведь я разработчик. Но вот например один из кандидатов сказал, что уже несколько месяцев не пишет код, а занимается задачами devops, хотя в резюме как раз указано разработчик .

▫️ Обычно наш тимлид дает несколько фрагментов кода и просит найти и исправить ошибку. И почему-то кандидаты неохотно пишут код. Большинство людей просто размышляли вслух, всего пару человек писали и исправляли. Один из них правда не приблизился к решению, но начал активно рефакторить существующие классы, из-за чего решение перестало компилироваться.

▫️И уже несколько человек сказали, что долго работали в реактивном стэке, и поэтому забыли Hibernate.

Первый пост-обзор на книгу "Микросервисы. Паттерны разработки и рефакторинга".
https://dmatveeva.github.io/microservices/

Kubernetes cheatsheet:
https://dmatveeva.github.io/kubernetes-cheatsheet/

Версионирование базы данных с Liquibase:
https://dmatveeva.github.io/liquibase/

Немного о скоростях, с которыми работает компьютер, и ссылки на инфографику:
https://dmatveeva.github.io/latency-numbers/

Немного об устройстве компьютера и реализации многопоточности.
https://dmatveeva.github.io/how-computer-works/

Channel name was changed to «System Design с Дарьей Матвеевой»