index0h

Фреймворков так много как раз потому что требования разные.
Иногда это только роутер, lumen.
Иногда это самовыражение сутедунта, codeigniter.
Иногда это успешная попытка в паттерны, symfony.
Иногда это хороший маркетинг, laravel.
И т.д.

Начните с требований и опишите что вам нужно. Уже от этого стоит отталкиваться.
Если хотите писать не плохой код: https://github.com/index0h/php-conventions

1. НИКОГДА не публикуйте креды к базе!
2. Не используйте подстановку данных в запрос через конкатенацию. Вместо этого используйте плейсхолдеры.
Пример 1 (SQL инъекция):

# Тут заэнкожено: '; DROP TABLE `users`; --
curl -XPOST -H 'Content-type: application/x-www-form-urlencoded' -d'phone=%27%3B%20DROP%20TABLE%20%60users%60%3B%20--'

Пример 2 (phone может содержать массив):

curl -XPOST -H 'Content-type: application/x-www-form-urlencoded' -d'phone[]=+123'

3. Не используйте глобальные переменные. Про это есть множество статтей.
4. Если есть возможность - используйте \PDO, вместо mysqli.
5. Не стоит объявлять функции/классы/трейты/интерфейсы по условию. Вместо этого используйте их по условию, но объявляйте без него.
6. При работе с путями рекомендую пользоваться глобальными, вместо относительных, иначе этот самый путь будет зависеть от скрипта, с которого запустили ваш код, а не от того, где происходит работа с файлами.
7. У вас конкурентно не безопасный код за счет того, что работа с файлами происходит в одном и том же каталоге, с одними и теми же именами файлов. Что будет если запустить два запроса одновременно на вытяжку всех пользователей? В лучшем случае один из запросов просто упадет с ошибкой что не может добавить в архив файл (это второй поток его уже удалил). Если будет запущено 2 запроса например на 1го пользователя и на всех - есть вероятность, что один из них вернет далеко не запрашиваемые данные)).
8. Очень рекомендую разделить вашу обработку на 2 части:
- Первая пусть записывает в файлики данные по пользователям при обновлении данных этих пользователей.
- Вторая - вытягивает вытягивает только id требуемых для архивирования и уже добавляет их в архив. Имя архива стоит делать рэндомным, что бы избежать конкурентного доступа к одному и тому же файлу на запись.
9. getUserses -> getUsers

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

Столкнулся с необходимостью применения трейтов PHP, и тут проблема.

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

Конструктор в трейте - это, не нахожу подходящего цензурного слова, пусть будет табу.

Что касается непосредственно вашей ошибки - смотрите в сторону автолодинга.

https://github.com/index0h/php-conventions почитайте на досуге

как сохранять сообщения, не привязываясь к очереди в отправителе, чтобы при запуске получателей они стали получать эти сообщения?

Создать эксчейндж, создать очереди, забиндить очереди на эксчейндж.

Если способ только декларировать очередь в отправителе, то тогда какой смысл fanout обменника?

Смысл в том, что распределение идет по очередям, а не консьюмерам. Если нет очередей - распределять некуда.

fanout вам не нужен

нормальной архитектурой, качеством кода, нормальным современным процессом с CI/CD и т.д.

От говнопроекта не застрахован никто, вне зависимости, php, java, c#, js, brainfuck...
Чаще всего архитектура, качество кода и вот это вот все развито там, где это критично для бизнеса и бизнес понимает, либо пишем нормально, либо жопа. Но таких, к сожалению, мало. Можете на собесе спросить, какой даунтайм допускается и как часто они происходят. Если адунтайм в минуту надо согласовывать за неделю и более - скорее всего об качестве пекутся. Если даунтайм в пол часа не особо проблема - всем нас*ать))

С одной стороны в требованиях были знания стильно-модно-молодежных Redis, Symfony понимания Git-Flow, Agile и т.д. и там же указаны - знание WP 1С-Битрикс. Как это можно понимать?

Это некомпетентность составившего вакансию, не более.

Как то, что придется занимать разно плановыми задачами?

Задайте вопрос рекрутеру))

Если выделить суть вопроса - как отличить компанию в которой можно будет вырасти в PHP разработчика, а не веб мастера.

Задайте несколько вопросов:
0. Вы продуктовая компания?
1. Что с их точки зрения легаси, какой его процент в проекте и как часто возвращается технический долг?
2. Какой процесс разработки от начала и до конца?
3. Какие стандарты и требования используются?
4. Какое покрытие тестами?

Заводите отдельную таблицу.

CREATE TABLE IF NOT EXISTS `phoneAuthorisationCode` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
    `phoneId` INT UNSIGNED NOT NULL,
-- Код используется для авторизации, по этому хранить его в открытом виде очень плохая идея
    `codeHash` CHAR(16) NOT NULL,
    `createdAt` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
-- Код временный, если expiredAt > CURRENT_TIMESTAMP - он прострочен и использовать его уже нельзя
    `expiredAt` TIMESTAMP NOT NULL,
-- Дату использования кода необходимо указывать. Если это поле не пустое, использовать этот код уже нельзя
    `processedAt` TIMESTAMP DEFAULT NULL,
    PRIMARY KEY (`id`)
)
    ENGINE = InnoDB
    DEFAULT CHARSET = `utf8`;

Мультипоточность в php - штука прикольная, поковырять. Но жить с ней часто довольно болезненно.
Лучше смотрите в сторону очередей и supervisor например.

нет, это инструменты для разных задач.

$_SERVER['REMOTE_ADDR']

post предполагает синхронный ответ на запрос, грубо говоря клиент уже отправил вам запрос и ждет пока ему ответят. Со стороны пыхи вы обрабатываете запрос и вот это самое echo выводит ответ для клиента обратно. Вы не выбираете кому отправить ответ. Но при обработке запроса вы можете решить, показывать ли какие-то данные на конкретно этот запрос, или нет.

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

2. В public нету точки входа index.php, я очень надеюсь что это просто ошибка, а index.php в корне проекта просто забыли удалить.

3. Что делать, если нужно 2 разных подключения к БД, а не одно?

4. Если я правильно понимаю, то что вы называете promise - это DTO + Builder. Очень похоже на лишние сущности.

5. Сессии в файлах - это очень странное решение. Как только вам потребуется завести еще один инстанс - все пойдет по ***де. Обычно сессии хранятся в memcached / redis как раз для того, что бы обеспечить горизонтальное масштабирование.

Очень рекомендую почитать на досуге https://github.com/index0h/php-conventions