Часть 1. Разочарование от нового проекта и фундамент для перемен
Часть 2. Выделенная команда и первый сервис по новому стандарту
Часть 3. Разбиение монолита по DDD
Часть 4. Создание шаблона микросервиса
Часть 5. Свой подход к интеграционным тестам
Часть 6. Что дало создание шаблона
➡️ Часть 7. Распиливание, миграции и оптимизации
Часть 8. Добровольный боттлнек, коммуникации и овертаймы за свой счет
Часть 9. Что нужно, чтобы драйвить такие перемены и оставить бизнес довольным
Часть 10. Почему распустили System Team и что в итоге?

Там SOA было. Несколько огромных сервисов, скажем так, несколько монолитов. Здесь использовался классический подход – паттерн Strangler. То есть по чуть-чуть переносили функционал. Новый, кстати, мог сразу в новом сервисе реализовываться. На период перехода естественно появляются фича-флаги. Тут однозначно они должны быть.

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

В идеале-то все мы знаем эту красивую теорию, что отдельный сервис – отдельная база данных, но не всегда так получается. Мы конкретно тут споткнулись, что у нас просто на Production не хватило памяти, нужно было реаллоцировать. А сервис нужно было как-то делать здесь и сейчас, поэтому мы просто сделали отдельные схемы. Отдельные схемы в нашей большой РБД. То есть сейчас у нас одна база, она просто побита схемами. Это тоже вполне рабочий кейс.

Когда мы прорабатывали один из сервисов (во всех обсуждениях, дизайн-сессиях, кстати, я тоже участвовал со всеми командами, не только со своей, это была часть моей рутины), там было пару десятков таблиц, вроде как немного. И мы решили попробовать новый персистенс для нового сервиса задизайнить. Сделали и потом мучились от боли – промежуточный период существования двух персистансов был тяжелым.

Но в некоторых сервисах мы шли другим путем, то есть персистенс оставляли старым. Был конечно не очень приятный маппинг на Infrastructure Layer, но в целом Domain и Application Logic были изолированы от старой схемы данных, что не мешало строить правильные доменные модели. В общем какое-то время жили на старых таблицах.

Т.е. какое-то время пожить на не очень хорошо спроектированном для нового сервиса старом персистенсе и страшном маппинге могли себе позволить. Продукт в целом не хайлоад. Потерять там каких-то 50, даже где-то 70 миллисекунд, ну, ничего страшного.

Это кстати тоже играло свою роль в принятии некоторых решений. Сервера все у нас Central US и end users у нас тоже американские. Поэтому тут никаких скачков по материкам, только если для нас как для разработчиков;). Поэтому где-то какие-то решения вполне упрощенные. Где-то даже у нас не заюзан кэш по этим причинам.

Вот у нас есть запрос в аутентификационный сервис на валидацию токена. То есть, приходит токен с клиента, проходит через валидацию, и на выходе – контекст авторизации запроса в респонсе. То есть, там информация по юзеру, по тенанту, по клеймам и т.д. Возвращается все.

Суть в том, что, казалось бы, это долго все, и можно прикручивать кэш. Но, учитывая географию, мы путем долгих оптимизаций SQL запроса и кода добились того, что на Production на 50-ом персинтиле мы имеем до 9 мс. То есть очень быстро. При этом авторизационный контекст это достаточно большой объект. В общем просадок в этом сервисе пока нету;) А лишний компонент мейнтейнить, ну, наверное, пока желания нет.

Доступ к базе – 2 запроса по буквально 2-3 миллисекунды. Понятно, что у нас не все запросы 9 миллисекунд. Это 50-ый персентиль. Бывает побольше, бывает и поменьше.

То есть мы очень сильно оптимизировали SQL-запросы. Буквально перепробовали все, что можно. Потому что у нас была какая идея? Давайте попробуем выжать максимум.

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

Важный момент. Чтобы не выставлять прям супер строгие рамки на проекте, как реализованы объекты репозиториев в Infrastructure Layer я не сильно обращал внимание. Что я имею в виду? Юзается там ORM или plain sql. Даже в рамках одного микросервиса. Не сильно важно, главное, чтобы работало быстро. Конкретно на получении контекста авторизации мы не юзали ORM, а юзали plain sql, что как раз и позволило максимально оптимизировать запрос в БД.

В восьмой серии будет о нетехнической стороне внедрения нового шаблона – коммуникациях, соблюдении контрактов и ревью PR-ов.