Вступление

В этом сообщении блога мы рассмотрим различия между Monolith и Microservices с точки зрения AWS.

Монолит

«Одноуровневое программное приложение, в котором пользовательский интерфейс и код доступа к данным объединены в единую программу на единой платформе. »- Википедия.

Некоторые примеры Monolith - это один файл jar Java, который обрабатывает бизнес-логику для различных областей вашего проекта, или программа COBOL, которая обрабатывает разные функции. Реализация монолита - неплохая идея, потому что сначала монолит - это просто, особенно для небольших проектов. Поскольку все содержится в единой кодовой базе, нет никакой чрезмерной инженерии.

  • Он также экономичен в небольших масштабах, но по мере роста вашего проекта модульность трудно обеспечить, масштабирование становится проблемой, а длительные циклы развертывания по принципу «все или ничего» медленно реагируют на запросы клиентов. Со временем эта единая база кода становится больше, поэтому, даже если вы не касаетесь некоторых функций, вам все равно нужно протестировать ее, чтобы убедиться, что они не затронуты, потому что они являются частью одного и того же кода, поэтому ваш бизнес становится медленно реагировать на клиентов. потребность.

Можете ли вы использовать API с Monolith?

Абсолютно. API не имеют ничего общего с Monolith или микросервисами. На ваш монолит может выходить ваш API-шлюз или балансировщик нагрузки, и когда разные URL-адреса или пути попадают в ваш API-шлюз / балансировщик нагрузки, они могут перенаправлять все вызовы на один и тот же монолит. У вашего монолита будет функция входа или параграф, который будет проверять URL или путь и вызывать различные функции внутри монолита и соответственно выполнять логику.

Масштабирование монолита

Если ваш монолит работает на виртуальной машине, и поскольку вы запускаете эту огромную программу как один исполняемый файл, вам понадобится большой экземпляр EC2.
Если вы используете экземпляр EC2 размера M5.12xlarge и у вас есть три разных шаблона трафика store/get, store/post и store/delete.

store/get, чтобы получить некоторую информацию о каком-либо продукте.

store/post публиковать информацию о продукте, покупателе или покупке и store/delete удаляет информацию из базы данных. Итак, предположим, что трафик для store/get увеличения ЦП также увеличится до порогового значения, и если у вас установлена ​​группа автоматического масштабирования для вашей виртуальной машины и превышен порог для другой конфигурации масштабирования, вместо масштабирования только ЦП, необходимого для store/get компонент, который необходимо масштабировать для всего монолита, потому что вы не можете разделить разные компоненты для работы на разных EC2, используя подход монолита.

API в микросервисе.

Все три компонента store/get, store/post и store/delete имеют разную кодовую базу, и на бэкэнде вы можете видеть, что они работают на разных виртуальных машинах, и в зависимости от типа API вы можете управлять памятью и ЦП EC2.

В этом случае store/get backend выполняется в t3.large, store/post backend выполняется в t3.medium, а store/delete backend выполняется в t3.micro

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

На диаграмме выше, если трафик на store/get увеличивается вместо увеличения всех трех разных ec2, масштабировать необходимо только виртуальную машину, на которой запущен store/get backend. Если вы используете единую базу данных для нескольких микросервисов, вам нужно иметь в виду, что при масштабировании микросервисов база данных должна иметь возможность обрабатывать увеличенное количество подключений.

Как правило, существует множество методов для оптимизации чтения из базы данных, например, вы можете использовать реплику чтения, кэширование и т. Д. Еще одно преимущество использования микросервисов состоит в том, что, поскольку большинство серверных ВМ независимы друг от друга и могут поддерживаться разными командами, эти микросервисы могут быть написаны на разных языках программирования.
Таким образом, store/get может быть написан на python, store/post backend может быть написан на nodejs, а store/delete бэкэнд может быть написан на Go.

Характеристики микросервисных архитектур.

  • Основное свойство состоит в том, что каждая микрослужба независима от другой.
  • Масштабирование: каждый может масштабироваться независимо от другого.
  • Управление: поскольку они разделены, вы можете применять различные функции управления и безопасности, и вы можете развертывать каждую из них независимо. Это делает ваш DevOps намного быстрее и проще.
  • Тестирование: вы можете тестировать свои микросервисы независимо друг от друга с разными функциями.

Не важно следить за каждой характеристикой. Основная характеристика - независимое масштабирование и независимая функциональность.
Иногда можно увидеть, что одна и та же база данных используется более чем для одного микросервиса.

Развертывание микросервисов в AWS

В AWS есть одна служба, которая отвечает на все вопросы, - это Amazon EC2. Существует заблуждение, что на Amazon EC2 нельзя запускать микросервисы, что неверно. Как мы видели ранее, каждый микросервис может работать в собственном Amazon EC2, каждый из этих Amazon EC2 может входить в разные группы масштабирования с разными критериями масштабирования. Вы можете выбрать подходящее семейство Amazon EC2 в зависимости от характера микросервиса. поэтому, если какой-либо микросервис требует интенсивного использования памяти, вы можете выбрать больший объем памяти EC2 и масштабировать его выше. Вы также можете использовать Elastic Load Balancer или Amazon API Gateway для размещения своих микросервисов.

Помимо EC2 для разработки современных приложений, вы можете рассмотреть бессерверную альтернативу, которой является AWS Lambda, где каждый серверный модуль микросервисов будет реализован в виде отдельных лямбда-функций.

Lambda масштабируется автоматически, поэтому в этом случае нет группы автоматического масштабирования, и Lambda также может обслуживаться Elastic Load Balancer или шлюзом Amazon API.

Другой популярный выбор - использование контейнеров. Вы можете поместить свое приложение в контейнеры и запустить его в эластичном сервисе Kubernetes Amazon (EKS) или сервисе эластичных контейнеров Amazon (ECS). К вашим контейнерным сервисам также можно обращаться с помощью Elastic Load Balancer или Amazon API Gateway.

В вашей рабочей нагрузке Kubernetes каждый микросервис будет обслуживаться разными службами: код для store/get, store/post и store/delete будет выполняться в контейнере, а этот контейнер будет работать в модуле, и все они будут обрабатываться одним входом, который будет быть балансировщиком нагрузки приложений.

Вы можете комбинировать все свои сервисы AWS. Например, store/get может работать в модуле, где серверная часть вашего микросервиса закреплена в контейнере. store/post может быть размещен на Amazon EC2, а store/delete может работать на AWS Lambda.

Выбор лучшего микросервиса зависит от требований проекта, с которым вы хотите работать, а также от ресурсов и рабочих нагрузок для вашей серверной части.

Грасиас

Понравилось читать? Оставьте несколько «аплодисментов» ниже, чтобы другие могли найти этот пост. 🙂

Посмотрите мои другие сообщения :)

Https://thecraftman.medium.com/

Больше контента на plainenglish.io