Решил продублировать в блог набор реплик из Telegram-канала Архитектура ИС и порекомендовать к прочтению книжку Распределенные системы. Паттерны проектирования (Издательство Питер, 2019, в оригинале: Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services, March, 2018). Это тот редкий случай, когда для чтения перевода не нужно иметь под рукой англоязычный оригинал. Книжка, безусловно, про паттерны, но не только про паттерны. Так, например, один из вопросов, на которые она дает ответ – как быть с повторно-используемыми (reusable) компонентами в микросервисной архитектуре
В отличии от сервиса в сервис-ориентированной архитектуре, которые изначально рассматривался как компонент, разработанный для повторного использования, микросервис таковым не является. Скорее наоборот, мы реализуем в микросервисе некий частный случай, функционал, востребованный иногда или возможно востребованный, например, при тестировании гипотез или функции необходимые лишь части клиентов и т.п.
Где же в этом случае реализовывать многократно используемые функции? В монолите такие функции реализуются в виде библиотек, принося с одной стороны несомненную пользу, а с другой – ад зависимостей. Брендан Бёрнс, автор книжки про паттерны проектирования распределенных систем, рекомендует реализовывать такой функционал в виде отдельных контейнеров. Нужен вам reusable функционал – добавляете в свой pod соответствующий контейнер и вызываете его из основного процесса внутри вашего микросервиса.
Интересно влияние идеи повторно-используемых компонент в виде контейнеров, дополнительно включаемых в микросервисы, на корпоративные ИТ-ландшафты. Когда-то давно стандартизация, унификация и борьба с дублированием функционала в корпоративных ИТ велась под флагом внедрения единых систем: корпоративное хранилище данных, корпоративная сервисная шина и т.п. (в английском, название таких систем начинаются со слова Enterprise). Когда стало ясно, что подобные системы моментально превращаются в черные дыры, способные пожирать данные и бюджеты, но совершенно не справляющиеся с задачей быстрой поставки функционала, политика корпоративных ИТ скорректировалась в сторону SOA-сервисов. Мол реализуйте логику где и на чем хотите, но читайте данные и отправляйте команды через обязательный набор сервисов. Сейчас вместо общих сервисов приходит тема раздачи адаптеров. Это чем-то похоже на service mesh. Нужен вам какой-нибудь справочник? – подцепите в свой pod MDM-контейнер, а где он возьмет данные и как раздаст их по всем узлам – это уже не забота прикладного программиста.
Вообще говоря, это уже не вполне микросервисы, что, само по себе, и не хорошо и не плохо. Зато какое поле деятельности для очередной волны переписывания всех корпоративных систем
Кстати, книжка довольно небольшая, чуть больше 200 страниц. Обзор её от издателя перевода на Хабре https://habr.com/ru/company/piter/blog/442514/ а ссылка на страницу книги с оглавлением и ознакомительным фрагментом на сайте издателя приведена выше. Паттернов проектирования распределенных систем, наверняка должно быть больше, особенно, если считать с анти-паттернами(другой подход к теме см., например, здесь: https://www.infoq.com/articles/kubernetes-effect/). Но паттерны – это штука, которая плохо поддается учету. У кого-то их три, у кого-то пять, а еще у кого-нибудь пятьдесят, но он их никогда не использует. Мне показалось, что автор скорее использовал паттерны, в качестве последовательных вех, раскрывающих некий общий подход от простого к сложному, от одноузловых паттернов, через технологические компоненты к принципу проектирования прикладных решений