GitHub
VIII. Конкурентність
Масштабуйте застосунок за допомогою процесів
Будь-яка комп’ютерна програма після запуску представлена одним або декількома процесами. Веб-додатки мають різні форми виконання процесів. Наприклад, PHP-процеси виконуються як дочірні процеси Apache, які запускаються в разі потреби в залежності від навантаження. Java-процеси використовують протилежний підхід: JVM забезпечує один масивний мета-процес, який резервує велику кількість системних ресурсів (процесора і пам’яті) під час його запуску, і керує конкурентністю всередині себе за допомогою потоків виконання (threads). В обох випадках запущені процеси видимі для розробників застосунку мінімально.
В застосунку дванадцяти факторів, процеси є сутностями першого класу. Процеси в застосунку дванадцяти факторів взяли сильні сторони від моделі процесів UNIX для запуску сервісів. Використовуючи цю модель, розробник може спроектувати свій застосунок таким чином, що для обробки різних робочих навантажень необхідно призначити кожному виду робіт свій тип процесу. Наприклад, HTTP-запити можуть бути оброблені за допомогою веб-процесу (web process), а тривалі фонові завдання оброблені робочим процесом (worker process).
Це не виключає можливості використання індивідуального мультиплексування для окремих процесів через потоки виконання віртуальної машини або асинхронні/подієві моделі в таких інструментах, як EventMachine, Twisted або Node.js. Але індивідуальна віртуальна машина може масшабуватися тільки обмежено (вертикальне масшабування), тому застосунок також повинен мати можливість бути запущеним як декілька процесів на декількох фізичних машинах.
Модель, побудована на процесах, дійсно показує себе з найкращого боку, коли постає необхідність масштабування. Відсутність розділених даних і горизонтальне розділення процесів застосунку дванадцяти факторів означає, що додавання більшої конкурентності є простою і надійною операцією. Масив типів процесів і кількість процесів кожного типу називається формацією процесів.
Процеси застосунку дванадцяти факторів ніколи не мають демонізуватися та записувати PID-файли. Замість цього вони мають покладатися на менеджер процесів операційної системи (наприклад, systemd, розподілений менеджер процесів на хмарній платформі, або в процесі розробки на такий інструмент, як Foreman) для керування потоком виведення, реагування на падіння процесів і обробку ініційованих користувачем перезавантаження чи завершення роботи.