Недавно прочитал книгу Криса Ричардсона «Микросервисы», о которой и хотел рассказать в этом посте. Это довольно объемная книга, в ней больше 500 страниц, и в оригинале она называется «Microservices Patterns with examples in Java», что более точно описывает содержание книги. В этой книге действительно упор сделан на типичные шаблоны проектирования при использовании микросервисной архитектуры. Основное содержание книги крутится вокруг выдуманной компании, которая разрабатывает сервис по доставки еды из ресторанов. У них уже есть написанное на Java монолитное приложение, и разработчики решили его разбить на микросервисы. В книге описываются, какие сложности при это могут возникнуть, как спроектировать взаимодействующую систему монолитов, и какие приемы для решения различных типичных проблем можно использовать.

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

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

Вторая глава посвящена тому, как начинать выстраивать архитектуру на основе микросервисов, рассказывается про архитектурные шаблоны на уровне микросервисов, говорится о том, что архитектуру можно рассматривать с разных точек зрения и на разных уровнях. Например, в виде логического представления (на уровне классов и пакетов), на уровне модулей (WAR, JAR, если говорить о Java), на уровне процессов и взаимодействия между ними и на уровне развертывания на различных устройствах. В этой же главе рассматриваются связи между микросервисами, говорится о проблеме, когда приложение формально состоит из микросервисов, но они настолько между собой взаимозависимы, что этот набор микросервисов можно назвать «распределенным монолитом». Здесь же говорится коротко о Domain-Driven Design — DDD (кстати, если кто знает хорошу. книжку про него, то, плз, напишите в комментариях), а также способах логического разделения монолита на микросервисы.

Третья глава посвящена взаимодействию между микросервисами. Здесь рассматриваются способы синхронного и асинхронного взаимодействия, говорится о том, почему асинхронное взаимодействие (например, через Kafka) при увеличении количества микросервисов не снижает (или не так сильно снижает) доступность и общую надежность системы. Здесь же говорится о способах обнаружения сервисов. Очень подробно рассматриваются проблемы, связанные с асинхронным взаимодействием микросервисов, например проблема определения порядка отправки сообщений, их дублирования или параллельной обработки одного события разными сервисами.

Четвертая глава посвящена шаблону «повествование» (Saga), когда нужно организовать асинхронную последовательность взаимодействия между микросервисами, причем некоторые взаимодействия могут закончиться неудачей, и тогда нужно будет уметь откатить уже выполненные в рамках повествования действия. Эта тема о том, как организовать в некотором роде распределенную транзакцию — очень большая проблема в распределенных системах, которой нет в монолите благодаря транзакционной модели в классических реляционных базах данных. Очень интересная тема, хотя реализовывать этот шаблон, конечно, муторно. В этой главе автор рассказывает о своем фреймворке, который написал для облегчений создания повествований.

Пятая глава посвящена выделению бизнес-логики в микросервисной архитектуре. Здесь рассматриваются несколько шаблонов проектирования, связанных с выделением бизнес-логики и отделения ее от сопутствующих микросервисов. В этой главе опять вспоминают о DDD. В этой главе очень подробно рассматривается шаблон проектирования «Агрегат» (кластер доменных объектов, с которыми можно обращаться как с единым целым) и «Доменное событие».

Следующая глава тоже посвящена событиям при взаимодействии микросервисов, но более конкретным событиям — а именно шаблону Event Sourcing, на русский язык это перевели как «порождение событий», хотя по логике это было бы правильнее назвать «порождающие события». Это шаблон, который сохраняющий где-то последовательность событий (например, в базе), на основе которых в будущем можно будет воссоздать объект (или агрегат в терминах DDD). В этой главе рассматриваются различные проблемы этого шаблона (например, как быть при миграциях?) и модификации, в частности, создание периодических снапшотов, чтобы каждый раз не надо было создавать агрегат на основе большого количества событий.

Седьмая глава посвящена тому, как организовать взаимодействие между микросервисами и клиентом. Здесь очень подробно рассматривается шаблон «Разделение ответственности командных запросов» — CQRS (Command Query Responsibility Segregation). Этот запрос позволяет разделить запросы, связанные с изменением данных, и запросы на получение какого-то особенного представления данных.

Восьмая глава посвящена возможным реализациям API Gateway, в том числе рассказывается о шаблоне Backends For Frontends (BFF), когда для каждого типа клиентов (фронтенд, мобильный клиент, стороннее приложение) создается свой API. В этой же главе коротко (на десяти страницах) рассказывается о GraphQL.

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

Остальные три главы скорее обзорные и больше посвящены DevOps (например, развертыванию с помощью Kubernetes посвящено целых 10 страниц), поэтому я про них скажу как о едином разделе. Здесь поминаются многие интересные штуки вроде Istio, как основа архитектуры, которая появилась совсем недавно и называется сервисная сетка (service mesh), когда многие задачи, связанные со взаимодействием микросервисов, которые раньше решали отдельные приложения самостоятельно, теперь перекладываются на инфраструктуру. Например, тот же Istio может реализовывать шаблон «рубильник», когда к какому-то микросервису перестают слать новые запросы, если он до этого стал недоступен. Ну а вообще Istio может брать на себя еще много других инфраструктурных задач. Istio достоин отдельной книги, здесь он только упоминается наряду с подобными системами и рассказывается только об основной идее. В книге приводятся даже длинные листинги настроек Kubernetes и Istio, но того материала, что имеется в книге явно мало, чтобы от этих примеров был какой-то толк. Примерно столько же места отведено бессерверному развертыванию (как же я не люблю этот маркетинговый термин!). Но тут уже можно лучше понять суть технологии и примеры оказываются полезными, хотя их тоже нельзя назвать подробным описанием технологии. Также в последних главах затрагивается тема безопасности, аутентификации пользователей и очень поверхностно рассказывается о технологии OAuth 2.0. Здесь также говорится о мониторинге сервисов и о логах.

Если говорить о книге в целом, то она мне понравилась. Очень хорошо написана теория шаблонов проектирования, о которых рассказывается. Помимо описания буквами к каждому шаблону прилагаются схемы и пример кода. Вот в них разбираться было уже тяжелее. Схемы достаточно перегруженные, еще переводчики «постарались» и зачем-то перевели на них некоторые названия классов и объектов, которые в тексте остаются в виде англоязычного наименования, поэтому иногда в уме приходилось переводить в обратную сторону, чтобы связать картинку с текстом (в остальном, кстати, перевод достаточно неплохой, явные косяки в глаза не бросались). Что касается кода, то все показано здесь на примере достаточно большого приложения доставки еды из ресторана, состоящего из нескольких микросервисов. Листинги кода иногда достаточно длинные. Может быть это моя особенность, но я не люблю такие пространные пояснительные куски кода, поэтому лично для меня они воспринимались очень тяжело, потому что надо держать в уме классы, которые описывались в предыдущих главах. Мне все-таки больше нравятся компактные изолированные примеры, а не единый пример, проходящий через всю книгу. Примеры написаны на Java c использованием Spring, но в принципе его знать не обязательно. Честно говоря, когда я начал читать эту книгу, то надеялся заодно поднять свой уровень владения Spring, но примеры использовали Spring на базовом уровне без каких-то хитрых его особенностей. Это на самом деле плюс для тех, кто пишет на других языках, ведь в русском переводе из заголовка книги исчезло упоминание Java. Но несмотря на тяжеловесность кода и диаграмм, основное описание шаблонов достаточно подробное и понятное. К некоторым недостаткам я бы отнес еще последние главы, которые получились очень поверхностные. Наверное, автор их написал, потому что нельзя в книге про микросервисы обойти тему DevOps, но в то же время про каждую затронутую в последних главах тему, можно написать отдельную книгу.

В итоге я бы поставил книге 4 из 5. Если вы ничего еще не читали про микросервисную архитектуру, то прочитать ее стоит, особенно, если вы пишете на Java и перед вами стоит задача распилить монолит.

PS. Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.