В результате у сервис-ориентированной архитектуры появился отдельный подтип, который стал развиваться параллельно – микросервисная архитектура. Особенности микросервисной архитектуры становятся очевидными в сравнении с двумя другими популярными типами архитектуры – монолитной и сервис-ориентированной. Поэтому начнем мы с разбора преимуществ и недостатков этих подходов, а затем вернемся к микросервисам. С микросервисами можно легко управлять масштабом и нагрузкой. Если нужно нарастить производительность конкретного модуля, можно выдать ему больше мощностей или запустить еще один экземпляр процесса.
При этом микросервисная система имеет симметричную, одноранговую, а не иерархическую организацию, что снимает необходимость в сложной организации взаимосвязей. Сервисы связываются между собой и с клиентами с использованием лёгких протоколов, например, через HTTP или текстовыми сообщениями. В результате создаётся система, простая в развёртывании и модернизации с функциями автоматической разработки и обновления. В статье, подготовленной для TAdviser, журналист Олег Нечай рассказывает о ключевых особенностях, преимуществах, инструментах и сложностях микросервисного подхода.
Кому подойдёт использование микросервисной архитектурыКому подойдёт использование микросервисной архитектуры
Такие запросы получаются, например, когда Битриксу надо сформировать страницу списка кроватей из 120 тысяч SKU. Или при фильтрации, когда по свойствам надо сформировать и вывести нужные карточки товаров. Помимо свойств товаров, запрос должен учитывать ещё и их изображения. Какую именно картинку для товара выводить, заказчик задает через отдельное свойство-флаг.
Кроме того, каждый модуль можно строить индивидуально с использованием оптимальных средств разработки. Основная концепция архитектуры в том, чтобы разделить сложное приложение на несколько https://deveducation.com/ небольших автономных и управляемых компонентов. Это позволяет повысить гибкость разработки, сократить time-to-market, улучшить отказоустойчивость и облегчить поддержку приложения.
Пример микросервисной архитектуры
В результате монолитные приложения становится сложнее поддерживать, не говоря уже о том, чтобы их структуру и логику полностью понимали разработчики, работающие над ними. Монолитное приложение легко разрабатывать, тестировать и развертывать. После развертывания вы просто настраиваете его с учетом текущих требований. Архитектура должна быть полноценно запущена и отлажена на первичной стадии.
- Каждый микросервис – это небольшая монолитная программа, которая выполняет свою функцию.
- Также может использоваться для тестирования микросервисов.
- Микросервисная архитектура приложения становится все более востребованной.
- В большинстве случаев разработчики используют для этих целей Docker.
- Зачастую эти функции очень разные, и если создать такое приложение в монолите, работать с ним будет очень тяжело.
- Это удобнее, чем монолит, где нельзя выдать больше ресурсов только одному компоненту — нужно давать их системе в целом.
И сроки подстройки пропорциональны размерам и сложности приложения. В монолитных приложениях команды обычно структурируются в соответствии с их индивидуальными функциями, такими как интерфейс, бэкэнд или базы данных. Когда делается запрос, который затрагивает все эти команды, работа над результирующими проектами может отнять много времени, потому что задачи должны быть разделены между несколькими разными членами команды. Крупное приложение может быть воспринято как черный ящик, за который никто не хочет брать на себя ответственность. Из-за невозможности четкого распределения на зоны ответственности у отдельных разработчиков может возникнуть нежелание работы с приложением, построенным на монолитной архитектуре. Например, доступ к документам, формируемым в рамках взаимодействия компании с поставщиками, потребителями или в рамках организации взаимодействия между сотрудниками.
Простым языком о микросервисной архитектуре для начинающих
Специалисты HHI быстро и качественно проведут тестирование и внедрение. Это позволяет в короткие сроки реализовать крупные программные продукты. Независимая эволюция подсистем дает возможность совершенствовать продукт, не изменяя при этом его сути. У нас есть собственный продукт, разработкой которого занимается отдельная команда – SingularityApp, планировщик дел и задач. Он состоит из множества различных решений для пользователей, которых становится все больше – новые фичи добавляются несколько раз в месяц. Микросервисы удобно реализуются при разработке на фреймворках – мы любим Laravel, Symfony – тоже ок.
Простыми словами – вы берете тяжелый и неповоротливый процесс. Убираете его из приложения, и запускаете в отдельном контейнере, где он работает сам по себе. СОА-сервисы монолитная архитектура (SOA – Service-oriented architecture) поддерживаются через реестр, который считается перечнем файлов каталога. Приложения должны найти сервис в реестре и вызвать его.
Design for failure для распределенной системы
Скорее, микросервис можно назвать частным случаем SOA и одним из способов ее реализовать. Неожиданный пример микросервисной архитектуры из живой природы — гигантский осьминог. В каждом щупальце осьминога свой мозг, поэтому его конечности двигаются независимо друг от друга. А сам осьминог благодаря этому способен на очень сложные движения.
Соответственно, изменения в одних частях монолита повлияют на функционирование всей системы. Более того, именно следование принципам DevOps делает микросервисы успешной архитектурой. А это именно то, в чём заключается суть концепции DevOps. Микросервисная архитектура – подход к разработке системы (продукта, приложения), при котором обеспечивается разделение ее компонентов на автономные составляющие — микросервисы.