Монолит

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

Тем не менее, он имеет тенденцию перерастать сам себя и становиться скорее болью, чем решением. Некоторые из этих болей:

  • Мы все работаем над одним и тем же кодом, и начинают возникать конфликты и побочные эффекты.
  • Вам нужно выпустить все решение, даже если у разных команд разные циклы.
  • Есть зависания кода для прохождения циклов проверки.
  • Он масштабируется в целом, а не только в той части, в которой увеличивается трафик.

Из-за этих болей и были созданы микросервисы. Предоставление независимости команде/домену для создания целенаправленных решений для уже проверенного бизнеса.

Микросервисы

Начнем с определения микросервиса:

Микрослужбы – это архитектурный и организационный подход к разработке программного обеспечения, при котором программное обеспечение состоит из небольших независимых служб, взаимодействующих через четко определенные API. Эти сервисы принадлежат небольшим автономным командам.

Все звучит как цветы и счастье, когда мы говорим о микросервисе. Тем не менее микросервисы сами по себе решают весь вопрос?

Сталкивались ли вы со следующими случаями в микросервисной архитектуре?

  • Прежде чем мы выпустим новую версию, нам нужно синхронизировать развертывание с другой командой.
  • Наше приложение было отключено, но это не наша проблема.
  • Наш сервис работал и масштабировался до тех пор, пока нас не начала использовать команда X.
  • И более…

Что происходит?

Микролиты

Упомянутые выше запахи вызваны тем, что Джонас Бонер называет микролитами, отличное слово для того, что здесь происходит.

Даже если мы думаем, что это «независимые» сервисы, синхронная связь может вызвать побочные эффекты, которые нам не нужны:

  • Между вашими службами могут быть каскадные события.
  • Границы вашего домена не ясны, потому что вы не владеете всем процессом.
  • Медленные сервисы вынуждены масштабироваться из-за требований к более быстрым сервисам.
  • При сетевых вызовах возникает дополнительная задержка.

Что потерялось при переводе?

Наличие микролитов происходит из множества заблуждений, которые у нас есть. Некоторые из них:

Домены != Ресурсы

Время от времени, когда мы делим монолит, мы думаем о доменах как о ресурсах. Из-за того, как мы обычно разделяем API и БД, мы думаем о разделении того, что уже существует, а не об извлечении достигнутых процессов.

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

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

Независимость != Единый источник

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

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

Быстро!= Синхронно

Люди думают, что прямой ответ всегда быстрее, чем отправка сообщения. Хотя иногда это действительно так, в микросервисах это может запускать каскад синхронных вызовов от одного сервиса к другому, оставляя наших пользователей в подвешенном состоянии по тайм-ауту.

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

Устойчивость != Полная

Убедиться, что весь процесс завершен, обычно путают с отказоустойчивостью. Устойчивость относится только к способности завершить процесс.

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

Заключение и последующие действия

Мы обречены?

Ответ - нет, мы не обречены! Мы можем проектировать наши сервисы с правильным разделением, используя некоторые инструменты DDD, а также использовать правильные инструменты для разделения наших микросервисов.

Давайте поговорим об этом в следующих главах этой серии.

Первоначально опубликовано на https://dev.to 4 сентября 2022 г.