Сервисы интроверты
Если вы думаете, как упростить разработку сервисов, то эта заметка для вас.
Основные рекомендации такие:
- Минимизируйте количество контактов сервиса.
- Используйте оркестратор по возможности.
- Не усложняйте логику обработки серийного отказа сервиса.
Минимизация контактов
Качественно написанный сервис имеет несколько типовых промежуточных и финишных коммуникаций. Например:
- Служебные сообщения: alerts (сообщения о нештатных ситуациях), check points, process metrics.
- Чтение и сохранение состояния процесса.
- Специальные сигналы для запуска прочих сервисов.
Проектируйте архитектуру так, чтобы сервис общался с минимальным количеством контрагентов (endpoints), максимально простым образом.
Идеальным вариантом был бы highly available, fault tolerance API Gateway, поддерживающий асинхронные вызовы (т.е. клиенту сразу отвечает OK, а доставку потребителю выполняет самостоятельно в настойчивом варианте).
Использование оркестратора
Применение оркестратора делает сервис пассивным в части кода, обрабатывающего получение задания. Код получается более типовым и простым (особенно, если задание закрепляется за подписчиком), что также ускоряет разработку. Дополнительно, оркестратор помогает строить маппинг данных между сервисами в формате No-Code, что уменьшает зависимость сервисов. То есть, в случае изменения выходного формата вызывающего сервиса реже придется менять API вызываемого сервиса.
Серийный отказ
Если сервис упал, его можно перезапустить, а если он упал несколько раз, то лучше уведомить о серийном отказе службу поддержки, а если он потом заработал, то уведомить еще раз. Прекрасный алгоритм, но сервисы станут проще, если будут просто отправлять alerts и check points, а на ошибку реагировать максимально примитивно. Отследить историю и состояние сервисов можно по логам, с помощью мониторинговой платформы, даже если сервис упал бесшумно или завис.