Последние несколько лет есть волна шумихи, которая пересекает ИТ-выделенные СМИ вперед и назад, растущая больше и больше. И эта волна о микросервисах.
Бесчисленные статьи, сообщения в блоге, видео и слайд -шоу, посвященные микросервисам, как их проектировать или как применять их к существующим приложениям.
Есть также несколько редких публикаций с более трезвым взглядом на микросервисы. Эта статья — моя попытка усилить этот голос мудрости.
Прежде всего: я ничего не имею против микросервисов. Более того, я уверен, что в некоторых случаях они являются совершенно разумным решением. Я так же хорошо знаю, что большинство энтузиастов микросервисов, которые хотят применить этот подход, часто едва понимают все последствия. Это правда, что микросервисы обеспечивают преимущества, но эти преимущества могут быть достигнуты только в определенных условиях. И эти условия Интегральная часть раствора микросервисов.
Примечание о сложности
Это редко упоминается, но, как правило, все понимают, что разработка программного обеспечения является своего рода инженерной деятельностью. И так же, как любая другая инженерная дисциплина, она следует некоторым общим закономерностям и подходам.
По сути, именно поэтому в течение долгого времени использовалась модель разработки водопада: этот подход классического инженера довольно хорошо работает для других инженерных мероприятий.
Но даже самые первые попытки применять подходы к классическому инженерии показали, что, несмотря на все сходства, разработка программного обеспечения значительно отличается от других инженерных дисциплин. И основная точка дифференциации — сложность. Помимо обычной сложности, которая появляется только в том, что существует много «движущихся частей», существует также взаимодействия и зависимости между этими движущимися частями. Взаимодействия и зависимости, которые часто даже трудно учитывать только потому, что мы понятия не имеем о них. Различные уязвимости программного обеспечения часто являются результатами некоторых внутренних взаимодействий или зависимостей, которые не были приняты во внимание.
Таким образом, вся история разработки программного обеспечения — это история войны против сложности. Структурное программирование и ООП, функциональные библиотеки и (очень) языки высокого уровня — лишь немногие примеры попыток справиться с этой сложностью. И как только мы обнаружим какой -либо новый способ уменьшить сложность, мы сразу же используем ее для создания еще более сложных систем, так что эта война никогда не заканчивается.
Вернемся к микросервисам
Давайте посмотрим на микросервисы с точки зрения сложности. Существует два основных фактора сложности строительства системы с микросервисами.
Первым источником сложности является начальная сложность применения. Здесь наступает первый неприятный сюрприз: микросервисы превращают программное обеспечение наизнанку и обнажают все внутренние зависимости и взаимодействия. Это определенно делает каждый конкретный микросервис проще и в то же время делает инфраструктуру намного более сложной.
Вторым источником сложности является (часто забытый) факт, что любая система, построенная с микросервисами, является распределенной системой. И в каждой распределенной системе есть целый пакет проблем, специфичных для распределенных систем, от проблем с подключением до согласованности и распределенных проблем с часами.
Инфраструктура является ключом
Как упомянуто выше, сложности внутреннего приложения перемещается в инфраструктуру после того, как мы начнем использовать микросервисы. Это делает Инфраструктура, неотъемлемая часть приложения Анкет Этот факт не часто упоминается и даже реже четко понимается: для успешного применения микросервисов обязательно иметь хорошее управление инфраструктурой, все эти оркестровки, распределенный мониторинг/регистрацию, синхронизации и т. Д. Там нет места для ярлыков или решений ADHOC. Цена любой ошибки намного выше. А так как есть гораздо больше движущихся частей, вероятность совершения ошибки намного выше. Итак, прежде чем попробовать микросервисы, просто спросите себя, готова ли ваша инфраструктура для них.
Причины (не) применять микросервисы
Прежде всего, есть два совершенно разных случая — новое приложение и существующее приложение.
Для новых приложений использование микросервисов может (или не может иметь преимущества, зависит от многих факторов и знаний о распределенных системах и их проблемах среди основных факторов. Отсутствие установленной инфраструктуры или понимание последствий распределенных приложений приводит к появлению нестабильных систем, которые чрезвычайно трудно поддерживать, разрабатывать и поддерживать. Это компенсирует любые возможные преимущества использования микросервисов.
Для существующих приложений использование микросервисов также редко бывает хорошей идеей. Большинство таких приложений обычно разработаны без учета соответствующих соображений. Это означает, что они:
- не готов жить в распределенной среде
- не ожидайте проблем с подключением при вызове (ранее внутренней) услуги
- Используйте за просмотр или другие долговые транзакции
- Делать другие вещи, которые вполне хороши для монолитного применения.
Попытки перейти на микросервисы для таких приложений обычно заканчиваются Распределенный монолит — Ужасная история для каждого молодого усыновления микросервисов. Это не означает, что использование микросервисов невозможно для таких приложений. Это просто означает, что приложение должно быть подготовлено к изменениям. А во время подготовки вы можете найти другой способ решить существующие проблемы без необходимости ввести микросервисы.
Оригинал: «https://dev.to/siy/don-t-do-microservices-if-you-can-2h0»