Вспомнил про этот вопрос, когда вчера заглянул в холодильник. Нужен был помидор, для того чтобы сделать бургеры. В холодильнике лежала одна большая помидорина, низом к верху. Беру я эту помидорину, переворачиваю, а она с другой стороны уже начала чернеть. Пришлось выкинуть всю помидорину весом грамм в 400. При этом были еще помидорки черри. Но они для бургеров не подходят. Но зато если испортится один черрик то не надо выкидывать всю пачку. Да, на основании вот такой аналогии перейдем к микросервисам))
❓Что такое микросервисы – это архитектурный стиль, при котором приложение или система строится как набор сервисов, каждый из которых решает набор определенных задач и закрывает отдельный набор потребностей бизнеса. При этом задачи, решаемые каждым отдельным сервисом, как правило не дублируются внутри других сервисов.
❓Плюсы микросервисов:
➕Масштабируемость и отказоустойчивость за счет того, что может быть запущено несколько экземпляров одного сервиса.
➕Возможность частичного обновления. Т.е. для реализации разработки функционала, необходимо внести изменения только в одном микро сервисе, без остановки всего приложения. Это позитивно влияет на показатель доступности приложения.
➕Лучшая надежность. В случае сбоев, удастся быстрее локализовать источник проблемы, определив сервис. При этом, при наличии ошибке в одном сервисе, система в целом продолжить функционировать, и станет недоступна лишь ее часть.
➕Меньшие издержки на тестирование. Как для регрессионного так и для юнит-тестов, компоненты участвующие в процессе тестирования автономны, что позволяет уменьшить объем тестирования.
❓Минусы микросервисов:
➖ Ассортимент технологических стеков. В виду того, что каждый компоненты такой архитектуры могут быть написаны на разных языках программирования, для разработки и поддержки приложения необходима команда, обладающая более широким набором компетенций.
➖ Сложная стандартизация. Поскольку знания разделены между несколькими командами, и при этом каждая отвечает за свой сервис или набор сервисов, то это приводит к отсутствию единого стандарта разработки и централизованного процесса обновления. С другой стороны, такой подход, за счет наличия нескольких практик в разных командах позволяет выбрать лучший, и адаптировав его, распространить на остальных.
➖ Оркестрация и шардирование. Если мы имеем несколько экземпляров одного сервиса, то чтобы избежать простоя во время обновления, экземпляры сервисов можно обновлять по одному. При этом надо поддерживать старую версию API и настраивать структуру взаимодействия. Если у нас несколько экземпляров одного и того же сервиса, то получается, что у нас есть несколько потребителей сообщений, надо настраивать маршрутизацию таким образом, чтобы, например, все сообщения, относящиеся к одному заказу в интернет-магазине, попадали к одному и тому же экземпляру сервиса.
Что такое «монолит» – так же архитектурный стиль, в котором вся логика выполнения целевого действия выполняется в рамках одного процесса взаимодействия между клиентом, базой данных и сервером.
❓Плюсы монолита:
➕Производительность. Правильно написанный монолит состоит из модулей, которые легко распилить на микросервисы. Сообщение между модулями происходит через память, поэтому оно быстрее, чем например через брокеры.
➕Единый технологический стек. Для разработки и поддержки приложения достаточно иметь команду обладающую схожим набором компетенций, при этом члены команды, легко дополняют и заменяют друг друга. Процессы написания кода и код-ревью выполнять проще, поскольку выполняются они в рамках одного компонента.
➡️ Единая среда данных. Это означает, что каждый компонент системы, имеет физический доступ к данным из единого источника. При этом данные целостны, и нет потребности в их синхронизации. Архитектуру, состоящую из набора микросервисов, имеющих по одному экземпляру и обращающихся к одной централизованной БД нельзя назвать эталоном микросервисной архитектуры, т.к. у приложения в целом появляется единая точка отказа – база данных.
❓Минусы монолита:
➖ Время простоя при обновлении. Даже при минимальных доработках, необходима приостановка работы и пересборка всего монолита или как минимум его серверной части. Если сборка осуществляется в рамках CI/CD, то удастся существенно сократить это время.
➖ Масштабируемость. Речь идет не о том, что монолит нельзя масштабировать. Само масштабирование выполняется по вертикали, за счет увеличения ресурсов используемых приложением в целом. Такой подход, создает сложность при необходимость увеличить производительность одного процесса, т.к. далеко не все приложения позволяют это сделать.
➖ Зависимость компонентов плохо влияет на производительность. Отсутствие возможности выделить ресурсоемкую операцию в отдельный процесс, создает проблемы, при запуске такой операции у всех пользователей системы.
❓Какую архитектуру предпочитают крупные ИТ-компании в России?
Нельзя сказать, что компании предпочитают какой-то из вариантов архитектуры, ввиду того, что каждый вариант применим для решения определенных задача. Так же все зависит от ситуации.
Сценарий 1 .К примеру, компания решила проверить бизнес-гипотезу и разработать какое-то приложение, с последующим выводом на рынок или для собственного использования. Архитектуру этого приложения трудно определить сразу, но при этом есть некоторые ограничения:
🔹нет уверенности в успешности гипотезы
🔹задачи для команды разработки сформулированы расплывчато
🔹существует строгое ограничение по ресурсам и этих ресурсов не много
В таком сценарии компании чаще выбирают монолитную архитектуру, но при этом строят «правильный монолит» ее с учетом того, что дальше этот монолит будет нарезаться на микросервисы.
Сценарий 2. Корпоративные информационные системы. Крупные системы управления предприятием ERP (SAP или 1С) и пр. построены исходя из принципов монолитной архитектуры, либо стремятся к соответствию этим принципам. При этом, внутри одного приложения возможно разделение на модули, каждый из которых выполняет свою бизнес-функцию, но при этом данные для таких систем привязаны к самому приложению и взаимозависимость модулей (Один модуль потребляет данные другого и производит данные для третьего) не позволяет назвать такие модули микросервисами.
При этом, если подняться чуть выше, и представить, что вокруг нашей ERP системы появляется такие решения как: система учета заработной платы, корпоративный портал и сервис электронного документооборота, то эту архитектуру также нельзя назвать микросервисной, т.к. каждый компонент входящий в ее состав является отдельным крупным монолитом, выполняющим целый комплекс бизнес – задач и сервисов.
Сценарий 3. Продуктовая компания, которая занимается разработкой и развитием продукта, являющимся центральным ядром их бизнеса и главным инструментом общения с клиентами. К примеру приложение онлайн-банка или приложение для заказа такси или еды. Ввиду того, что:
🔹понятна бизнес цель разработки данного приложения
🔹возможно определить сложность этого приложения и тех компонентов, которые будут входить в состав
🔹есть бюджет на разработку продукта, и не только на стадию MVP
🔹объем потребителей приложения понятен только примерно и скорее понятен его максимум, но система должна иметь возможность горизонтального масштабирования, ввиду того что мы не знаем динамику, с которой новые пользователи будут добавляться в приложение
🔹надежность и отказоустойчивость важна и архитектура проектируется с учетом этих ограничений
для такого приложения чаще всего используется микросервисная архитектура.