Микросервисы: MonolithFirst?

9

Я исследовал микросервисные архитектуры, пытаясь получить общее представление обо всех плюсах и минусах, когда и почему, и т. Д. Большая часть информации, которую я читаю / смотрю, поступает из ThoughtWorks (Мартин Фаулер, Нил Форд и др.). аль).

Большинству работ Мартина Фаулера по этому вопросу посвящено несколько лет, когда Микросервисы (как общеизвестное имя в программировании, если не в общей практике) были еще молоды, поэтому я беру большую часть этого с недоверием.

Одна вещь, в частности, это:

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

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

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

(ссылка: https://martinfowler.com/bliki/MonolithFirst.html - выделите их)

Теперь, спустя 3 года, и когда микросервисы являются более вездесущим термином, можно ли вообще согласиться с тем, что новая система обычно лучше обслуживается благодаря наличию больших (чем микросервис, но меньше, чем монолит) сервисных блоков для начала и созданию они более гранулированы как часть эволюционной меры?

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

Похоже на здравый общий подход, но любопытно мысли сообщества.

jleach
источник

Ответы:

2

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

Для нового кода, в котором вы не уверены, где должна быть граница, соберите его в одном сервисе. Если вы сохраняете его модульным, вы можете по мере необходимости отделять от него микросервисы. Особенно когда вы находите части своего сервиса, которые должны масштабироваться иначе, чем остальные.

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

В основном:

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

Слишком часто мы слышим полезные советы от умных людей с хорошей репутацией, таких как Мартин Фаулер, а затем превращаем их в жесткую доктрину, от которой никак нельзя отказаться.

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

Берин Лорич
источник
13

Наиболее важные преимущества микросервисов могут быть достигнуты простой модуляризацией кода. Вы можете изолировать группы функций в модули, используя любую имеющуюся систему модулей (maven, npm, nuget и т. Д.). Каждый модуль может служить одной цели: иметь собственный репозиторий, использовать собственную схему БД, управлять собственной конфигурацией, иметь собственный список невыполненных функций и график выпуска. Они все еще могут быть развернуты вместе на монолит. Это очень управляемое количество накладных расходов и дает некоторые хорошие преимущества. Большие накладные расходы связаны с разделением развертываний, что очень ценно только тогда, когда у вас достаточно масштаба, чтобы это потребовалось. Если ваш код уже является модульным, тогда будет легче выполнить миграцию, когда придет время.

Jiggy
источник
Похоже, что это хорошая практика общего кодирования, смешанная с небольшим улучшенным управлением кодовой базой, но она не соответствует пути «не нужно обновлять весь монолит при незначительном обновлении службы», что, как я ожидаю, имеет тенденцию к микросервисам. сиять. В любом случае, хороший совет, спасибо.
jleach
1
Полностью согласен с ответом. Хорошо построенный и правильно модульный монолит обеспечивает большинство (хотя и не все) преимуществ, которые имеют микросервисы. С другой стороны, у микросервисов есть свои довольно большие проблемы.
Милош Мрдович
@jleach Одним из качеств хорошей модульности является независимое развертывание. Если вам нужно перекомпилировать и заново развернуть весь монолит, чтобы выполнить незначительное обновление модуля, вы делаете что-то не так.
Милош Мрдович
2
Это хороший подход. Не создавайте микросервис ради того, чтобы заниматься микросервисом. Микросервисная архитектура должна использоваться для решения проблем, но они также поставляются с набором собственных проблем, поэтому, если вы не готовы / не знаете об этих компромиссах, вы должны быть очень осторожны при разработке микросервиса с нуля.
Ли Райан
1
@MilosMrdovic, даже с модульным подходом, вы все равно можете получить некоторую эффективность в развертывании, поскольку вам не нужно повторно тестировать весь монолит, только модуль, который вы обновляете. Если ваш модуль прошел все качественные ворота, вы можете построить и отправить его. Тогда вашему монолиту просто нужно обновить версию зависимости и заново развернуть. Вам не нужно будет перестраивать любые другие модули.
Джигги
2

На мой взгляд, может быть полезно сначала разработать монолит (или лучше: разработать части вашего приложения в виде монолита).

Существуют случаи, когда вы не уверены в домене и границах вашей проблемы (например, я создаю сайт управления судном, нужен ли мне сервис судна и сервис флота, или достаточно обслуживания судна?), И в таких случаях Монолит легче освоить.

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

Кристиан Зауэр
источник
1
«И в таких случаях микросервис может быть проще в разработке» - вы имели в виду говорить о монолитах там?
Амон
@amon Спасибо, я исправил предложение - мой сын перебивал меня 34235 раз, поэтому я был сбит с толку;)
Кристиан Сауэр
Хотя я согласен с вашим первым предложением, я думаю, вы должны учитывать, что даже ваш монолит уже должен быть «модульным» внутри, иначе вы просто не сможете отделить что-либо, не упав все.
Вальфрат
@ Walfrat Я склонен согласиться, но соблазн повторно использовать существующий код гораздо больше (и не так легко подавить) в монолите. Например, «о, смотрите, кто-то определил WidgetId, я просто буду использовать его для моего FormId»: Кроме того, вы не можете легко использовать другой язык / db для проекта, который действительно стимулирует мышление «все должны использовать общие инструменты»
Christian Sauer
1

Я почти уверен, что в этой статье MF было несколько вопросов.

Мой взгляд на это так:

Монолит с проблемами обслуживания или масштабируемости улучшается, разбивая его на микро сервисы. Такой проект почти всегда будет «успешным», поскольку даже разрушение небольшого участка может привести к ощутимым результатам, и вы можете провести черту под ним, когда будете довольны.

Является ли ваша половина монолита + очередь сообщений и пара рабочих процессов засчитываемой как «Микросервисная архитектура», является аргументом для отказа от паба, но вы определенно будете называть это так, когда будете говорить о проекте.

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

Также мы должны помнить, что MF пишет с большой точки зрения ООП. Он естественно скептически относится к более современному распределенному подходу.

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

Ewan
источник
Спасибо. Если MF имеет тенденцию быть слегка предвзятым, есть ли кто-то, чью работу я могу изучать на противоположной стороне, чтобы помочь получить глубину перспективы?
августа
Я бы не рекомендовал «веб-знаменитостей» в качестве учебного ресурса. Это хорошо для нескольких анекдотов и забавного разговора, но по моему опыту это детали, которые имеют все значение между успехом и провалом.
Эван
0

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

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

Программист
источник
Микросервисы действительно решают множество организационных проблем. Если у каждого сервиса есть владелец, то вы знаете, как подавиться, когда что-то не работает.
Джигги
@jiggy: если код хорошо модульный, вам не обязательно разбивать его на несколько служб, чтобы знать, кого задушить.
Ли Райан
@ Райан, если кто-то думает, что микросервисы и модульность являются синонимами, то они полностью упустили суть.
Инженер-программист,