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

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

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

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

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

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

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

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

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

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

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

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

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

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

В основном:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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