Книга: Создание микросервисов

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

Об авторе

Ты не знаешь кто такой автор? Не беда! Знаешь Мартина Фаулера? Да, того мужика, который топит за Рефакторинг, Шаблоны корпоративных приложений и UML (это всё его книжки), ну и конечно за микросервисы в своем блоге. Так вот, Сэм и Мартин работают в одной конторе ThoughtWorks. На сколько я понимаю, эти ребята занимаются консалтингом в построении всяких разных систем и в использовании микросервисных архитектур. Занятная работенка. Между делом ребята пишут книги, вот сегодня и поговорим про одну из них.

Обзор

Сразу скажу, впечатления от книги хорошие. На многие вопросы она дает ответы, но не на все. Такс, давай по порядку.

Прежде всего я для себя усвоил из книги интересную и, пожалуй, самую главную мысль. Твои и мои системы будут падать, обязательно будут падать. Вот так, без этого в нашем производстве никак. Сэм обращает внимание на одну забавную вещь. В действительности среди наших коллег можно наблюдать Архитекторов, Инженеров и другие громкие названия должностей, при том, что это всё заимствованные слова из других профессий. Архитектор софта и архитектор здания или моста это совершенно несравнимые люди. За архитекторами, которые проектируют очередной мост, стоит огромная история, тонна знаний, которые передаются из века в век, снова и снова. Какой релевантный багаж у наших архитекторов, ну, например, банковских систем? 20-40 лет? В масштабах реальной архитектуры это практически ничто. Мы пытаемся навешать ярлыков, чтобы ощутить ложное чувство защищенности, но от правды никуда не скроешься. Наши системы обязательно будут где-то падать, где-то работать не так как ожидалось и это нормально, для текущего этапа прогресса, это вполне приемлемо. Наша же задача, быть к этому готовыми. В общем, мне нравится эта мысль, особенно на фоне прочтения статей о crash-only software.

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

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

Пара важных паттернов, которые вы встретите в книге, это Backends for Frontends и Tolerant Reader. Про последний я уже писал вот здесь. Backends for Frontends это когда вы под кажный тип клиента имеете по сути свой gateway, который контролирует объем данных, необходимый этому виду клиента, например, когда нам нужно получить данные на мобильный клиент их, во-первых, должно быть по минимуму, во-вторых, для экономии батареи устройства использовать минимум запросов. Дроссель - это еще один интересный паттерн, который описывает автор, как полезный подход при миграции с legacy систем.

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

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

Разделы о развертывании и тестировании хорошо пересекаются с видео, которое я упоминал на своем телеграм канале

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

Из недостатков, я не увидел практически никакой информации о том какие практики используются для авторизации действий пользователей в системе. JWT токен был упомянут единожды вскользь. Как автор администрировал одновременно множество сервисов также остается загадкой, возможно никак. Хотя у меня есть представление как реализовать всё, что меня интересует, в книге этой информации нет.

Заключение

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