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