Я исследовал микросервисные архитектуры, пытаясь получить общее представление обо всех плюсах и минусах, когда и почему, и т. Д. Большая часть информации, которую я читаю / смотрю, поступает из ThoughtWorks (Мартин Фаулер, Нил Форд и др.). аль).
Большинству работ Мартина Фаулера по этому вопросу посвящено несколько лет, когда Микросервисы (как общеизвестное имя в программировании, если не в общей практике) были еще молоды, поэтому я беру большую часть этого с недоверием.
Одна вещь, в частности, это:
Когда я слышу истории о командах, использующих архитектуру микросервисов, я заметил общую закономерность.
- Почти все успешные истории микросервисов начались с монолита, который стал слишком большим и был разрушен
- Почти во всех случаях, когда я слышал о системе, которая была построена как микросервисная система с нуля, это привело к серьезным проблемам.
Этот шаблон заставил многих моих коллег утверждать, что вам не следует начинать новый проект с микросервисами, даже если вы уверены, что ваше приложение будет достаточно большим, чтобы оно того стоило. ,
(ссылка: https://martinfowler.com/bliki/MonolithFirst.html - выделите их)
Теперь, спустя 3 года, и когда микросервисы являются более вездесущим термином, можно ли вообще согласиться с тем, что новая система обычно лучше обслуживается благодаря наличию больших (чем микросервис, но меньше, чем монолит) сервисных блоков для начала и созданию они более гранулированы как часть эволюционной меры?
Или есть ли норма начинать проект с нуля с гранулированной микросервисной архитектурой, в отличие от приведенных выше утверждений?
Похоже на здравый общий подход, но любопытно мысли сообщества.
источник
На мой взгляд, может быть полезно сначала разработать монолит (или лучше: разработать части вашего приложения в виде монолита).
Существуют случаи, когда вы не уверены в домене и границах вашей проблемы (например, я создаю сайт управления судном, нужен ли мне сервис судна и сервис флота, или достаточно обслуживания судна?), И в таких случаях Монолит легче освоить.
Вам следует прекратить делать это, если вам нужно объединить различные технологии (например, ваши существующие части написаны на C #, но ваша новая проблема требует машинного обучения, лучше всего с Python), иметь хорошее понимание доменов в вашем проект или ваш монолит гальванизирует, например, каждый просто строит этот монолит и подавляет понятие отдельных услуг.
источник
Я почти уверен, что в этой статье MF было несколько вопросов.
Мой взгляд на это так:
Монолит с проблемами обслуживания или масштабируемости улучшается, разбивая его на микро сервисы. Такой проект почти всегда будет «успешным», поскольку даже разрушение небольшого участка может привести к ощутимым результатам, и вы можете провести черту под ним, когда будете довольны.
Является ли ваша половина монолита + очередь сообщений и пара рабочих процессов засчитываемой как «Микросервисная архитектура», является аргументом для отказа от паба, но вы определенно будете называть это так, когда будете говорить о проекте.
С другой стороны, любой новый проект, независимо от выбранной архитектуры, рискует не соответствовать ожиданиям, поэтому, естественно, вы ожидаете более низкий показатель успеха. Кроме того, если вы начали с того, что хотите создать «Микросервисную архитектуру наилучшей практики» с нуля, вы, возможно, решитесь на новые технологии и более сложные микросервисы.
Также мы должны помнить, что MF пишет с большой точки зрения ООП. Он естественно скептически относится к более современному распределенному подходу.
В наше время я ожидаю, что любое крупное бизнес-решение будет включать в себя элемент микросервисов, и только дурак посоветует вам сделать одно гигантское монолитное приложение, если вы не распространяете одно приложение в стиле настольного компьютера.
источник
Из моего (обширного) опыта я стал свидетелем того, как многие другие проекты проваливаются из-за проблем людей, а не из-за проблем с технологиями. К сожалению, людям не нравится терпеть неудачу, и поэтому они склонны сообщать о причинах неудачи и обвиняют технологию.
В моей области финансы большинство новых проектов в настоящее время используют микросервисные архитектуры, и, похоже, это выигрышная архитектура с точки зрения совокупной стоимости владения (TCO). Похоже, что эти проекты не часто терпят неудачу, и когда они делают указанные причины, не часто перечисляют архитектуру приложения в качестве проблемы.
источник