Монолиты и микросервисы. Какая архитектура лучше подходит для вашего бизнеса?
Изображение: Shutterstock.ai
Когда микросервисы оправданны
Архитектура на базе микросервисов действительно может быть оправдана при определенных факторах, но также бывает выгоднее начать с монолитного приложения. Сбой Prime Video, который взбудоражил весь интернет, тому подтверждение.
Возможно, это будет оправдано, когда компания дойдет до размеров, например, Амазона. В таком случае могут появиться ситуации, где архитектура микросервисов станет оправданной. Но даже у такого гиганта, как GitHub, ключевые приложения представляют собой монолиты с миллионами строк кода, над которыми работают тысячи программистов. Если у вас нет такого объема, то даже не задумывайтесь о микросервисах.
Восстанавливаем порядок после преждевременного перехода на микросервисы
Если же вы уже перешли на архитектуру микросервисов, но сделали это без понимания назначения такой архитектуры, то следует восстановить порядок. Поговорим о том, как это можно сделать.
Для начала прекратите усугублять ситуацию. Не получится разгрести этот беспорядок, продолжая его нагромождать. Откажитесь от внедрения новых микросервисов. Вместо этого нужно выбрать один из существующих в качестве эпицентра, в который будет встраиваться новая функциональность. Новый центр в итоге должен поглотить большинство других микросервисов. Но главное — не ухудшать и без того сложное положение.
Далее консолидируйте критические взаимозависимые компоненты. Худший признак микросервисов, если последовательный поток операций разделен на несколько разрозненных систем. Будь то регистрация, оформление заказа или просмотр отдельного фрагмента контента — именно в таких случаях микросервисы наносят максимальный вред, серьезно затрудняя обновление всего потока и создавая риски ошибок. Внесение изменений требует координации между множеством систем, решения проблем синхронизации и так далее. Поэтому консолидация микросервисов в макросервисы на пути к единому монолиту должна начинаться именно с таких критических взаимозависимых компонентов.
Еще один пункт, о котором не стоит забывать — изолированные высоконагруженные сегменты. Их лучше объединять в последнюю очередь. Если микросервисы спроектированы правильно, то часто выделяют узкий, обособленный и, как правило, требовательный к производительности участок системы, который может выиграть от переписывания на более производительный язык программирования. Например, все веб-приложение написано на Java, но есть один экран, который испытывает резкие скачки нагрузки, поэтому сервис может быть написан на C++, чтобы максимизировать отдачу от процессора. В таком случае грамотно используем микросервисную архитектуру. Однако теперь следует убедиться, что действительно получилось провести бенчмаркинг и доказать, что регресс производительности того стоил.
Выбирайте более простые и универсальные решения. Одним из побочных эффектов микросервисов является тенденция использовать множество разных языков программирования, фреймворков и экосистем. Но результатом может стать система, состоящая из разных языков программирования, чаще всего, от 3 до 5, большого количества разнородных фреймворков и целого клубка взаимозависимостей. Это убийственно для целостного понимания и приводит к распространенному симптому микросервисной архитектуры — ситуации, когда никто не понимает, что происходит и не может работать со всей системой целиком. Поэтому важно начать упрощать.
В подавляющем большинстве систем должно быть не более двух языков для бэкенда: один универсальный, оптимизированный для производительности разработчика, который нужно будет использовать 99% времени, и один высокопроизводительный язык для решения оставшегося процента узких задач, если такие появятся.
Изучаем основы перед применением сложных архитектур
Научитесь разбивать большие системы на модули, а не на распределенные сервисы. Многие переходили к микросервисам из-за того, что думали, что если не умеешь правильно проектировать крупные системы с помощью программных абстракций вроде модулей и пространств имен, то можно решить проблему, разделив систему сетевыми границами. Но это путь в никуда.
Создать большую, надежную и производительную систему сложно. А пытаться разрабатывать ее для новой предметной области с самого первого дня — невозможно.
Классической книгой, которая научит вас разбивать огромные предметные области на стройные доменные модели, является «Предметно-ориентированное проектирование» Эрика Эванса. Но к такой сложной архитектуре стоит переходить только после того, как получится освоить базовые навыки программирования. Если вы пока только начинаете свой путь, то советую прочитать что-то попроще вроде «Паттерны проектирования» Мартина Фаулера.
В ИТ хватает ярких, увлеченных ребят. Многие из них рвутся сразу стать «крутыми разработчиками», но при этом пока не знают даже основ. Самоуверенность и стремление — это круто, но есть вещи, которые приходят только с опытом. Поэтому новичков следует предупреждать об опасностях микросервисов. Не стоит бояться учиться на своих ошибках, без них невозможен рост. Обучение — это круто, можно всегда начать с чистого листа. Новые знания могут помочь пересмотреть старые решения и сделать иначе.
Осторожно применяем микросервисы
Микросервисы, как и любой другой паттерн — просто инструмент. Фраза «все зависит от контекста» верна, но одних этих слов мало, чтобы помочь создавать крутые системы. Нужно пояснить, от чего именно это зависит.
Эффективное применение микросервисов обычно завязано на двух факторах. Во-первых, на наличии большой сложной системы, которая выросла из простого прототипа. Во-вторых, на возможности отделить компонент с жесткими границами и без критических связей, причем только если это реально повысит производительность или есть плюшки от изоляции команды.
Заключение
Итак, выбор архитектуры является важным процессом в разработке. Вы должны четко понимать, что нужно вашей системе. Можно использовать микросервисы, а можно реализовать монолит. Важно понимать тенденцию развития проекта, чтобы правильно выбрать архитектуру и реализовать надежное ПО.
Опубликовано 18.04.2024
