Бэкенд на Elixir Phoenix для конкурентного API от процессов BEAM и супервизоров до каналов реального времени

Серверная разработка годами живёт в конфликте: потоки тяжёлые, их мало, любой общий ресурс это замок, а любой зависший запрос это очередь возмущения. На этом фоне виртуальная машина BEAM выглядит прибывшей из другого мира: процессы здесь весят килобайты, их миллионы, падение одного не трогает соседей, а перезапуск упавшего это работа дерева надзора, а не человека с пейджером. Elixir дала этому миру современный синтаксис, Phoenix дал каркас для веба, и связка стала одним из самых честных выборов для API с тяжестью одновременности: чаты, телеметрия, игры, биржевые ленты, всё что живёт на тысячах одновременных соединений.

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

Почему для конкурентного API выбирают BEAM и что это даёт

Конкурентность на классических рантаймах это работа с дефицитом: ядер мало, потоков мало, блокировки повсюду, и архитектура выстраивается вокруг экономии дефицита. BEAM строится вокруг изобилия: планировщики по ядру, процессы дешёвые настолько, что на одну подключённую websocket-сессию заводится свой маленький мир, и переключение контекста это манипуляция указателем, а не жертва операционной системе. Изобилие меняет дизайн: вместо пула соединений на поток, вместо очередей на общий ресурс, вместо блокировок на сообщения.

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

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

Четвёртое свойство это распределённость из коробки: нодам платформы доступна связь по имени процесса между машинами, и горизонтальное масштабирование начинается без внешней шины. Слабости тоже честны: сырая вычислительная мощь на одном потоке не конёк платформы, тяжёлую математику выносят в нативные порты, и выбор BEAM это выбор про одновременность, а не про такты.

Процессы вместо потоков миллионы маленьких изолированных миров

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

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

defmodule MyApp.Worker do
  use GenServer

  def start_link(opts) do
    GenServer.start_link(__MODULE__, opts, name: __MODULE__)
  end

  def push(item) do
    GenServer.cast(__MODULE__, {:push, item})
  end

  @impl true
  def handle_cast({:push, item}, state) do
    {:noreply, [item | state]}
  end
end

Общие behaviours дают структуру: генерический сервер для состояния с синхронными и асинхронными вызовами, менеджер задач для конечных автоматов, брокер событий для потоков сообщений, и всё это библиотека OTP, а не рамки для самодеятельности. Умение платформы это не миллионы голых процессов, а миллионы процессов, живущих по устойчивым образцам, и образцы упакованы в язык фреймворка платформы.

Супервизоры и философия пусть упадёт дерево отказоустойчивости по построению

Философия платформы звучит провокационно: процесс, столкнувшийся с ошибкой, не ловят и не обхаживают, ему позволяют упасть, а супервизор запускает нового с чистого состояния. Логика инженерная: чистый перезапуск проще и надёжнее запутанной логики восстановления, известное чистое состояние лучше полу-починенного, и дерево надзора строит систему, где отказ периферии не каскадится в отказ ядра.

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

defmodule MyApp.Supervisor do
  use Supervisor

  def start_link(init) do
    Supervisor.start_link(__MODULE__, init, name: __MODULE__)
  end

  @impl true
  def init(_init) do
    children = [
      MyApp.Repo,
      MyAppWeb.Endpoint,
      {MyApp.PubSub, name: MyApp.PubSub},
      MyApp.Worker
    ]
    Supervisor.init(children, strategy: :one_for_one)
  end
end

Пороги перезапуска настраиваются по интенсивности: частые падения одного ребёнка не должны ронять узел, и стратегия эскалации прекращает бесконечные рестарты переданием проблемы выше. Системы, где каждая неисправность локализована своим супервизором, переживают частичные отказы так, как пользователь и не заметил, и это спокойствие и есть измеримый результат философии.

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

Phoenix как каркас API конвейер Plug контексты и Ecto

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

Контроллеры остаются тонкими по построению: контроллер разбирает запрос, зовёт контекст, формирует ответ, и бизнес-логика живёт в контекстах, модулях предметной области, которые не знают про веб. Контекст это фасад предметной области с ясными функциями, и веб оказывается одним из клиентов домена, рядом с каналами, задачами и скриптами.

defmodule MyAppWeb.OrderController do
  use MyAppWeb, :controller

  def show(conn, %{"id" => id}) do
    json(conn, Contexts.fetch_order(id))
  end

  def create(conn, params) do
    case Contexts.create_order(params) do
      {:ok, order} ->
        json(conn, order)

      {:error, changeset} ->
        conn
        |> put_status(422)
        |> json(%{errors: translate(changeset)})
    end
  end
end

Слой хранения живёт на Ecto: описания схем, наборы изменений с валидацией, репозиторий с транзакциями, и набор изменений заменяет обезличенные объекты ошибки на структуру с перечислением проваленных полей. Ошибки домена приезжают в контроллер как значения, и сопоставление с образцом в связке с наборами изменений делает ветку ошибки такой же прямолинейной, как ветка успеха.

Каналы реального времени сокеты темы и присутствие участников

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

Протокол каналов выше сырого сокета: клиент подключается к сокету с токеном, присоединяется к темам, шлёт события и получает рассылки, и восстановление после обрыва встроено в протокол переприсоединением с восстановлением подписок. Опознание на сокете делает приватные темы приватными, и тема с идентификатором комнаты получает проверку прав в момент присоединения.

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

Обратное давление и очереди GenStage для честной нагрузки

Система из миллионов процессов всё равно подчиняется законам спроса и предложения: источник, производящий быстрее потребителя, копит почтовые ящики, и честная система обязана сообщать источнику о темпе потребителя. GenStage это паттерн платформы для конвейеров с обратным давлением: потребитель заявляет спрос, производитель выдаёт ровно заявленное, и конвейер течёт со скоростью самого медленного звена без скрытых груд.

Паттерн применяется к типовым местам API: пакетная рассылка уведомлений с темпом внешнего сервиса, конвейер обогащения записей, экспорт больших выписок по частям, и везде источник не убегает от потребителя, а шагает с ним. Композиция стадий строит графики обработки: разбор, трансформация, запись, с независимым масштабированием каждой стадии по нагрузке.

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

Эксплуатация релизы кластеризация и наблюдение живой системы

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

Кластеризация узлов открывает именованные процессы между машинами: брокер сообщений платформы связывает узлы, и темы каналов рассылаются на все машины кластера без внешнего слоя. Сетевой фундамент связи узлов выбирается под инфраструктуру, а семантика остаётся в приложении, и горизонтальное масштабирование живого API сводится к запуску ещё одного узла и включения его в кластер.

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

Порядок внедрения Phoenix API свёрнут в короткую лестницу:

1. собрать скелет с деревом надзора и контекстами домена;
2. вынести логику в контексты и держать контроллеры тонкими;
3. включить экспорт метрик и панель наблюдения с первого релиза;
4. завести процессы на соединения и темы, мониторить очереди ящиков;
5. добавить каналы для событий реального времени и присутствие участников;
6. уложить тяжёлые конвейеры в стадии с обратным давлением;
7. выпускать релизами, кластеризовать узлы и разбирать падения по журналам.

BEAM и Phoenix возвращают серверной разработке то, чего ей хронически не хватает: спокойствие под одновременностью. Падение это перезапуск, нагрузка это процессы, поток это темп потребителя, и API, собранный по этой лестнице, держит тысячи соединений так же скучно, как классический сервер держит десяток, и именно эта скучность под нагрузкой остаётся главным инженерным аргументом стека.