В наши дни я слишком часто читал, что архитектура микросервисов - ненужный и слишком сложный тренд, который компаниям вообще не нужна.

Причины обычно связаны со сложностью, особенно в коммуникации и асинхронности. Заявление о том, что «вашей компании нужны продуктивность и ценность», прислушиваются очень часто.

Действительно ли архитектура микросервисов является шумихой, еще одним поводом для разработчиков узнавать что-то новое, независимо от того, что лучше для компании?

Архитектура микросервисов против подхода монолитной архитектуры

Одна из наиболее распространенных атак на архитектуру микросервисов - по сравнению с монолитной. В первом случае люди ищут сложные вещи, чтобы затем подтвердить, что во втором это проще: микросервисы требуют более сложной инфраструктуры, они обычно зависят от более асинхронного подхода, отображение контекста затруднено, определение домена становится сложным и т. Д.

Но разве эти зависимости архитектуры микросервисов не связаны только с этой архитектурной тенденцией, или они на самом деле являются зависимостями какого-либо хорошего проекта разработки?

Должны ли мы думать, что эти разработчики не используют SOLID в своих монолитах? И, если они не используют SOLID, нет ли у них вообще никаких проблем? Сложно представить.

Итак, когда они говорят, что «архитектура микросервисов требует очень сложной инфраструктуры», разве монолитная инфраструктура не является инфраструктурой микросервисов только для одного микросервиса? Разве автомасштабирование, ведение журнала, очереди или базы данных не подходят для монолитной архитектуры?

Когда мы говорим об асинхронности, разве монолиты не используют очереди для долгоживущих процессов, не используют ли они автоматические выключатели для вызова внешних служб, не используют ли они отображение контекста для отображения информации из монолита в модели домена внешних служб, которые они использовать?

И, ради бога, разве разработчики монолитов не пытаются разобраться в предметной области, чтобы создать хорошее представление о реальных концепциях, задействованных в их бизнесе?

Разрабатывать микросервисы сложно. Создать хороший монолит тоже непросто.

Разрабатывать микросервисы сложно. Поскольку у вас есть много сервисов, которые обмениваются данными между ними и с миром, вам необходимо обеспечить оптимальное взаимодействие.

Сделать это можно двумя способами, по крайней мере, самыми важными:

  • Синхронно: вы просто звоните в сервис и ждете ответа. Что случилось, если приемник не работал? Вам нужно исправить эту ситуацию, и в качестве ответа используется автоматический выключатель.
  • Асинхронно: вы отправляете сообщение в очередь, и один или несколько демонов прослушивают эти сообщения. Вы можете предположить, что в неопределенное время в будущем все будет хорошо. Если ваши сообщения могут выполняться в любом порядке, и они также идемпотентны - они могут выполняться много раз - у вас есть предыдущий сценарий - служба отключена - исправлена, потому что вы можете снова обработать сообщение, когда служба снова заработает или ошибка было исправлено.

Оба случая сложны. В первом вам нужно управлять всеми возможными путями, по которым может прийти пользователь, и давать приемлемый ответ; Кроме того, создайте необходимое, чтобы избежать потери информации при сбое вызова службы. Во втором вам нужно управлять асинхронной операцией, а это означает наличие мониторинга демонов, очередей тупиковых ситуаций и т. Д .; Кроме того, вам необходимо спроектировать платформу для передачи сообщений о выбросах, которые не должны зависеть от какого-либо порядка и которые могут выполняться более одного раза.

Другая горячая тема - отображение контекста. Поскольку микросервис, как таковой, является ограниченным контекстом, вы не можете совместно использовать какой-либо агрегат, VO или что-либо еще с другим микросервисом.

Приведем пример: у вас есть футбольный менеджер. У вас есть игроки, и у вас есть пользователи, которые используют платформу. Допустим, у вас есть два микросервиса: auth и football. В auth у вас есть совокупность пользователей, в которой есть имя, фамилия, имя пользователя, пароль и т. Д. В футболе у ​​вас есть совокупность игроков, в которой есть имя, фамилия, рост, вес, команда и т. Д. Более того, допустим, некоторые игроки иметь доступ к платформе как пользователи. Вы видите это? Имя и фамилия являются общей информацией в обоих микросервисах. Это та самая информация. Вам нужен способ синхронизации информации между обоими микросервисами. И вам нужно сопоставить идентификаторы, чтобы знать, что пользователь с идентификатором 1 является игроком с идентификатором 32 - вы можете использовать те же идентификаторы, чтобы избежать сопоставления контекста, но давайте представим, что это не так. Пример может быть более сложным, с большим количеством микросервисов.

Чтобы управлять такой ситуацией в микросервисах, вы должны инициировать события изменения информации при изменении поля, а затем прослушивать события и обрабатывать их для обновления информации в других микросервисах. Это сложно, и есть некоторые моменты, которые нужно исправить.

Есть и другие сложные вещи, когда вы разрабатываете микросервисы, такие как инфраструктура, которые в наши дни используются как образы докеров в кластере Kubernetes. Но две темы ниже, на мой взгляд, более сложные.

Итак, да, разработать архитектуру микросервисов достаточно сложно. Но…

Наступил 2021 год. Несколько лет назад Манифест« Двенадцати факторов был новинкой, архитектурой, к которой стремилось программное обеспечение. Но, как я уже сказал, это 2021 год, и теперь двенадцать факторов - это минимум.

Даже монолиты теперь взаимодействуют с внешними службами, такими как CRM, системы хранения мультимедиа, API социальных сетей и т. Д. Что происходит, когда мы общаемся с этими службами? То же самое, что я сказал вам ниже. Вам нужно делать это синхронно или асинхронно, с теми же проблемами и теми же решениями. Вам также необходимо сопоставление контекста, чтобы связать ваши агрегаты с агрегатами внешних сервисов. Вам нужно синхронизировать информацию.

Чтобы разработать хорошую архитектуру микросервисов, вам нужны очень хорошие разработчики. Значит нужен хороший монолит. Если мы сравним плохие монолиты с хорошими микросервисами, нам всегда будет легче разрабатывать монолиты.

Итак, что это за шум о микросервисах, вся эта ненависть?

Не будет ли проблема в том, что мы сравниваем очень недоработанные монолиты с микросервисами, поэтому для монолитов нужны многие зависимости архитектуры микросервисов, но они просто проигнорировали это?

Не будет ли проблема в том, что некоторые команды пытаются разработать микросервисы из очень плохого монолита в качестве серебряной пули, но с теми же фактическими знаниями, которые построили неудачный монолит, поэтому они терпят неудачу и обвиняют архитектуру микросервисов?

Создавайте свое программное обеспечение, используя архитектуру, в которой вы хорошо разбираетесь. Ваши знания и способности решат, будет ли результат хорошим или плохим, независимо от выбранной вами архитектуры.