Микросервисы? Почему бы нет!
20 декабря 2022 г.Недавно мне задали провокационный вопрос — какие минусы микросервисной архитектуры вы можете назвать? Поначалу я был удивлен, так как этот вездесущий архитектурный подход в наши дни стал чуть ли не золотым стандартом. Я бы ожидал более логического вопроса: «Почему мы их используем?» или «Каковы преимущества использования микросервисной архитектуры вместо монолита?». Сегодня я хочу рассказать о затратах на разработку дизайна микросервиса, которые полезно понимать и помнить.
Это примеры использования, когда стоит дважды подумать, стоит ли использовать микросервисы:
- Вы не хотите тратить на это слишком много ресурсов
- Вы стремитесь к быстрой начальной загрузке продукта.
- Вы рассматриваете возможность разделения серверной части на микросервисы.
- У вас уже есть микросервисная архитектура, но вы не полностью понимаете ее ограничения и последствия.
Добавление забавной (даментальной) сложности
Основной аспект среды микрослужб заключается в том, что это распределенная система. Когда мы разделим наш монолит на множество частей, мы должны начать думать о непротиворечивости данных. Запрос, который делает пользователь, теперь может обновлять информацию более чем в одной базе данных. В монолите у нас есть транзакция, которую можно откатить. Точно так же с микросервисами нам может потребоваться откатить изменение в нескольких сервисах. Существует множество шаблонов для обработки проблем согласованности, но вся тема потребует много размышлений, если вы сталкиваетесь с ней впервые. Например, вы можете захотеть просмотреть распределенные транзакции, шаблон саги, шаблон исходящих сообщений или многое другое. Эта конкретная тема критична и вовсе не тривиальна. Вы можете в конце концов прочитать о теореме CAP и задаться вопросом, что вы хотели сделать в первую очередь, что потребовало такой сложности.
Стоимость процесса разработки
Наличие распределенной системы создает для нас другие препятствия. Надежность кластера служб, сложная трассировка ошибок и разнородная среда программирования дополняют усилия по разработке.
Представьте себе цепочку сервисов, общающихся друг с другом. В какой-то момент в сети между ними возникнут проблемы, или один сервис выйдет из строя или будет принудительно перезапущен для увеличения или уменьшения масштаба. В результате нам нужно инструментировать повторные попытки кода и экспоненциальные отсрочки.
Чтобы эффективно обрабатывать ошибки в рабочей среде, нам необходимо будет внедрить в наш набор сервисов такие функции, как мониторинг, метрики и агрегирование журналов. С монолитом у нас могут быть только возможные состояния - он либо сломан, либо нет. При наборе услуг сотни комбинаций могут привести к полному или частичному отказу всей системы.
Все мы знаем, как утомительно иногда бывает найти ошибку. Поскольку кодовая база равномерно распределена по нескольким службам, автоматические переходы кода и подсказки, показывающие использование метода, отсутствуют. Отсутствие этого инструмента усложняет отладку и, следовательно, требует больше времени для исследования.
Еще одна потенциальная стоимость микросервисной архитектуры — обслуживание. Время от времени нам нужно будет создавать новые сервисы и выяснять, как включить их в существующую систему. На проектирование и координацию всего уходит больше времени, и в конечном итоге вам может потребоваться гораздо больше усилий по обслуживанию, чем ожидалось. Например, вы можете попробовать новую технологию или язык с новым сервисом, что само по себе хорошо, но другим разработчикам также неудобно изучать его. Службы начальной загрузки могут стать новой задачей, и для адаптации потребуется время.
И последнее, но не менее важное: мы говорим о микросервисах, связанных с умножением запросов и временем выполнения бизнес-потока. Замена межпроцессных вызовов сетевыми может привести к критической задержке на каждый вызов приложения. Это приемлемо для большинства служб, но имейте в виду, что иногда это может иметь решающее значение.
Стоимость инфраструктуры и процессов
Затраты на обслуживание также сказываются на развертывании и организации служб. Компании, использующие микросервисы, часто перенимают культуру DevOps или нанимают отдельных сотрудников.
Как я уже говорил, если вы помогли себе с агрегированием и отслеживанием журналов, вы могли бы быть спасены. Но в редких случаях даже это не поможет, потому что изменения, которые нам нужно применить, выходят за рамки нашей ответственности. В монолите вы бы проследили за кодом в разных модулях, поняли бы хотя бы путь кода, а затем смогли бы решить, нужно ли вам связываться с аналитиком или другим разработчиком. При отсутствии такой возможности вы можете только надеяться, что у другой команды найдутся время и ресурсы для вас.
Не только это, но мы также должны держать всех в контексте того, что происходит за рамками нашей команды. С появлением новых служб и отделов растут и расходы на связь. И вот тогда понимание того, что мы делаем, ослабевает. Мы постепенно начинаем терять поверхность контакта с продуктом и берем на себя ответственность лишь за крошечную часть системы.
Представим, что у нас есть приложение, содержащее различные микросервисы, и мы хотим добавить новую интересную функцию. Во-первых, нам нужно либо создать новый микросервис, либо добавить часть в существующий. Для простоты мы собираемся добавить его в существующий микросервис. Мы должны просмотреть наши спецификации API и определить правильное место и формат для нового метода. Нам также нужно будет добавить сквозную поддержку нашей функции во все службы, которые взаимодействуют с той, которую мы будем модифицировать. Это может быть обновление базы данных или дополнительная логика для обработки новых событий, или нам может потребоваться добавить набор новых сущностей в нашу систему. На этом раннем этапе мы должны думать о новых функциях, влияющих на набор сервисов, а не просто добавлять несколько строк кода в существующий сервис. Вместо того, чтобы иметь систему с простым подходом к новым функциям, теперь есть головная боль шагов интеграции.
Заключение
Подводя итог, можно сказать, что затраты и усилия, связанные с поддержкой микросервисов, растут в геометрической прогрессии. Как разработчики, мы могли бы предпочесть, чтобы наши системы оставались небольшими и гибкими, а не распределенной скоординированной сети, где ни один человек не имеет в виду всю картину. Тот факт, что нам приходится иметь дело со всеми обсуждаемыми препятствиями, не только демотивирует и блокирует нас всеми возможными способами, но и заставляет нас больше сосредоточиться на дополнительной сложности, а не на внутренней ценности для бизнеса.
Спасибо за чтение и удачного кодирования!
Оригинал