Наконец-то ты это сделал! Вы думали об этом побочном проекте, который потенциально может стать единорогом, и считаете, что у вас есть навыки, чтобы воплотить этот проект в жизнь. Затем, проводя свое исследование, вы внезапно слышите о том, как компании переходят от монолитной архитектуры к микросервисной архитектуре. Вы не понимаете, что это за модные слова. Вы инстинктивно и мудро посмотрели, что такое микросервисная архитектура, и научились ее создавать. Но теперь вы натолкнулись на название этой статьи и запутались еще больше, потому что считали, что создание проекта с использованием микросервисной архитектуры - хорошая идея.
Если вы не тот человек, которого я описал во введении, не волнуйтесь. Я не жду никого, но если да, то привет! Нам, вероятно, следует подружиться, и вот почему создание микросервисной архитектуры может быть не очень хорошей идеей.
АЙП ЗА АРХИТЕКТУРОЙ МИКРОСЕРВИСА
Многие компании переходят на микросервисные архитектуры, и на это есть веские причины. Представьте, что вы хотите создать бизнес электронной коммерции, который хочет масштабироваться до луны, позвольте позвонить DogeCommerce. Вам нужно будет добавить аутентификацию пользователя, профиль клиента, списки продуктов и платежное решение (PayPal, Paystack). Вы можете создать приложение в едином репозитории кода, где есть все функции, и разместить его на AWS (веб-сервисы Amazon), и бум, оно прошло IPO на миллиард долларов, поздравляем! То, что вы построили, является примером монолитной архитектуры, где все функции и код имеют единую кодовую базу, работающую в единой базе данных.
Архитектура может показаться идеальной, и по большей части это так! Один мудрый человек однажды сказал, что лучшим решением зачастую является простейшее, что применимо и здесь, но микросервисная архитектура была бы не лучшим решением, если бы монолитная конструкция не имела некоторых недостатков. Во-первых, с монолитным дизайном развертывание новых функций похоже на попытку доставить все продукты из автомобиля сразу. Вы могли бы подумать, что это хорошая идея, пока пластиковый ремешок не откажется, и у вас не возникнут серьезные проблемы, и вы бы посмотрели свое заявление в пятницу вечером, например:
Единая точка отказа преобладает в монолитных проектах, поэтому для отказа всего сервера требуется одна функция, которая остановит связь с клиентом. Именно здесь на помощь приходит микросервисная архитектура. Она дает вам больше рук при переноске продуктов. Микросервисы - это архитектурный подход к созданию высокомасштабируемых и обслуживаемых приложений, которые позволяют компаниям быстрее поставлять продукты и быть конкурентоспособными. Перерыв в производственной группе не приведет к краху всего приложения из-за того, насколько оно слабо связано.
У микросервисов есть крошечные базы данных, в которых клиенты подключены к различным устройствам. Такой подход дает компаниям множество преимуществ, особенно при приеме на работу новых сотрудников. Им не пришлось бы тратить время на попытки понять, как работать со всей кодовой базой и только с назначенной им функцией. Параллельная разработка также более управляема. Компании могут отслеживать объем нагрузки, которую берет на себя конкретная функция, и увеличивать или уменьшать ее наиболее экономичным способом, в отличие от монолитной конструкции, которая представляет собой простой подход. Итак, со всеми этими преимуществами, почему бы мне не создать побочный проект стоимостью в миллиард долларов с помощью микросервиса? Прежде чем я перейду к этому, я должен развеять некоторые слухи о конструкции монолита.
«! ВСЕ КЛИЕНТЫ ПОДКЛЮЧЕНЫ К ОДНОЙ МАШИНЕ»
Идея о том, что все клиенты должны подключаться к одной машине, подразумевает, что с монолитами возможно только вертикальное масштабирование, что неверно. Монолиты также могут масштабироваться по горизонтали.
ПОЧЕМУ НЕОБХОДИМО ДЕЙСТВИТЕЛЬНО СЛЕДУЕТ ДИЗАЙНОМ СТАРЫХ МОНОЛИТОВ
Большинство преимуществ микросервисов перед монолитами - это работа с большими командами и игра с нулевой суммой при запуске. Микросервисы нужны тогда, когда команда стремительно растет, а не когда это делают пользователи. Попытки создать микросервис для вашего приложения, когда над ним работают только два человека, расточительны и глупы, потому что они будут дублировать много кода для запуска тестов и подключений. Это также приводит к появлению множества движущихся частей в уравнении, о которых нужно беспокоиться, и это не жизнеспособно для небольшой команды. Создание микросервиса также требует умелых рук, если только вы не рискуете написать антипаттерны, которые работают против всего, что вы пытаетесь достичь.
Спасибо за чтение! Если вам понравилась эта статья, подумайте о том, чтобы дать ей аплодисменты и подписаться на меня в Twitter (twitter.com/theisaac3n)
