Микросервисная архитектура – одна из наиболее обсуждаемых тенденций в области архитектуры программного обеспечения на данный момент, и она навсегда изменила способ создания корпоративных приложений. Вместо медленного, сложного монолитного подхода прошлого разработчики и компании во всем мире обращаются к архитектуре микросервисов для упрощения и масштабирования своих структур. На самом деле, даже такие компании, как Amazon, Netflix, Spotify и Uber, совершили переход.
Независимо от того, хотите ли вы начать работу с микросервисами или вам просто интересно узнать о спорах, связанных с этим, вы находитесь в правильном месте. Сегодня я расскажу вам обо всем, что вам нужно знать о микросервисах, от реальных примеров до шаблонов архитектуры и многого другого. Мы рассмотрим следующее:
- Что такое Архитектура микросервисов
- Преимущества и недостатки
- Микросервисы и Докер
- Технологические стеки и архитектурные шаблоны
- Справочное руководство
Давайте начнем!
Что такое Архитектура микросервисов?
Универсального определения термина “микросервисы” не существует. Простейшее определение микросервисов, также называемое архитектурой микросервисов, представляет собой архитектурный стиль, который структурирует приложение с использованием слабо связанных сервисов. Эти коллекции или модули могут независимо разрабатываться, развертываться и обслуживаться.
Они работают гораздо быстрее и надежнее, чем традиционные сложные монолитные приложения. Используя микросервисные архитектуры, организация любого размера может разрабатывать технологические стеки, адаптированные к их возможностям.
Использование микросервисов дает много ощутимых преимуществ, которые мы обсудим позже, но все еще существуют некоторые разногласия по поводу того, следует ли компаниям переходить с монолитной архитектуры на микросервисную. Давайте рассмотрим разницу между ними, чтобы понять суть дебатов.
Монолитный против Микросервисы
Монолитная архитектура – это традиционный способ создания и развертывания приложений. Эта структура основана на концепции единого, неделимого подразделения, включающего серверную часть, клиентскую часть и базу данных. Все аспекты унифицированы и управляются как единое целое и кодовая база. Это означает, что любые обновления должны вноситься в одну и ту же кодовую базу, поэтому весь стек должен быть изменен. По мере масштабирования монолитных приложений они могут становиться довольно сложными, поэтому общая разработка, как правило, занимает больше времени.
С другой стороны, архитектура микросервисов |/разбивает это подразделение на независимые, которые функционируют как отдельные службы. Это означает, что каждая служба имеет свою собственную логику и кодовую базу. Они взаимодействуют друг с другом через API (Интерфейсы прикладного программирования).
Итак, какую архитектуру вам следует выбрать? Давайте разберем это по полочкам.
Выбор монолитной архитектуры
Если ваша компания – небольшая команда.
Таким образом, вам не придется иметь дело со сложностями развертывания микросервисной архитектуры. Если вы хотите более быстрый запуск.
Выбор архитектуры микросервисов
- Если вы хотите разработать более масштабируемое приложение. Масштабирование архитектуры микросервисов намного проще. Новые возможности и модули могут быть добавлены с большой легкостью и скоростью.
- Если ваша компания крупнее или планирует расти. Использование микросервисов отлично подходит для компании, которая планирует расти, поскольку архитектура микросервисов гораздо более масштабируема и ее легче настраивать с течением времени.
Преимущества и недостатки микросервисов
Существует ряд причин, по которым архитектура микросервисов является лучшим выбором для вашей компании. Давайте обсудим наиболее заметные преимущества, а затем рассмотрим некоторые недостатки.
Выгоды
Повышает масштабируемость и производительность
Большим командам часто приходится работать вместе над сложными проектами. С помощью микросервисов проекты можно разделить на более мелкие независимые подразделения. Это означает, что команды могут действовать независимо в отношении логики предметной области, что сводит к минимуму координацию и усилия. Кроме того, команды, ответственные за каждый микросервис, могут принимать свои собственные технологические решения в зависимости от своих потребностей.
Например, внутренняя структура каждого блока или контейнера не имеет значения, пока интерфейс функционирует правильно. Таким образом, для написания микросервиса можно использовать любой язык программирования, поэтому ответственная команда может выбрать лучший язык для своих товарищей по команде.
Хорошо интегрируется с устаревшими системами
Монолитные системы трудно поддерживать. Многие устаревшие системы плохо структурированы, плохо протестированы или зависят от устаревших технологий. К счастью, микросервисы могут работать вместе с устаревшими системами для улучшения кода и замены старых частей системы. Интеграция проста и может решить многие проблемы, из-за которых монолитные системы остались в прошлом.
Устойчивое развитие
Микросервисные архитектуры создают системы, которые остаются ремонтопригодными в долгосрочной перспективе, поскольку различные части можно заменить. Это означает, что микросервис можно легко переписать без ущерба для всей системы. Пока зависимости между микросервисами управляются надлежащим образом, можно легко вносить изменения для оптимизации потребностей команды и производительности.
Кросс-функциональность
Микросервисы лучше всего подходят для распределенных команд. Если у вас есть команды по всему миру или различные подразделения, микросервисы предоставляют необходимые свободы и гибкость для автономной работы. Можно быстро принимать технические решения, которые мгновенно интегрируются с другими сервисами. Кросс-функциональность еще никогда не была такой простой.
Недостатки
Развертывание требует больше усилий
Эксплуатация микросервисной системы часто требует больших усилий, поскольку существует больше развертываемых блоков, каждый из которых должен быть развернут и отслеживаться. Изменения в интерфейсах должны быть реализованы таким образом, чтобы по-прежнему было возможно независимое развертывание отдельных микросервисов.
Тестирование должно быть независимым
Поскольку все микросервисы должны тестироваться вместе, один микросервис может блокировать этап тестирования и препятствовать развертыванию других микросервисов. Существует больше интерфейсов для тестирования, и тестирование должно быть независимым для обеих сторон интерфейса.
Сложно изменить несколько микросервисов
Изменения, которые затрагивают несколько микросервисов, может быть сложнее реализовать. В микросервисной системе изменения требуют нескольких скоординированных развертываний.
Микросервисы и Докер
Docker и микросервисы – почти синонимы. Микросервисы должны быть отдельно развертываемыми, масштабируемыми независимыми единицами. Но что, если вы создадите несколько микросервисов для своего приложения? Docker – это легкое решение для развертывания микросервисов. Микросервис может быть упакован в образ Docker и изолирован как контейнер Docker. Таким образом, вы можете создать приложение, не зависящее от вашей хост-среды.
Вместо того, чтобы иметь собственную полноценную виртуальную машину, контейнеры Docker совместно используют ядро операционной системы на хосте Docker. Процессы из контейнеров отображаются в таблице процессов операционной системы, в которой запущены контейнеры Docker.
Чтобы использовать Docker с микросервисами, вам необходимо создать образы Docker с помощью файлов с именем Dockerfile . Файлы Dockerfile легко писать, поэтому развертывание программного обеспечения может быть легким. Взгляните на пример файла Dockerfile для микросервиса Java.
FROM openjdk:11.0.2-jre-slim COPY target/customer.jar . CMD /usr/bin/java -Xmx400m -Xms400m -jar customer.jar EXPOSE 8080
Хотите узнать больше о Docker? Ознакомьтесь с Образовательным курсом по основам Docker и Kubernetes
Типичная микросервисная система содержит несколько контейнеров Docker. Координация системы из нескольких контейнеров Docker требует настройки виртуальной сети. Контейнеры должны иметь возможность находить друг друга, чтобы общаться. Среда Docker Compose может связываться с другим сервером по ссылке, предлагая систему обнаружения служб.
Продолжайте учиться.
Изучайте архитектуру микросервисов, не просматривая видео или документацию. Обучающие текстовые курсы легко просматриваются и имеют живую среду кодирования, что делает обучение быстрым и эффективным.
Введение в Принципы и концепции микросервисов
Технологические стеки и шаблоны архитектуры
Одно дело понимать, как работает микроархитектура, и совсем другое – реально создавать и внедрять ее. Вот почему мы хотим сосредоточиться на различных технологиях, доступных вам для всей системы микросервисов. Давайте рассмотрим некоторые различные технологические стеки, шаблоны и проекты для создания исполняемой архитектуры микросервиса.
Решения в области микро- и макроархитектуры
Желательно разделить вашу архитектуру на микро- и макроархитектуру. Микроархитектура включает в себя все решения, принимаемые для каждого микросервиса. Макроархитектура включает в себя все решения, принимаемые на глобальном уровне, которые применяются ко всем микросервисам.
Концепцию микро- и макроархитектуры можно распространить на технические решения. Технические решения могут приниматься в рамках макро- или микроархитектуры. Например, взгляните на технические решения, которые должны быть приняты на микро- и макроуровнях для базы данных:
Micro: Каждый микросервис может иметь свой собственный экземпляр базы данных. Если базы данных были определены на микроархитектуре, сбой одной базы данных приведет только к сбою одного микросервиса. Это делает все приложение намного более надежным.
Макрос: База данных также может быть определена как часть архитектуры макросов. Несколько микросервисов не должны совместно использовать схему базы данных.
Автономные системы
Автономная система (SCS) – это тип микросервисной архитектуры, который определяет элементы макроархитектуры. Это означает, что они не представляют всю систему в целом. Поскольку SCS является автономным, он предоставляет все необходимое для реализации одной части логики домена, например данные журнала и пользовательский интерфейс. SCSS также имеют дополнительный API.
Например, SCS для платежа микросервиса будет хранить информацию, относящуюся к этому платежу, в виде ограниченного контекста. Он также будет реализовывать пользовательский интерфейс для отображения истории платежей, а данные о клиентах будут реплицироваться из других SCSS.
Думайте об этом как о наборе лучших практик; SCSS предоставляют точные правила, основанные на установленных шаблонах, предлагая точку отсчета для построения микросервисной архитектуры. Все эти правила гарантируют, что SCS реализует домен, поэтому добавленная функция изменяет только один SCS.
Мы можем рассматривать SCS как микросервисную архитектуру, поскольку ее можно развертывать независимо и разделять систему на независимые веб-приложения. Фактически, одна SCS может быть даже разделена на несколько микросервисов. Они отличаются от микросервисов тремя основными способами: они больше, чем микросервисы; они ориентированы на слабую связь; у них должен быть пользовательский интерфейс.
Вы можете узнать больше о SCSs здесь
Интеграция с внешним интерфейсом
Микросервисы также могут быть интегрированы с веб-интерфейсом. Разделение интерфейса на различные модули помогает решить некоторые проблемы, возникающие при рассмотрении его как единого целого. Модульный интерфейс состоит из отдельно развертываемых микросервисов. Это может принести много преимуществ вашему интерфейсу.
Например, модульный интерфейс может иметь независимую логику домена, и изменение домена может быть реализовано простым изменением только одного микросервиса. Чтобы объединить отдельные интерфейсы, они должны быть интегрированы, поэтому необходима система интеграции.
Это может быть достигнуто с помощью ссылок, где один интерфейс отображает ссылку, которую другой интерфейс считывает и обрабатывает. Это также может быть достигнуто с помощью перенаправлений, например, как OAuth2 обрабатывает интеграцию с внешним интерфейсом. Переадресации сочетают передачу данных с интеграцией с интерфейсом.
Однако есть несколько исключений, когда интерфейс должен быть развернут как монолит. Например, собственные мобильные приложения должны быть монолитными для развертывания или если бы существовала отдельная команда, ответственная за разработку интерфейса.
Асинхронные Микросервисы
Асинхронные микросервисы отправляют запрос другим микросервисам, пока он обрабатывает запросы и ожидает результатов. Протоколы асинхронной связи отправляют сообщения, на которые реагируют получатели, но прямого ответа нет. Микросервис может быть определен как асинхронный, если он не выполняет запросы к другим микросервисам во время обработки, или он выполняет запросы, но не ожидает результатов.
Асинхронные микросервисы предлагают несколько заметных преимуществ по сравнению с синхронными микросервисами и решают многие проблемы распределенных систем. Логика, необходимая для обработки запросов микросервиса, не зависит от результатов, что делает их гораздо более независимыми.
Аналогичным образом, если партнер по коммуникации потерпит неудачу, это не приведет к сбою всей системы, обеспечивая общую устойчивость вашей системы. Кроме того, обработка и доставка почти всегда гарантированы.
Некоторыми распространенными примерами технологий для асинхронных микросервисов являются Kafka (MOM, обычно используемый для обмена сообщениями), REST и формат данных Atom (для дополнительной инфраструктуры).
Платформы микросервисов
Платформы микросервисов, такие как PaaS и Docker scheduler, поддерживают работу и взаимодействие ваших микросервисов. Эти технологии обеспечивают связь между микросервисами для развертывания, анализа журналов и мониторинга.
Например, эти платформы поддерживают HTTP и REST с балансировкой нагрузки и обнаружением служб. Для реализации микросервисов требуется ограниченная поддержка операций, поэтому они могут быть быстро развернуты и поддерживать несколько микросервисов.
Платформы микросервисов представляют собой упрощение и решение распространенных проблем. Некоторые известные платформы – Kubernetes и Docker, что очень важно для работы микросервисов. PaaS и Cloud Foundry также полезны, но они не так популярны.
Важно отметить, что переход на эти платформы требует изменений в работе и установке приложений, что может сделать использование платформы микросервисов большим и своевременным шагом. Это главный недостаток микросервисных платформ.
Подведение итогов
Теперь, когда у вас есть представление о том, что может предложить архитектура микросервисов и какие существуют варианты, вы готовы приступить к практическому обучению. Взгляните на наш список ресурсов ниже для получения дополнительной информации о микросервисах.
Ресурсы
Руководство по микросервисам: сборник статей, посвященных различным темам, связанным с микросервисами
Искусство мониторинга в эпоху микросервисов: полезные вопросы и ответы с автором книги “Искусство мониторинга”, в которой рассматриваются стратегии мониторинга
Создание микросервисов: : книга О’Рейли о микросервисах
Руководство для начинающих по микросервисам GitHub: простой в навигации репозиторий кода для начинающих
Введение AWS в микросервисы: Документация Amazon и определение концепций микросервисов
Микросервисная архитектура: окончательные онлайн-курсы
Ищете онлайн-курс, которому вы действительно можете доверять? Мы подготовили для вас серию из двух частей “Все, что вам нужно знать о микросервисах”, написанную одним из экспертов в этой области Эберхардом Вольфом , одним из основателей сообщества Java Champions.
Начните с основных принципов работы микросервисов, чтобы заложить все основы, необходимые для развертывания и внедрения.
Введение в принципы и концепции микросервисов расскажет вам обо всех плюсах и минусах этой захватывающей тенденции, используя реальные примеры и стратегии миграции.
Затем вы можете перейти к Архитектура микросервисов: практическая реализация , одному из лучших курсов для изучения мельчайших деталей реализации в реальном мире.
Этот курс познакомит вас с реальными “рецептами” и техническими стеками. Вы разберетесь во всех тонкостях развертывания и к концу станете профессионалом в области микросервисов!
Оба этих курса основаны на высоко оцененной книге Эберхарда на ту же тему, так что вы знаете, что получаете первоклассное обучение.
Будьте лучше подготовлены к борьбе с этой растущей тенденцией!
Счастливого обучения!
Оригинал: “https://dev.to/educative/microservices-architecture-tutorial-all-you-need-to-get-started-4pd4”