REST (Representational State Transfer)

• Отсутствие статуса у сервера. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания и обработки запроса. Сервер не хранит контекст клиента между запросами.
• Унифицированный интерфейс. Согласованный способ взаимодействия с ресурсами, обычно использующий стандартные методы HTTP.
• Resource-Based. Сервисы моделируются как ресурсы, идентифицируются по URL и управляются с помощью форматов (обычно JSON или XML).
• Архитектура клиент-сервер. Клиент и сервер разделены, что позволяет им развиваться независимо друг от друга.
• Кэшируемость. Ответы должны определять, можно ли их кэшировать для повышения производительности.

• Стандартизация. Обеспечивает стандартизированный способ доступа к ресурсам, что облегчает понимание и использование разработчиками.
• Масштабируемость. Отсутствие статичности позволяет RESTful-сервисам легко масштабироваться.
• Интероперабельность. Взаимодействие на основе HTTP обеспечивает совместимость различных платформ и языков.
• Отсутствие специализированных фреймворков. Стандартная реализация есть в большинстве современных языков программирования «из коробки».

• Общедоступные API. REST идеально подходит для общедоступных API благодаря своей простоте и широкому распространению.
• CRUD-операции (от английского create, read, update, delete). Лучше всего подходит для сервисов, требующих операций создания, чтения, обновления и удаления.
• Связь микросервисов. Используется для сценариев, в которых сервисы должны предоставить endpoints для доступа к данным или работы с ними.

RPC (Удалённый вызов процедур)

• Прозрачность. Вызов удалённой функции выглядит так же, как и вызов локальной функции.
• Синхронность. Обычно вызовы RPC синхронные, то есть клиент ожидает ответа от сервера до продолжения выполнения.
• Типизация. RPC часто строго типизированный, что позволяет проверять корректность данных на этапе компиляции.

1. gRPC

2. Apache Thrift

3. Apache Avro

4. ZeroC ICE

5. JSON-RPC

Архитектура, управляемая событиями (Event-Driven Architecture, EDA)

• Продюсеры генерируют события, а консьюмеры прослушивают и реагируют на них.
• Брокеры являются посредниками между продюсерами и консьюмерами, обеспечивая надёжную доставку событий.
• Потоки событий непрерывны, и их можно обрабатывать в режиме реального времени.

• Масштабируемость. Сервисы могут масштабироваться независимо в зависимости от нагрузки на события.
• Разделение. Сервисы могут работать независимо друг от друга, уменьшая взаимозависимость.
• Обработка в реальном времени обеспечивает аналитику в реальном времени и быстро реагирующие системы.
• Устойчивость к сбоям. Сообщения могут быть поставлены в очередь, что гарантирует, что они не будут потеряны и смогут быть обработаны, когда потребитель будет доступен.

Системы обмена сообщениями

1. RabbitMQ — это брокер сообщений с открытым исходным кодом, использующий протокол Advanced Message Queuing Protocol (AMQP). Он поддерживает различные схемы обмена сообщениями, включая «точка — точка» и «публикация — подписка».
   RabbitMQ подходит для таких задач, как обработка заданий, распределение событий и обработка данных в реальном времени. Он характеризуется высокой доступностью, кластеризацией, гибкой маршрутизацией и пользовательским интерфейсом управления.
2. Apache Kafka — это распределённая потоковая платформа с открытым исходным кодом, предназначенная для обработки сообщений с высокой пропускной способностью и низкой задержкой. Она широко используется для создания конвейеров данных в реальном времени и потоковых приложений.
3. Amazon SQS (Simple Queue Service) — это полностью управляемый сервис очередей сообщений, предоставляемый AWS. Он позволяет разделять и масштабировать микросервисы, распределённые системы и бессерверные приложения. Amazon SQS широко используется для фоновой обработки заданий, асинхронных рабочих процессов и развязки микросервисов.

Выбор правильного метода взаимодействия

1. Латентность — это время, необходимое для прохождения сообщения от отправителя к получателю и обратно. Синхронные методы коммуникации, такие как REST и RPC, обычно имеют более высокую латентность по сравнению с асинхронными методами.
   Выбирайте синхронные методы для задач, где требуется немедленный ответ. Используйте асинхронные методы для некритичных по времени операций, где задержка может быть терпимой или не требуется немедленного ответа на запрос.
2. Консистентность данных — обеспечение целостности данных в распределённых сервисах может быть непростой задачей. Синхронные методы могут обеспечить более надёжные гарантии согласованности, в то время как асинхронные методы могут обеспечить только возможную согласованность.
   Используйте методы синхронного взаимодействия для операций, требующих немедленной согласованности. Асинхронные методы подходят для сценариев, в которых допустима конечная согласованность.
3. Масштабируемость подразумевает способность справляться с растущими нагрузками путём добавления дополнительных ресурсов. Асинхронные методы обычно обеспечивают лучшую масштабируемость, поскольку они разделяют сервисы и могут обрабатывать изменяющиеся нагрузки с помощью очередей сообщений.
   Используйте асинхронные методы для сервисов, которые должны масштабироваться независимо друг от друга и обрабатывать всплески трафика. Используйте синхронные методы для более простых, тесно связанных взаимодействий.
4. Отказоустойчивость — способность системы продолжать работу в случае сбоя. Асинхронные методы обеспечивают более высокую отказоустойчивость, поскольку они буферизируют сообщения и позволяют сервисам обрабатывать их, когда они доступны. Применяйте асинхронную обработку данных для повышения отказоустойчивости и предотвращения потери сообщений при сбоях в работе служб. Синхронные методы требуют надёжной обработки ошибок и механизмов повторных попыток для достижения отказоустойчивости.

Стратегии обеспечения согласованности данных

1. Конечная согласованность гарантирует, что при необходимом времени все реплики данных придут к одному и тому же значению. Этот подход часто используется в распределённых системах, где не требуется немедленная согласованность.
   Подходит для сценариев, в которых высокая доступность и устойчивость к разделениям более важны, чем немедленная согласованность (например, в лентах социальных сетей или каталогах товаров).
2. Строгая согласованность гарантирует, что все операции чтения возвращают последнюю запись. Такой подход необходим, когда требуется строгая точность данных.
   Идеально подходит для финансовых операций, управления запасами и других критически важных операций, где точность данных не может быть нарушена.
3. Партицирование данных подразумевает разделение большого набора данных на более мелкие и управляемые части (партиции), распределённые между несколькими узлами. Эта стратегия может помочь сбалансировать нагрузку и повысить производительность.
   Полезно для крупномасштабных систем, таких как распределённые базы данных, где различные разделы могут управляться независимо друг от друга для обеспечения масштабируемости и производительности. Например, данные о клиентах можно разделять по географическому признаку и держать в дата-центре, наиболее близком к клиенту.

Распределённые транзакции

1. Фаза подготовки, когда координатор отправляет сообщение prepare всем участвующим сервисам с просьбой подготовиться к фиксации транзакции. На что каждый сервис отвечает голосованием (зафиксировать или прервать) в зависимости от того, сможет ли он успешно зафиксировать транзакцию.
2. Фаза фиксации — если все сервисы голосуют за фиксацию, координатор отправляет сообщение о фиксации всем сервисам, указывая им на фиксацию транзакции. Если какая-либо служба голосует за отказ, координатор посылает сообщение об отказе, предписывая всем службам откатить транзакцию.

• Блокировка. Если координатор не справляется, участники могут остаться в неопределённом состоянии, ожидая решения.
• Производительность. Протокол может вносить задержки из-за необходимости многократных обходов между координатором и участниками.

• Неблокируемость. В отличие от 2PC, паттерн Saga не блокирует сервисы, поскольку каждый шаг независим и может быть отменён при необходимости.
• Масштабируемость. Он более масштабируем и устойчив к сбоям, что делает его подходящим для крупномасштабных распределённых систем.

Традиционные методы развёртывания

Контейнеризация

• Пространства имён. Пространства имён обеспечивают изоляцию процессов, гарантируя, что у них есть свой собственный изолированный экземпляр глобальных ресурсов, таких как идентификаторы процессов, сетевые интерфейсы и файловые системы.
• Группы управления (cgroups). Группы управления позволяют управлять и ограничивать ресурсы (процессор, память, дисковый ввод-вывод), которые может использовать контейнерный процесс.
• Объединённые файловые системы. Файловые системы типа OverlayFS позволяют создавать многоуровневые файловые системы и эффективно обмениваться базовыми образами и слоями между контейнерами.

• Согласованность в разных средах: Благодаря инкапсуляции всех зависимостей контейнеры обеспечивают стабильную работу приложений в средах разработки, тестирования и производства.
• Упрощённая разработка и развёртывание: Разработчики могут упаковывать приложения вместе с их зависимостями, что уменьшает проблему «это работает на моей машине».
• Масштабируемость и гибкость: Контейнеры можно легко реплицировать и горизонтально масштабировать, чтобы справиться с изменяющейся нагрузкой, что делает их идеальными для архитектур микросервисов.
• Улучшенное использование ресурсов: Контейнеры имеют малый объём и совместно используют ресурсы, что позволяет более эффективно использовать аппаратное обеспечение по сравнению с виртуальными машинами.
• Расширенные практики DevOps: Контейнеры позволяют использовать такие практики, как непрерывная интеграция/непрерывное развёртывание (CI/CD), инфраструктура как код и автоматизированное тестирование, способствуя более гибкому процессу разработки.

Сине-зелёные релизы (Blue-Green)

Канареечные релизы (Canary)

Скользящие релизы (Rolling)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        ports:
        - containerPort: 80 

• Round Robin
  Эта стратегия последовательно распределяет запросы между доступными экземплярами. Каждый экземпляр получает равную долю запросов в круговом порядке.
  Стратегия проста и эффективна для систем, где все экземпляры имеют схожие характеристики мощности и производительности.
  
• Least Connections
  Эта стратегия направляет запросы к экземпляру с наименьшим количеством активных соединений. Она помогает распределить нагрузку более равномерно, особенно когда есть экземпляры с разной производительностью.
  Least Connections применяется в системах, где экземпляры могут обрабатывать запросы разной сложности и продолжительности.
  
• IP Hash
  Эта стратегия использует хэш IP-адреса клиента, чтобы определить, какой экземпляр будет обрабатывать запрос. Это гарантирует, что запросы от одного и того же клиента будут последовательно направляться к одному и тому же экземпляру.
  Она подходит для сценариев, в которых требуется сохранение сеанса (например, для продолжительных пользовательских сеансов в сервисе с состоянием).
  
• Weighted Round Robin
  Аналогична стратегии Round Rrobin, но с весами, присваиваемыми каждому экземпляру на основе его возможностей или характеристик производительности. Экземпляры с более высокими весами получают больше запросов.
  Такая стратегия идеально подходит для систем, где некоторые экземпляры более мощные и могут обрабатывать большую долю нагрузки.
  
• Случайное распределение
  Запросы направляются к экземплярам случайным образом. Несмотря на свою простоту, эта стратегия может быть эффективной в определённых сценариях.
  Она подходит для сред с равномерно распределёнными экземплярами и когда другие стратегии могут не дать значительных преимуществ.
• Нестандартные алгоритмы балансировки нагрузки
  В некоторых средах могут потребоваться пользовательские алгоритмы балансировки нагрузки, разработанные с учётом конкретных требований, таких как географическое положение, задержка или специфические для приложения показатели.
  Нестандартные стратегии могут использоваться в сложных системах, где стандартные стратегии не отвечают конкретным требованиям или где доступны расширенные метрики для принятия решений о маршрутизации.