Иллюстрация @alvaro_sanchez Какое-то время все были без ума от микросервисов.
Невозможно было открыть любимый новостной агрегатор и не увидеть некую доселе неизвестную компанию, рассказывающую о спасении своего инженерного отдела с помощью микросервисов.
Возможно, вы даже работали в компании, которая была охвачена ажиотажем вокруг крошечных, волшебных сервисов, которые могли бы решить все проблемы большой, заброшенной устаревшей базы кода.
Естественно, на деле все оказалось совсем наоборот. Когда вы оглядываетесь назад на то, что произошло, ваше видение ближе к 100%, чем когда вы смотрите с надеждой в будущее.
Я хочу поговорить о некоторых важных заблуждениях и ловушках движения микросервисов с точки зрения человека, который работал в компании, убежденной в целительной силе микросервисов.
Я не хочу, чтобы вывод из этой статьи был «микросервисы == плохо», но в идеале я хотел бы, чтобы вы подумали о проблемах при принятии решения, подходит ли вам архитектура микросервисов.
Что вообще такое «микросервис»?
Идеального определения не существует, но люди, продвигающие эту область, смогли описать хороший набор требований к системе, который бы квалифицировал ее как «микросервисную» архитектуру.Можно сказать, что это не монолит. На практике это означает, что микросервис работает только с небольшой, максимально ограниченной областью задач.
Он выполняет минимум функций для достижения конкретной цели в вашем стеке.
Вот более конкретный пример: допустим, в банке есть «Служба входа в систему», и вы определенно не хотите, чтобы эта служба имела доступ к финансовым транзакциям ваших клиентов.
Вы переместите эту область в некую «Службу транзакций» (имейте в виду — имена давать очень сложно).
Кроме того, люди часто подразумевают, что микросервисы должны взаимодействовать с другими сервисами удаленно.
Поскольку они являются независимыми процессами и часто выполняются далеко от других, обычно такие процессы взаимодействуют друг с другом по сети с использованием REST или какого-либо другого протокола RPC. Пока что все кажется достаточно простым — нужно просто обернуть небольшие кусочки системы в какой-нибудь REST API, и дать возможность всем общаться друг с другом по сети.
По моему опыту, есть 5 «истин», которые, по мнению людей, не всегда верны:
- Код станет чище
- Проще писать модули, решающие одну задачу
- Работает быстрее монолита
- Инженерам будет проще, если им не придется работать с единой кодовой базой.
- Это самый простой способ добиться автоматического масштабирования, и здесь где-то задействован Docker.
Заблуждение №1: Чистый код
«Вам не нужно добавлять ограничение на сеть, чтобы оправдать написание лучшего кода».Дело в том, что ни микросервисы, ни какой-либо другой подход к моделированию технологического стека не являются обязательными для написания более чистого и удобного в обслуживании кода.
Конечно, поскольку движущихся частей становится меньше, снижается возможность писать ленивый и непродуманный код. Но это все равно, что сказать, что кражу можно остановить, убрав товар с витрин магазинов.
Вы не решили проблему, просто удалили множество функций.
Популярный подход заключается в построении архитектуры таким образом, чтобы логические «сервисы» владели частями домена.
Это похоже на концепцию микросервисов, поскольку зависимости, управляющие системой, будут явными.
И бизнес-логика не разойдется по разным углам.
Кроме того, этот подход не приводит к чрезмерному использованию сети и возможным проблемам, связанным с этим.
Еще одним преимуществом этого подхода является то, что он напоминает сервис-ориентированную архитектуру, построенную поверх микросервисов: если вы решили перейти на микросервисы, то большая часть работы уже проделана, и вы, скорее всего, уже хорошо разбираетесь в предметной области.
правильно разделить его части.
Настоящая SOA начинается с кода и со временем продолжается через топологию физического стека.
Заблуждение №2: Это проще
«Распределенные транзакции никогда не были проще» На первый взгляд это может выглядеть по-другому, но большинство доменов (особенно в новых компаниях, которым приходится много раз создавать прототипы, поворачивать и вообще переопределять домен) не могут быть разделены на аккуратные, аккуратные коробки.Часто произвольной части системы для корректной работы необходимо получить данные о другой части.
Все становится еще сложнее, когда он делегирует операцию записи данных другой части, находящейся за пределами ее домена.
Когда вы вышли за пределы своей зоны влияния и вам необходимо использовать другие части для хранения или изменения данных, то вы въехали в страну распределенные транзакции .
Когда в одном запросе участвуют несколько удаленных сервисов, сложность значительно возрастает. Можно ли обращаться к ним параллельно или к ним нужно обращаться последовательно? Знаете ли вы заранее все возможные ошибки (на уровне приложения) И на сетевом уровне), которые могут возникнуть в любой момент, на любом участке цепочки, и что эти ошибки будут означать для самого запроса? Зачастую каждая из распределенных транзакций требует разного подхода к обработке ошибок.
А понять все ошибки и понять, как их решить – это очень и очень большая работа.
Заблуждение №3: Это быстрее
«Вы можете значительно улучшить производительность монолита, если добавите немного дисциплины».Это заблуждение сложно опровергнуть, поскольку в действительности мы часто можем ускорить работу отдельной системы, если уменьшим количество задач или количество загружаемых зависимостей и так далее.
Но в целом это не систематические доказательства.
Я не сомневаюсь, что если бы вы перешли на микросервисы, код, изолированный в этих сервисах, мог бы ускориться, но не стоит забывать и о задержках, появляющихся из-за сетевых запросов.
Сеть никогда не бывает такой быстрой, как внутренняя связь, иногда она «достаточно быстрая».
Кроме того, многие истории о повышении производительности на самом деле связаны с преимуществами нового языка или целого технологического стека, а не только с архитектурой микросервисов.
Если вы перепишете старое приложение Ruby on Rails, Django или NodeJS на новом языке, таком как Scala и Go (два популярных варианта для микросервисных архитектур), производительность улучшится, хотя бы из-за повышения производительности новых технологий в целом.
Но этим языкам на самом деле все равно, если вы назовете их процессы «микро».
Они быстрее из-за простых факторов, таких как компиляция.
Кроме того, в большинстве запускаемых приложений чистая производительность ЦП и памяти почти никогда не является проблемой.
Обычно проблема заключается в вводе-выводе, а дополнительные сетевые вызовы только увеличивают объем ввода-вывода.
Заблуждение № 4: Лучше для инженеров
Когда многие инженеры работают в изолированных кодовых базах, возникает синдром «это не моя проблема».Может показаться, что когда небольшие команды работают над маленькими кусочками головоломки, все становится проще.
Но в конечном итоге такая конфигурация может привести к проблемам.
Самая большая проблема — необходимость запуска постоянно растущего количества сервисов для любого, даже самого маленького изменения.
То есть вам нужно вкладывать время и силы в создание и поддержку системы, в которой каждый инженер может запускать все локально.
Такие вещи, как Docker, могут упростить эту задачу, но кому-то все равно придется поддерживать конфигурацию на протяжении всего срока существования проекта.
Кроме того, это усложняет написание тестов.
Чтобы написать хороший набор интеграционных тестов, нужно понимать все сервисы, связанные с той или иной операцией, учитывать все возможные ошибки и так далее.
Понимание системы займет больше времени, чем ее разработка.
Хотя я бы никогда не сказал инженеру, что понимание системы — это пустая трата времени, я хочу предостеречь его от преждевременного усложнения.
Наконец, такая конфигурация создает социальные проблемы.
Баги могут жить одновременно в нескольких сервисах и требовать изменений на уровне нескольких команд. Им необходимо синхронизировать и координировать усилия.
Кроме того, люди могут потерять чувство ответственности и попытаться переложить как можно больше проблем на другую команду.
Когда инженеры работают вместе над одной базой кода, их понимание системы растет вместе с пониманием друг друга.
Они скорее будут работать вместе над решением проблем, чем быть королями и королевами маленьких изолированных княжеств.
Заблуждение №5: Оно лучше масштабируется
«Микросервис можно масштабировать вширь, как монолит» Упаковка сервисов в отдельные блоки и их масштабирование с помощью, скажем, Docker — это, без сомнения, хороший подход для горизонтального масштабирования.Однако это можно сделать не только с помощью микросервисов.
Подход работает и в случае монолитных приложений.
Вы можете создавать логические монолитные кластеры, обрабатывающие часть трафика.
Например, входящие запросы API, интерфейс информационной панели и фоновые задачи могут находиться в одной базе кода, но не каждому компьютеру необходимо обрабатывать все три типа запросов.
Преимущество здесь такое же, как и в случае с микросервисами: отдельные кластеры можно настроить в зависимости от нагрузки и индивидуально масштабировать для реагирования на пики трафика.
Архитектура микросервисов поощряет такой подход с самого начала, но ничто не мешает вам использовать тот же метод для масштабирования монолитного стека.
Когда использовать микросервисы
«Когда вы, как инженерная организация, будете готовы».Я хочу закончить эту статью обсуждением того, когда настало подходящее время для перехода на микросервисы (или, если вы уже начали, как узнать, подходящее ли сейчас время).
Самое важное на пути к хорошей, работающей микросервисной архитектуре — это простое понимание своей предметной области.
Если вы этого не понимаете или все еще пытаетесь понять, микросервисы принесут больше проблем, чем решений.
Но если у вас уже есть глубокое понимание, то вы знакомы с границами и зависимостями, и подход на основе микросервисов может быть правильным шагом.
Еще одним важным фактором является ваша рабочая среда, особенно то, как она будет выглядеть в контексте распределенных транзакций.
Если вы знаете пути каждой категории запросов в системе и понимаете, где, как и почему эти пути могут сломаться, то вы сможете построить распределенную модель обработки запросов.
Помимо понимания окружающей среды, есть тема мониторинг среда.
Это выходит за рамки споров о микросервисах и монолитах, но мониторинг должен лежать в основе инженерных усилий.
Вероятно, вам понадобится много информации о различных частях системы, чтобы понять, почему одна часть ведет себя плохо или даже генерирует ошибки.
Если у вас есть налаженная система мониторинга компонентов системы, то вы сможете понять поведение системы при горизонтальном масштабировании.
И, наконец, если вы действительно сможете продемонстрировать ценность для своей инженерной организации и бизнеса в целом, то переход к микросервисам поможет вам расти, масштабироваться и зарабатывать деньги.
Конечно, строить интересные системы и пробовать новое — это круто, но, в конце концов, в любой компании есть самый главный показатель.
Если вам придется отложить выпуск новой функции, которая принесет компании деньги, из-за поста в блоге о том, что «монолиты — это плохо», то вам придется обосновать это решение.
Иногда это того стоит. Иногда нет. Знание того, когда нужно действовать и не торопиться, поможет вашей репутации в долгосрочной перспективе.
Выводы
Надеюсь, теперь у вас есть набор условий и вопросов, которые необходимо решить, если кто-то предложит микросервисный подход. Как я сказал вначале, моей целью не было доказать, что «микросервисы — это плохо».Но переходить к микросервисам, не задумываясь обо всех возможных деталях и проблемах, — значит напрашиваться на проблемы в будущем.
Если вы спросите моего совета, я бы посмотрел на «внутренние» сервисы, основанные на чистых, четко определенных модулях в коде.
Их уже в будущем можно будет перевести на реальные услуги, если возникнет такая необходимость.
Этот подход не единственно возможный и уж точно не панацея от плохого кода.
Но это поможет вам двигаться вперед быстрее, чем если бы вы углубились в микросервисы раньше, чем это понадобится.
Теги: #микросервис #монолит #архитектура #приложение #веб-приложение #разработка #программирование #Системный анализ и проектирование #Микросервисы
-
Новый Ноутбук Vaio X От Sony
19 Oct, 24 -
Формула Идеальной Команды
19 Oct, 24 -
Hbo Запускает Онлайн-Сервис Hbo On Broadband
19 Oct, 24 -
Матрица: Тело Как Источник Энергии
19 Oct, 24 -
Nexus Q И Аксессуары Для Nexus
19 Oct, 24 -
Многоязычные Кайны
19 Oct, 24
