Что такое микросервисы?
MICROSERVICES — это шаблон сервис-ориентированной архитектуры, в котором приложения создаются как совокупность различных наименьших независимых сервисных единиц. Это программный подход, который фокусируется на разложении приложения на однофункциональные модули с четко определенными интерфейсами. Эти модули могут быть независимо развернуты и эксплуатироваться небольшими группами, владеющими всем жизненным циклом службы.
Термин «микро» относится к размеру микросервиса, которым должна управлять одна команда разработчиков (от 5 до 10 разработчиков). В этой методологии большие приложения делятся на наименьшие независимые единицы.
В этом учебном курсе для начинающих вы
- Что такое микросервисы?
- Что такое монолитная архитектура?
- Что такое микросервисная архитектура?
- Микросервис VS. Монолитная архитектура
- Проблемы микросервиса
- SOA против микросервисов
- Микросервисные Инструменты
- Лучшие практики архитектуры микросервисов
Что такое монолитная архитектура?
С точки зрения непрофессионала, вы можете сказать, что монолитная архитектура подобна большому контейнеру, в котором все программные компоненты приложения объединены в один пакет.
Давайте обсудим пример магазина электронной коммерции в контексте монолитной архитектуры.
В любом приложении электронной коммерции есть некоторые стандартные функции, такие как поиск, обзор и рейтинги, а также платежи. Эти функции доступны для клиентов, использующих их браузер или приложения. Когда разработчик сайта электронной коммерции развертывает приложение, оно представляет собой единое монолитное устройство. Код для различных функций, таких как поиск, обзор и рейтинги и платежи, находится на одном сервере. Для масштабирования приложения вам необходимо запустить несколько экземпляров (серверов) этих приложений.
Что такое микросервисная архитектура?
МИКРОСЕРВИСНАЯ АРХИТЕКТУРА — это архитектурный стиль разработки, который позволяет создавать приложения в виде набора небольших автономных сервисов, разработанных для бизнес-сферы.
Давайте рассмотрим пример приложения электронной коммерции, разработанного с микросервисной архитектурой. В этом примере каждый микросервис ориентирован на отдельные возможности бизнеса. Поиск, рейтинг, обзор и оплата имеют свой экземпляр (сервер) и общаются друг с другом.
В этой монолитной архитектуре все компоненты объединяются в единый модуль. Но в архитектуре микросервисов они разбиты на отдельные модули (микросервисы), которые взаимодействуют друг с другом.
Связь между микросервисами — это связь без сохранения состояния, в которой каждая пара запроса и ответа независима. Следовательно, микросервисы могут общаться без особых усилий. В микросервисной архитектуре данные объединяются. Каждый микросервис имеет свое отдельное хранилище данных.
Микросервисы против монолитной архитектуры
| Microservices | Монолитная архитектура |
|---|---|
| Каждая единица всего приложения должна быть наименьшей, и она должна быть в состоянии поставить одну конкретную бизнес-цель. | Единая база кода для всех бизнес-целей |
| Запуск службы относительно быстрый | Запуск службы занимает больше времени |
| Неисправность изоляции легко. Даже если одна служба выходит из строя, другая может продолжать функционировать. | Неисправность изоляции сложна. Если какая-либо конкретная функция не работает, вся система выходит из строя. Для решения этой проблемы приложение необходимо пересобрать, повторно протестировать, а также повторно развернуть. |
| Все микросервисы должны быть слабо связаны, чтобы изменения, сделанные в одном, не влияли на другой. | Монолитная архитектура тесно связана. Изменения в одном модуле кода влияют на другой |
| Предприятия могут использовать больше ресурсов для услуг, которые обеспечивают более высокую рентабельность инвестиций | Поскольку услуги не изолированы, индивидуальное распределение ресурсов невозможно |
| Для службы, которая часто используется, может быть выделено больше аппаратных ресурсов. В приведенном выше примере электронной коммерции большее количество пользователей проверяют список товаров и осуществляют поиск по сравнению с платежами. Таким образом, можно выделить больше ресурсов для микросервиса поиска и распечатки товаров. | Масштабирование приложений является сложным, а также расточительным. |
| Микросервисы всегда остаются последовательными и постоянно доступны. | Инструменты разработки перегружены, так как процесс должен начинаться с нуля. |
| Данные объединены. Это позволяет отдельным микросервисам использовать модель данных, наиболее подходящую для ее нужд. | Данные централизованы. |
| Маленькие Сфокусированные Команды. Параллельное и более быстрое развитие | Требуется большая команда и значительные управленческие усилия |
| Изменение модели данных одного микросервиса не влияет на другие микросервисы. | Изменение в модели данных влияет на всю базу данных |
| Взаимодействует с другими микросервисами с помощью четко определенных интерфейсов. | Непригодный |
| Микросервисы работают по принципу, который ориентирован на продукты, а не проекты | Делать акцент на весь проект |
| Нет взаимозависимости между кодами. Вы можете использовать разные технологии для разных микросервисов. | Одна функция или программа зависит от других. |
Проблемы микросервиса
- Микроуслуги полагаются друг на друга, и им придется общаться друг с другом.
- По сравнению с монолитными системами существует больше сервисов для мониторинга, которые разработаны с использованием разных языков программирования.
- Поскольку это распределенная система, это сложная модель.
- Различные сервисы будут иметь свой отдельный механизм, что приведет к большому объему памяти для неструктурированных данных.
- Эффективное управление и командная работа, необходимые для предотвращения каскадных проблем
- Воспроизвести проблему будет непросто, если она уже выпущена в одной версии и возвращается в последней версии.
- Независимое развертывание сложно с микросервисами.
- Микросервисная архитектура приносит много накладных расходов.
- Сложно управлять приложением, когда в систему добавляются новые сервисы
- Для поддержки неоднородно распределенных микросервисов требуется широкий круг квалифицированных специалистов.
- Микросервис стоит дорого, так как вам нужно поддерживать разное пространство сервера для разных бизнес-задач.
SOA против микросервисов
Сервисы SOA поддерживаются в организации реестром, который действует как список каталогов. Приложения должны искать сервисы в реестре и вызывать сервис.
В другом мире SOA похожа на оркестр, где каждый артист выступает со своим инструментом, а музыкальный руководитель дает указания всем.
С другой стороны, микросервисы — это форма стиля сервис-ориентированной архитектуры, в которой приложения создаются как набор различных небольших сервисов, а не как одно программное обеспечение или приложение.
Микросервисы — это как труппа, где каждый танцор независим и знает, что ему нужно делать. Так что, если они пропустят некоторые шаги, они знают, как вернуться к правильной последовательности.
Вот подробное сравнение между SOA и Microservices
| параметр | SOA | Microservices |
|---|---|---|
| Тип дизайна | В SOA программные компоненты открыты для внешнего использования для использования в форме сервисов. | Микро Сервис является частью SOA. Это реализация SOA. |
| зависимость | Бизнес-единицы являются зависимыми. | Они независимы друг от друга. |
| Размер программного обеспечения | Размер программного обеспечения больше, чем у любого обычного программного обеспечения | Размер Программного обеспечения всегда мал в Микросервисах |
| Технологический стек | Технологический стек ниже по сравнению с Microservice. | Стек микросервисных технологий может быть очень большим |
| Характер применения | Монолитный в природе | Полный стек в природе |
| Независимый и Фокус | SOA-приложения созданы для выполнения нескольких бизнес-задач. | Они созданы для выполнения одной бизнес-задачи. |
| развертывание | Процесс развертывания занимает много времени. | Развертывание является простым и менее трудоемким. |
| Экономичность — эффективность | Более экономически эффективным. | Менее рентабельно. |
| Масштабируемость | Меньше по сравнению с микросервисами. | Высоко масштабируемый |
| Бизнес логика | Компоненты бизнес-логики хранятся в одном домене услуг. Простые проводные протоколы (HTTP с XML JSON) API управляется с помощью SDK / клиентов |
Бизнес-логика может существовать между доменами Service Bus, как слои между сервисами Middleware. |
Микросервисные Инструменты
1) Wiremock: тестирование микросервисов
WireMock — это гибкая библиотека для создания заглушек и насмешек над веб-сервисами. Он может настроить ответ, возвращаемый HTTP API, когда он получает конкретный запрос. Он также используется для тестирования микросервисов.
Ссылка для скачивания: http://wiremock.org/
2) Докер
Docker — это проект с открытым исходным кодом, который позволяет нам создавать, развертывать и запускать приложения с использованием контейнеров. Используя эти контейнеры, разработчики могут запускать приложение как единый пакет. Это позволяет вам отправлять библиотеки и другие зависимости в одном пакете.
Ссылка для скачивания: https://www.docker.com/
3) Хистрикс
Hystrix — это отказоустойчивая Java-библиотека. Этот инструмент предназначен для разделения точек доступа к удаленным службам, системам и сторонним библиотекам в распределенной среде, такой как микросервисы. Это улучшает общую систему, изолируя отказавшие сервисы и предотвращая каскадный эффект отказов.
Ссылка для скачивания: https://github.com/Netflix/Hystrix
Лучшие практики архитектуры микросервисов
- Отдельное хранилище данных для каждого Микросервиса
- Сохраняйте код аналогичного уровня зрелости.
- Отдельная сборка для каждого микро сервиса
- Всегда обращайтесь с людьми без гражданства.
Резюме
- Микросервисы — это шаблон сервис-ориентированной архитектуры, в котором приложения создаются как совокупность различных наименьших независимых сервисных единиц.
- Микросервисная архитектура — это архитектурный стиль разработки, который позволяет создавать приложения в виде набора небольших автономных служб, разработанных для бизнес-сферы.
- Монолитная архитектура похожа на большой контейнер, в котором все программные компоненты приложения объединены в один пакет.
- В микросервисе каждая единица всего приложения должна быть наименьшей, и она должна быть в состоянии достичь одной конкретной бизнес-цели
- В монолитной архитектуре большая кодовая база может замедлить весь процесс разработки. Новые выпуски могут занять месяцы. Сопровождение кода сложно
- Два типа микросервисов: 1) без сохранения состояния 2) с сохранением состояния
- Микросервисы полагаются друг на друга, и им придется общаться друг с другом. Помогает вам сделать акцент на конкретной функции и потребностях бизнеса
- Сервис-ориентированная архитектура, вскоре известная как SOA, представляет собой эволюцию распределенных вычислений на основе модели проектирования запросов или ответов для синхронных и асинхронных приложений.
- В SOA программные компоненты открыты для внешнего использования для использования в форме сервисов, тогда как Micro Service является частью SOA. Это реализация SOA
- Wiremock, Docker и Hystrix — некоторые популярные инструменты для микросервисов