Обзор книги “Microservice Patterns and Best Practices”

Прочитал на выходных очередную книжку по архитектуре программного обеспечения “Microservice Patterns and Best Practices” за авторством Vinicius Feitosa Pacheco. Книжка определенно интересная, с практическим уклоном, но немного не мой профиль. Я люблю концепции и теории, а автор пошел от сохи:) В процессе построения микросервисной архитектуры для новостного портала вы познакомитесь как с архитектурными концепциями и паттернами, так и попишите код на python и go, поконфигурируете nginx, напишите docker файлы, настроите docker compose и т.д. А я люблю читать концепции, хотя ясно, что дьявол кроется в деталях, но явно не в настолько простых.

Рис.1 “Заставка книги”

Автор начинает с того, чтобы объяснить концепцию микросервисов. И выделяет на это первую часть книги. Начинается все с обсуждения приложения и концепций, что помогут его сделать лучше:

  • DDD (Domain Driven Design) — среди всех инструментов автор выбирает три, которрые отлично ложатся в концепцию микросервисной архитектуры: Context maps, Anti-corruption layer, Interchange context
  • Single Responsibility Principle — буква “S” из SOLID:) Но я рекомендую глянуть более общий принцип Common Closure Principle из книжки Uncle Bob “Clean Architecture”
  • Explicitly published interface — здесь говорится о прямо опубликованном интерфейсе, который минимально необходимого размера, с версиями и публично опубликован только внешний (external) интерфейс (то, что мы пообещали клиентам)

Дальше рассматривается вопрос независимого деплоя, агрейда, масштабирования и замены. Ключевое слово тут — “независимый”. Отдельно стоит упомянуть “Scale Cube”, который подробно обсуждался в книге “The art of Scalability”. Этот куб трехмерный (и слава богу, т.к. рисовать тессеракт я не умею).

В качестве осей выступают:

Рис.2 “Scale Cube”
  • X-axis — горизонтальная декомпозиция (закидаем инстансами)
  • Y-axis — функциональная декомпозиция (растащем разные функции в отдельные инстансы)
  • Z-axis — партиционирование (шардирование) данных (мы уже отчаялись и готовы на все)

Способы коммуникации, среди которых есть 2: синхронная и асинхронная. И т.д.

Вторая глава целиком посвящена тулингу для микросервисов. Автор рассматривает его довольно здраво и в конце определяется с инструментами:

  • python с flask’ом
  • go без фреймворка
  • rabbit, redis, etc

В третьей главе рассматриваются внутренние паттерны:

  • для структурирования проекта
  • стратегии кеширования
  • CQRS для разделения команд на изменение и запросов для получения данных
  • Event sourcing и чем он отличается от CQRS

Четвертая глава отдана обсуждению экосистемы микросервисов:

  • отдельные контейнеры под сервисы
  • неплохие подходы к декомпозиции на отдельные микросервисы
  • хранение данных — деление на горячие и холодные, а также по регионам:)
  • работа с failures — проектирование с избыточностью, разделение по критичности, проектирование с изоляцией (типа переборок на Титанике, но рабочих), принцип “fail fast” и отдельно использование паттерна circuit breaker

В пятой главе рассматривается паттерн/антипаттерн “shared data microservices”. По факту, для greenfield, когда вы проектируете и создаете с нуля — это антипаттерн. Но для brown field, когда у вас уже есть монолит, это неплохая возможность начать дробить монолит на микросервисы. Вот рабочий алгоритм:

  • определитесь с приоритетами
  • выставите дедлайны — они помогут вам понимать как движется распил монолита, который часто настолько же бесконечен, насколько ремонт:)
  • определите домен
  • проведите эксперименты
  • определите стандарты
  • создайте прототип
  • отправьте его на production

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

  • База данных для хранения данных, а не для бизнес правил
  • База данных для хранения данных, а не для обмена событиями (через триггеры)
  • Не создавайте сущностей с циклическими зависимостями

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

  • Aggregator Microservice Design Pattern
  • Proxy Microservice Design Pattern
  • Chained Microservice Design Pattern
  • Branch Microservice Design Pattern (Aggregator + Chained в связке)

В десятой главе автор рассказывает про асинхронный способ коммуникаций. Рассказывает неплохо, но я бы порекомендовал почитать отдельную книгу “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions” (Addison-Wesley Signature Series) Gregor Hohpe, Bobby Woolf.

В одиннадцатой главе автор собирает все разработанные микеросервисы вместе и рассказывает про то, как разделить микросервисы по уровням

  • public facing layer — то, что опубликовано для клиентов
  • internal layer — то, что мы используем внутри

Последние две главы посвящены тестированию, а также вопросам эксплуатации (мониторинг, безопасность, deploy). По этим вопросам тоже дана только краткая информация, но ее достаточно, чтобы на коленке запилить набор микросервисов.

Если подвести итог, то можно признать, что книга достаточно хороша. Она подойдет тем, кто много слышал про микросервисы, но не щупал их вживую. В этой книге вам расскажут как их пилить правильно, а также покажут на практике как это реализовать:)

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store