ћерион Ќетворкс

ћикросервисы – это шаблон сервис-ориентированной архитектуры, в котором приложени€ создаютс€ в виде наборов небольших и независимых сервисных единиц. “акой подход к проектированию сводитс€ к разделению приложени€ на однофункциональные модули с четко прописанными интерфейсами. Ќебольшие команды, управл€ющие всем жизненным циклом сервиса могут независимо развертывать и обслуживать микросервисы.

“ермин «микро» относитс€ к размеру микросервиса – он должен быть удобным в управлении одной командой разработчиков (5-10 специалистов). ¬ данной методологии большие приложени€ дел€тс€ на крошечные независимые блоки.


„то такое монолитна€ архитектура?

≈сли говорить простым €зыком, то монолитна€ архитектура – это как бы большой контейнер, в котором все компоненты приложени€ соедин€ютс€ в единый пакет.

¬ качестве примера монолитной архитектуры давайте рассмотрим сайт дл€ электронной торговли. Ќапример, онлайн-магазин.

ћонолитна€ архитектура приложени€ дл€ электронной торговли

¬ любом таком приложении есть р€д типовых опций: поиск, рейтинг и отзывы, а также оплаты. ƒанные опции доступны клиентам через браузер или приложение.  огда разработчик сайта онлайн-магазина развертывает приложение, это считаетс€ одной монолитной (неделимой) единицей.  од различных опций (поиска, отзывов, рейтинга и оплаты) находитс€ на одном и том же сервере. „тобы масштабировать приложение, вам нужно запустить несколько экземпл€ров (серверов) этих приложений.


„то такое микросервисна€ архитектура?

ћикросервисной архитектурой называетс€ методика разработки архитектуры, позвол€юща€ создавать приложени€ в виде набора небольших автономных сервисов дл€ работы с конкретными предметными област€ми. “акой вариант структурированной архитектуры позвол€ет организовать приложени€ в множество слабосв€занных сервисов. ћикросервисна€ архитектура содержит мелкомодульные сервисы и упрощенные протоколы.

ƒавайте рассмотрим пример приложени€ дл€ онлайн-торговли с микросервисной архитектурой. ¬ данном примере каждый микросервис отвечает за одну бизнес-возможность. ” «ѕоиска», «ќплаты», «–ейтинга и ќтзывов» есть свои экземпл€ры (сервер), которые взаимодействуют между собой.

ћикросервисна€ архитектура

¬ монолитной архитектуре все компоненты сливаютс€ в одну модель, тогда как в микросервисной архитектуре они распредел€ютс€ по отдельным модул€м (микросервисам), которые взаимодействуют между собой (см. пример выше).

 оммуникаци€ между микросервисами – это взаимодействие без сохранени€ состо€ни€.  ажда€ пара запросов и ответов независима, поэтому микросервисы легко взаимодействуют друг с другом. ћикросервисна€ архитектура использует федеративные данные.  аждый микросервис имеет свой отдельный массив данных.


ћикросервисы и монолитна€ архитектура: сравнение

ћикросервисы

ћонолитна€ архитектура

 аждый блок данных создаетс€ дл€ решени€ определенной задачи; его размер должен быть предельно малым

≈дина€ база кода дл€ всех бизнес-целей

«апуск сервиса происходит сравнительно быстро

Ќа запуск сервиса требуетс€ больше времени

Ћокализовать ошибки довольно просто. ƒаже если один сервис сломаетс€, другой – продолжит свою работу

Ћокализовать ошибки сложно. ≈сли кака€-то определенна€ функци€ не перестает работать, то ломаетс€ вс€ система. „тобы решить проблему, придетс€ заново собирать, тестировать и развертывать приложение.

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

ћонолитна€ архитектура тесно св€зана. »зменени€ в одному модуле кода вли€ет на другой

 омпании могут выдел€ть больше ресурсов на самые рентабельные сервисы

—ервисы не изолированы; выделение ресурсов на отдельные сервисы невозможно

ћожно выделить больше аппаратных ресурсов на самые попул€рные сервисы. ¬ примере выше посетители чаще обращаютс€ к каталогу товаров и поиску, а не к разделу оплат. “аким образом, будет разумнее выделить дополнительные ресурсы на микросервисы каталога товаров и поиска

ћасштабирование приложени€ – задача сложна€ и экономически не выгодна€

ћикросервисы всегда остаютс€ посто€нными и доступными

Ѕольша€ нагрузка на инструменты дл€ разработки, поскольку процесс необходимо запускать с нул€

‘едеративный доступ к данным, благодар€ чему под отдельные микросервисы можно подбирать наиболее подход€щую модель данных

ƒанные централизованы

Ќебольшие целевые команды. ѕараллельна€ и ускоренна€ разработка

Ѕольша€ команда; требуетс€ серьезна€ работа по управлению командой

»зменени€ в модели данных одного микросервиса никак не сказываетс€ на других микросервисах

»зменени€ в модели данных вли€ют на всю базу данных

„етко прописанный интерфейс позвол€ет микросервисам эффективно взаимодействовать между собой

Ќе предусмотрено

ћикросервисы делают акцент на продуктах (модул€х), а не проектах

—осредоточены на проекте в целом

ќтсутствие перекрестных зависимостей между базами кода. ƒл€ разных микросервисов можно использовать разные технологии

ќдна функци€ или программа зависит от другой


—ложности в работе с микросервисами

  • ћикросервисы полагаютс€ друг на друга, поэтому необходимо выстроить коммуникацию между ними.
  • ¬ микросервисах создаетс€ больше модулей, чем в монолитных системах. Ёти модули пишутс€ на разных €зыках, и их необходимо поддерживать.
  • ћикросервисы – это распределенна€ система, так что, по сути, мы имеем дело со сложной системой.
  • ¬ разных сервисах используютс€ свои механизмы; дл€ неструктурированных данных требуетс€ больший объем пам€ти.
  • ƒл€ предотвращени€ каскадных сбоев необходимо эффективное управление и слаженна€ командна€ работа.
  • “рудно воспроизвести ошибку, если она пропадает в одной версии и вновь по€вл€етс€ в другой.
  • Ќезависимое развертывание и микросервисы – вещи слабо совместимые.
  • ћикросервисна€ архитектура требует большего количества операций.
  • —ложно управл€ть приложением, когда в систему добавл€ютс€ новые сервисы.
  • ƒл€ поддержки всевозможных распределенных сервисов требуетс€ больша€ команда опытных специалистов.
  • ћикросервисы считаютс€ дорогосто€щими решени€ми, поскольку дл€ разных задач создаютс€ и поддерживаютс€ разные серверные пространства.

—ервис-ориентированна€ архитектура (—ќј) или микросервисы

—ќј-сервисы (SOA - Service-oriented architecture) поддерживаютс€ через реестр, который считаетс€ перечнем файлов каталога. ѕриложени€ должны найти сервис в реестре и вызвать его.

»наче говор€, —ќј похож оркестр: каждый музыкант играет на своем инструменте, а всеми артистами управл€ет дирижер.

ћикросервисы – это разновидность —ќј-стил€. ѕриложени€ создаютс€ в виде набора небольших сервисов, а не цельной программы.

ћикросервисы похожи на труппу артистов: каждый танцор знает свою программу и не зависит от других. ƒаже если кто-то забудет какое-то движение, вс€ труппа не собьетс€ с ритма.

“еперь давайте поговорим о различи€х между —ќј и микросервисах.

ѕараметр

—ќј

ћикросервисы

“ип проектировани€

¬ —ќј компоненты приложени€ открыты дл€ внешнего мира; они доступны в виде сервисов

ћикросервисы – это часть —ќј. “ака€ архитектура считаетс€ реализацией —ќј

«ависимость

ѕодразделени€ – зависимы

ќни не завис€т друг от друга

–азмер приложени€

–азмер приложени€ больше, чем у обычных программ

–азмер приложени€ всегда небольшой

—тек технологий

—тек технологий ниже, чем у микросервисов

—тек технологий очень большой

—ущность приложени€

ћонолитна€

ѕолностекова€

Ќезависимость и ориентированность

—ќј-приложени€ создаютс€ дл€ выполнени€ множества бизнес-задач

—оздаютс€ дл€ выполнени€ одной бизнес-задачи

–азвертывание

ѕроцесс развертывани€ раст€нут по времени

Ќесложное развертывание, на которое тратитс€ меньше времени

–ентабельность

Ѕолее рентабельно

ћенее рентабельно

ћасштабируемость

ћеньше, чем у микросервисов

¬ысока€ масштабируемость

Ѕизнес-логика

 омпоненты бизнес-логики хран€тс€ внутри одного сервисного домена. ѕростые проводные протоколы (HTTP с XML JSON).
API управл€етс€ с помощью SDK/клиентов

Ѕизнес-логика распределена между разными корпоративными доменами


ћикросервисные инструменты

Wiremock – тестирование микросервисов

WireMock – это гибка€ библиотека дл€ создани€ заглушек и сервисов-имитаций. ¬ ней можно настроить ответ, который HTTP API вернет при получении определенного запроса. “акже может использоватьс€ дл€ тестировани€ микросервисов.

Docker

Docker – это проект с открытым кодом дл€ создани€, развертывани€ и запуска приложений с помощью контейнеров. »спользование такого рода контейнеров позвол€ет разработчикам запускать приложение в виде одного пакета.  роме того, в одном пакете могут поставл€тьс€ библиотеки и другие зависимости.

Hystrix

Hystrix – это отказоустойчива€ Java-библиотека. ƒанный инструмент предназначен дл€ разделени€ точек доступа к удаленным сервисам, системам и сторонним библиотекам в распределенной среде (микросервисах). Ѕиблиотека улучшает всю систему в целом, изолиру€ неисправные сервисы и предотвраща€ каскадный эффект от сбоев.


Ћучшие примеры использовани€ микросервисной архитектуры

  • ќтдельное хранение данных дл€ каждого микросервиса.
  • ѕоддержание кода на едином уровне зрелости
  • ќтдельна€ сборка дл€ каждого микросервиса.

«аключение

  • ћикросервисы – это —ќј-шаблон, в котором приложени€ создаютс€ как набор малых и независимых серверных единиц.
  • ћикросервисна€ архитектура относитс€ к стил€м разработки архитектуры, позвол€ющим создавать приложение в виде небольших и автономных сервисов дл€ определенных предметных областей.
  • ћонолитна€ архитектура похожа на большой контейнер, в котором все компоненты приложени€ собраны в один пакет.
  •  аждый блок приложени€ в микросервисе имеет предельно малый размер и выполн€ет определенную функцию.
  • Ѕольша€ база кода в монолитной архитектуре замедл€ет процесс разработки. ¬ыход новых версий может раст€нутьс€ на мес€цы. ѕоддерживать такую базу кода довольно сложно.
  • —уществует 2 типа микросервисов: Stateless (без сохранени€ состо€ни€) и Stateful (с отслеживанием состо€ни€)
  • ћикросервисы на Java полагаютс€ друг на друга; они должны взаимодействовать между собой. ћикросервисы позвол€ют в большей степени сконцентрироватьс€ на определенных функци€х или потребност€х бизнеса.
  • —ервисно-ориентированна€ архитектура, или —ќј, – это усовершенствованные распределенные вычислени€, основанные на проектной модели запроса/ответа в синхронных или асинхронных приложени€х.
  •  омпоненты приложени€ в —ќј открыты дл€ внешнего мира и представлены в виде сервисов; микросервисы считаютс€ частью —ќј. Ёто реализаци€ —ќј.
  •   попул€рным микросервисным инструментам относ€тс€ Wiremock, Docker и Hystrix.

—кидки 50% в Merion Academy

¬ыбрать курс