Существует несколько методов работы с повторяющимися сообщениями: • добавление в сообщения идемпотентных дескрипторов; • отслеживание и отклонение дубликатов
Стандарт REST обладает множеством положительных качеств. • Он простой и привычный. • API на основе HTTP можно тестировать в браузере, используя, к примеру, расширение Postman, или в командной строке с помощью curl (при условии, что вы применяете JSON или другой текстовый формат). • Он имеет встроенную поддержку стиля взаимодействия вида «запрос/ответ». • Протокол HTTP, естественно, дружествен к брандмауэрам. • Он не нуждается в промежуточном брокере, что упрощает архитектуру системы. Однако использование REST имеет и недостатки. • Он поддерживает лишь стиль взаимодействия вида «запрос/ответ». • Степень доступности снижена. Поскольку клиент и сервис взаимодействуют между собой напрямую, без промежуточного звена для буферизации сообщений, они оба должны работать на протяжении всего обмена данными. • Клиенты должны знать местонахождение (URL) экземпляра (-ов) сервиса. Как описывается в подразделе 3.2.4, это нетривиальная проблема для современных приложений. Для определения местонахождения экземпляров сервисов клиентам приходится использовать так называемый механизм обнаружения сервисов. • Извлечение нескольких ресурсов за один запрос связано с определенными трудностями. • Иногда непросто привязать к HTTP-командам несколько операций обновления. Несмотря на эти недостатки, REST считается стандартом де-факто для построения API, хотя у него есть несколько любопытных альтернатив. GraphQL, к примеру, реализует гибкое и эффективное извлечение данных (этот стандарт обсуждается в главе 8, в которой речь пойдет также о шаблоне API-шлюза). Еще одна альтернатива REST — технология gRPC. Посмотрим, как она работает
для управления транзакциями лучше применять совсем другой подход — шаблон «Повествование». Повествование — это последовательность локальных транзакций, которые координируются путем обмена сообщениями. Повествования сложнее традиционных ACID-транзакций, но они хорошо подходят для многих ситуаций. У них есть одно ограничение — отложенная согласованность (eventual consistency). Если вам нужно, чтобы данные обновлялись автоматически, они должны находиться в пределах одного сервиса, что может помешать декомпозиции.
Шаблон «Декомпозиция по поддомену» Определяет сервисы в соответствии с поддоменами в DDD. См. microservices.io/patterns/decomposition/decompose-by-domain.html.
Шаблон «Разбиение по бизнес-возможностям» Определяет сервисы, соответствующие бизнес-возможностям. См. microservices.io/patterns/decomposition/decompose-by-business-capability.html.
Использование микросервисной архитектуры делает выпуск начальных версий довольно трудным. Стартапам почти всегда лучше начинать с монолитного приложения.
микросервисная архитектура существенно усложняет администрирование. В промышленной среде приходится иметь дело с множеством экземпляров разнородных сервисов. Для успешного развертывания микросервисов требуется высокая степень автоматизации. Вы должны использовать технологии следующего плана: • инструменты для автоматического развертывания, такие как Netflix Spinnaker; • общедоступную платформу PaaS, такую как Pivotal Cloud Foundry или Red Hat OpenShift; • платформу оркестрации для Docker, такую как Docker Swarm или Kubernetes.
Сервисы должны использовать механизм межпроцессного взаимодействия. Это сложнее, чем вызывать обычные методы. К тому же ваш код должен уметь справляться с частичными сбоями и быть готовым к недоступности или высокой латентности удаленного сервиса.
