Предисловие

На написание данной статьи меня натолкнуло то, что я хотел бы оставить ответы на интересующие меня в момент изучения мной микросервисов — вопросы.

Также хотелось бы отметить, что в статье не исключено наличие странностей, недосказанностей, и ошибок — возникли они по причине того что данная статья написана с целью описания в ней своего опыта исследования темы Микросервисов.

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

Приятного чтения!

Важное замечание

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

Содержание

• Что такое микросервисы?

• Почему тебе не нужны микросервисы?

• Зачем нужны микросервисы?

• Когда нужно использовать микросервисы?

• Почему «Монолит» это не плохо?

• Технологический стек микросервисной архитектуры

• «Стирание границ между бизнесом и разработкой»

• Материалы для изучения

Что такое микросервисы?

Микросервисы, или микросервисная архитектура — это не про способ реализации своего монолитного приложения, это не про язык программирования.

Действительно странная вещь, но ассоциация у некоторых людей при слове микросервисов возникает что это что то там про GO, и что это вот только на нем.

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

И да, тематика предметно‑ориентированного проектирования (DDD) и микросервисной архитектуры — тесно связанны, посему, настоятельно рекомендую к ознакомлению материалы Эрика Эванса и Вернона Вона

• Реализация методов предметно‑ориентированного проектирования | Вернон Вон

• Предметно‑ориентированное проектирование (DDD). Структуризация сложных программных систем | Эванс Эрик

Способ выделение логических элементов системы, а так же парадигмы микросервисной архитектуры приводят также к необходимости разделению вашей БД из состояния — общая БД для огромного монолита, в состояние когда для каждого элемента систему вы реализуете отдельную обособленную от остальных микросервисов БД. У этого способа так же есть свои плюсы и минусы — об этом поговорим чуть дальше.

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

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

Почему тебе не нужны микросервисы?

Ты стартап? — Тебе не нужны микросервисы.
У тебя нет денег? — Тебе не нужны микросервисы.

Что же не так?

Проблема микросервисов в том, что это слишком дорого... Микросервисная архитектура на этапе зарождения продукта, это 100% необоснованное решение. И кто то возразит — но ведь в случае масштабирования у нас будет момент для маневра. Но есть проблема в том что никто не знает, будет ли выбранная вами идея приносить вам доход который будет покрывать ваши затраты на разработку в среде микросервисной архитектуры...

Все немного неоднозначно, но для реализации подобной архитектуры, с учетом того что на старте можно обойтись только разработчиками, то в будущем вам так или иначе придется взять в команду как минимум — devops инженера, так как справляться с задачей развертывания —качественно, разработчики вряд ли смогут (да и не очень то и захотят).

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

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

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

Микросервисы - это не самый легкий вариант. Попробуйте для начала более простые подходы.

Зачем нужны микросервисы?

Давайте разберем парочку преимуществ и недостатков системы, разработанной на основе микросервисной архитектуры.

Преимущества?

Командоориентированность

Кто то со мной поспорит (и не сомневаюсь что окажется прав), но в случае с монолитной архитектурой, в99% случаях возникают проблемы с доставкой обновлений из‑за возможных проблем с менеджментом и очередью разработки той или иной части задачи/задач, частые проблемы с конфликтом интересов и прочие возникающие проблемы с точки зрения ориентира на командность в монолит‑проекте.

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

Масштабирование

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

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

Ко всему прочему, независимое масштабирование упрощает управление инфраструктурой и позволяет более гибко реагировать на изменения в бизнес‑требованиях.

Развертывание

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

Бывалый поймет, что преимущество это ценно, так как ситуации когда кто то положил «бэк» выпустив код с ошибками на «прод» — бывают очень печальными...

Недостатки?

Согласованность данных

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

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

На эту тему, есть — большая, достаточно познавательная и интересная статья

Технологическая перегрузка

Микросервисная архитектура подразумевает использование множества различных технологий и инструментов для управления разными сервисами: контейнеризация (Docker), оркестрация (Kubernetes), системы мониторинга, логирования и автоматизации развертывания, Apache Kafka.

В случае отсутствия devops инженеров — это приводит к необходимости глубоко разбираться в разных инструментах, что увеличивает когнитивную нагрузку на команду разработчиков.

Стоимость

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

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

Когда нужно использовать микросервисы?

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

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

Также микросервисы подходят для проектов, которые предполагают разнообразные требования к масштабируемости. Например, если одна часть системы испытывает значительно большую нагрузку (например, платежная система в интернет‑магазине), ее можно масштабировать независимо от остальных сервисов.

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

Почему «Монолит» это не плохо?

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

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

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

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

2. Целостность – Вся логика и зависимости находятся в одном месте, что упрощает отладку, тестирование и развертывание. Нет необходимости в сложной настройке коммуникаций между сервисами.

3. Производительность – В монолитах нет накладных расходов на взаимодействие между сервисами по сети (как в случае микросервисной архитектуры), что может положительно сказаться на производительности.

4. Простое развертывание – Развёртывание монолита зачастую происходит быстрее и легче, так как вся система запускается как единое целое, что упрощает процесс управления версиями.

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

6. Меньшая зависимость от команды — Поскольку вся система едина, одна команда может эффективно поддерживать её, не прибегая к специализированным навыкам для управления множеством сервисов. Так же, в монолит порог вхождения к примеру нового сотрудника, гораздо ниже, в отличие от проекта с микросервисной архитектурой.

Технологический стек микросервисной архитектуры

Помимо выбранного вами языка программирования, вам так же понадобится определенный ряд инструментов для работы и взаимодействия с микросервисами:

1. Kubernetes
   Обеспечивает оркестрацию контейнеров, автоматизацию развертывания, масштабирования и управления контейнеризованными приложениями.

2. Docker
   Используется для контейнеризации микросервисов, упрощает развертывание и управление зависимостями.

3. REST / gRPC
   Протоколы для общения между микросервисами. REST подходит для веб-приложений, gRPC оптимален для высокопроизводительных систем.

4. API Gateway
   Центральная точка маршрутизации запросов, упрощает клиентам взаимодействие с несколькими микросервисами.

5. Kafka / RabbitMQ
   Системы обмена сообщениями для асинхронной передачи данных между микросервисами, помогают наладить коммуникацию и обработку событий.

6. Prometheus / Grafana
   Инструменты для мониторинга и визуализации данных, помогают отслеживать состояние микросервисов и производительность системы.

«Стирание границ между бизнесом и разработкой»

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

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

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

Каким образом это происходит с точки зрения конкретики?

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

Собственно, благодаря этому процесс разработки становится прозрачным, а адаптация к изменениям происходит быстрее и с меньшими затратами.

Материалы для изучения

• Микросервисы

  • Создание микросервисов. Издание 2. Сэм Ньюмен

• Предметно-ориентированное проектирование

  • Реализация методов предметно-ориентированного проектирования | Вернон Вон

  • Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем. Эванс Эрик