Технология «Функции как сервис» (FaaS), часто ассоциируемая с «бессерверными» вычислениями, произвела революцию в том, как мы развёртываем код. В контексте событийно-управляемых микросервисов (EDM) FaaS выступает не просто как инструмент для обработки веб-хуков, а как мощный механизм для создания реактивных, эластичных и экономически эффективных компонентов.

По сути, FaaS-решение можно представить как базовую связку «производитель-потребитель», которая регулярно завершает свою работу и освобождает ресурсы. Но чтобы вписать этот паттерн в строгую архитектуру EDM, необходимо понимать специфику его жизненного цикла, управления состоянием и масштабирования.

Это девятая глава цикла. Она опирается на главу II (партиционирование, consumer groups), главу V (state stores, rebalance), главу VII (состояние, TTL) и главу VIII (оркестровка, Saga). Здесь мы разберём, как эти механизмы преломляются в мире FaaS.

IЗолотые правила проектирования FaaS-микросервисов

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

IIАнатомия запуска: триггеры и жизненный цикл

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

Основные типы триггеров

IIIХолодный и тёплый старт

При первом запуске или после долгого простоя функция проходит через «холодный старт»: провайдер выделяет контейнер, загружает код и устанавливает соединения с брокером событий. Это занимает время и может вызвать задержки.

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

Практические меры против cold start

• Provisioned concurrency (AWS Lambda) — держать N экземпляров всегда тёплыми. Стоит денег, но устраняет cold start.
• Минимальный размер кода — меньше кода, быстрее загрузка. Убирайте неиспользуемые зависимости.
• Инициализация вне handler'а — соединения с БД, Kafka-клиенты создавать в init-блоке, а не в каждой инвокации.
• Runtime с быстрым стартом — Go, Rust, Node.js стартуют быстрее, чем Java или .NET.

IVEvent-source mapping: как функция подключается к потоку

В AWS Lambda event-source mapping — это ключевой механизм, который связывает источник событий (SQS, Kinesis, DynamoDB Streams, MSK) с функцией. Понимание его настроек критично для production.

Partial batch response

Без partial batch response, если один event в batch падает, весь batch переобрабатывается — включая уже успешные события. Это ведёт к дубликатам.

public class Handler implements RequestHandler<SQSEvent, SQSBatchResponse> {
    @Override
    public SQSBatchResponse handleRequest(SQSEvent event, Context context) {
        List<SQSBatchResponse.BatchItemFailure> failures = new ArrayList<>();
        for (SQSEvent.SQSMessage msg : event.getRecords()) {
            try {
                processMessage(msg);
            } catch (Exception e) {
                failures.add(new SQSBatchResponse.BatchItemFailure(msg.getMessageId()));
            }
        }
        return new SQSBatchResponse(failures);
    }
}

Только события из failures будут переобработаны. Успешные — зафиксированы и удалены из очереди.

VПарадокс состояния в бессерверном мире

Главная философия FaaS — отсутствие состояния (stateless). Функция эфемерна: она запускается, выполняет работу и исчезает вместе со своей локальной памятью. Но как быть, если бизнес-логика требует агрегации или хранения данных?

В классическом EDM-подходе состояние выносится вовне. Функция явно подключается к внешним хранилищам (Redis, DynamoDB, CosmosDB) через сеть. Это снижает гибкость масштабирования, так как провайдеру FaaS приходится учитывать сетевые задержки и лимиты внешних БД, но зато позволяет масштабировать функции горизонтально без ограничений.

VIAzure Durable Functions: stateful FaaS

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

Три типа функций в Durable Functions

Saga на Durable Functions

[FunctionName("OrderSaga")]
public static async Task<string> RunOrchestrator(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    try {
        await context.CallActivityAsync("ReserveInventory", order);
        await context.CallActivityAsync("ChargePayment", order);
        await context.CallActivityAsync("ShipOrder", order);
        return "completed";
    } catch (Exception) {
        await context.CallActivityAsync("ReleaseInventory", order);
        await context.CallActivityAsync("RefundPayment", order);
        throw;
    }
}

Ключевое: состояние orchestrator персистится автоматически. При сбое worker'а — другой worker подхватывает с того же шага. Это ровно тот механизм, который в Temporal реализуется через durable execution (глава VIII).

Human-in-the-loop

using (var timeoutCts = new CancellationTokenSource())
{
    var approvalTask = context.WaitForExternalEvent<bool>("Approval");
    var timeoutTask = context.CreateTimer(
        context.CurrentUtcDateTime.AddHours(24),
        timeoutCts.Token);

    var winner = await Task.WhenAny(approvalTask, timeoutTask);
    if (winner == approvalTask)
    {
        // Human approved
    }
    else
    {
        // Auto-compensate
    }
}

VIIОркестровка vs хореография в FaaS

Когда одна функция должна передать эстафету другой, возникает вопрос координации. Здесь мы возвращаемся к паттернам из главы VIII, но с поправкой на эфемерность FaaS.

public int orchestrationFunction(Event[] events, Context context) {
    for (Event event : events) {
        // Строгий синхронный вызов
        Result resA = invokeFunctionA(event);
        Result resB = invokeFunctionB(event, resA);

        // Публикуем финальный результат
        producer.produce("Output-Stream", composeOutput(resA, resB));
    }
    // Сообщаем фреймворку, что можно зафиксировать смещения
    context.success();
    return 0;
}

VIIIИдемпотентность FaaS-функций

Функция может быть вызвана повторно: retry от провайдера, at-least-once доставка, partial batch failure. Как гарантировать, что повторный вызов не создаст дубликатов?

Три подхода к идемпотентности

1. Idempotency key в заголовке. Для HTTP-триггеров — передавать Idempotency-Key в заголовке (Stripe, Adyen поддерживают нативно). Для SQS — использовать MessageId как ключ.
2. Conditional writes. Для DynamoDB — attribute_not_exists(event_id) в condition expression. Для PostgreSQL — INSERT ... ON CONFLICT DO NOTHING.
3. Дедупликация в state store. Хранить обработанные event_id в Redis с TTL (например, 24 часа). Перед обработкой — проверка, после обработки — запись.

// DynamoDB conditional write
PutItemRequest request = PutItemRequest.builder()
    .tableName("processed-events")
    .item(Map.of(
        "event_id", AttributeValue.builder().s(eventId).build(),
        "processed_at", AttributeValue.builder().n(String.valueOf(now)).build()
    ))
    .conditionExpression("attribute_not_exists(event_id)")
    .build();

try {
    dynamoDb.putItem(request);
    processEvent(event);  // только если condition passed
} catch (ConditionalCheckFailedException e) {
    // Уже обработано — пропустить
}

IXМасштабирование и ловушка «виртуального тупика»

FaaS предоставляет невероятные возможности для горизонтального масштабирования. Если порядок событий не важен (например, обработка очереди), провайдер может запустить тысячи экземпляров функции одновременно.

Но если вы работаете с партиционированными потоками событий, где порядок критичен, максимальный уровень параллелизма жёстко ограничен количеством разделов (partitions) в потоке.

Три способа избежать тупика

XVPC и network latency

Если функция работает внутри VPC — она теряет доступ к managed-сервисам (S3, DynamoDB, SQS) без NAT Gateway или VPC Endpoint. Это добавляет latency и стоит денег.

Правило: если функция не требует доступа к ресурсам внутри VPC (RDS, ElastiCache), не помещайте её в VPC. Это упрощает архитектуру и снижает latency.

XICost model FaaS: когда это дешевле контейнеров

FaaS оплачивается за:

• Количество вызовов — обычно $0.20 за 1M вызовов.
• GB-seconds — память × время выполнения.
• Cold starts — каждая инициализация считается как вызов + GB-seconds.
• Network egress — трафик между регионами и в интернет.

XIITesting FaaS-функций

Тестирование FaaS — отдельная дисциплина. Функции эфемерны, зависят от триггеров и внешних сервисов.

XIIIСравнение провайдеров FaaS

XIVЧеклисты и связь с циклом

Связь с предыдущими главами

Чеклист проектирования FaaS-микросервиса

• Функция принадлежит одному ограниченному контексту
• Offset фиксируется ПОСЛЕ успешной обработки
• Partial batch response включён для потоковых источников
• Failure destination (DLQ, SNS) настроен
• Инициализация соединений вне handler'а (reuse тёплых экземпляров)
• Идемпотентность через idempotency key / conditional write / дедуп-таблицу
• State вынесен во внешнее хранилище (Redis, DynamoDB)
• Для долгих процессов — Durable Functions или workflow engine
• Ordering гарантирован через оркестровку, если порядок критичен
• Автомасштабирование с гистерезисом, а не агрессивное
• Static partition assignment там, где нагрузка предсказуема
• Batch size согласован с lifespan функции
• Функция вне VPC, если не нужен доступ к VPC-ресурсам
• Стоимость оценена: FaaS vs контейнеры
• LocalStack / SAM Local для интеграционных тестов

Ключевые выводы главы

1. FaaS идеален для дискретных событий — очереди, вебхуки, реактивное обогащение.
2. State выносится вовне. FaaS stateless по философии; состояние — во внешних stores с network latency.
3. Durable Functions (Azure) — stateful FaaS с автоматическим сохранением состояния. Реализуют Saga с human-in-the-loop.
4. Event-source mapping — ключ к production. Batch size, batch window, partial batch response, DLQ.
5. Идемпотентность — обязательна. Idempotency key, conditional writes, дедуп-таблица с TTL.
6. Rebalancing deadlock — реальная ловушка. Гистерезис, static assignment, cooperative sticky assignor.
7. Ordering в хореографии нарушается при параллельном запуске. Оркестровка — только способ сохранить порядок.
8. VPC latency — плата за доступ к RDS/ElastiCache. Не помещайте функцию в VPC без необходимости.
9. Cost model — FaaS дешевле при переменной нагрузке и редких триггерах, дороже при постоянной высокой нагрузке.
10. Testing — LocalStack, SAM Local для интеграционных тестов. Mock events — для unit.

Глава IX цикла «Событийно-управляемая архитектура». Источники: AWS Lambda, Azure Durable Functions, GCP Cloud Functions, Cloudflare Workers, LocalStack, AWS SAM, практические кейсы production-систем.