Сергей Рогожкин

Сейчас напишу немного высокомерно, но опыт позволяет. Уже почти 20 лет в разработке и около 15 в веб.
Надо понимать, что почти все кто используют многочисленные Фреймворки не понимают что такое ООП. А уж тем более, что такое SOLID и т.д.
И поэтому, что бы они не писали, в конце-концов превращается в какашку с костылями.
Да, потом героически проект переписывается с учётом изменений (или ещё чаще умирает) Но, он по прежнему остаётся абсолютно не расширяемым и не поддерживаемым.

И вот мы возвращаемся к Фреймворкам.
Нужно брать тот Фреймворк, который писали с учётом определённых парадигм и принципов. Так как этих вот парадигм, достаточно описанных и изученных не так много (на самом деле их 2.5 штуки), то можно сразу ориентироваться на ООП + MVC(или MVP или MVVM) + SOLID
Если Фреймворк что-то из этого нарушает, то он по умолчанию не может вам дать возможность написать хорошее, расширяемое приложение. А хороший Фреймворк, даже начинающим программистам должен прививать правильные подходы к разработке. Что-бы хочешь, не хочешь, а hello world уже не превращался в ад.

Сразу оговорюсь, что я давно "забил" на Фреймворки. Есть один идеальный — это Pyramid. А оцениваю любой продукт по документации. Там сразу видны все огрехи и косяки. Буду писать и параллельно смотреть в доки.

Larvel
Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах. На этом можно уже, даже и остановиться. ООП, по большому счёту тут нет. Суть ООП в использовании объектов. Тут же класс выступает в качестве пространства имён функций.
Раз нет ООП, то и нет всей теории и принципов связанных с ним.
А раз под этим Фреймворком не заложено никакой теории, то в 99% случаев можно сказать, что на нём что-то правильно, написать невозможно.

Если взглянуть глубже, то открывается ещё больше ада:
ActiveRecord.
Плох по умолчанию. С ним очень тяжело контроллировать целостность данных. Вам нужно придумать слой абстракции, где вы будете транзакционно записывать все данные вне бизнес логики. Фреймворк вам тут не поможет. Он предложит это делать в экшене (контроллере). И тут вы столкнётесь, что при написании чего-то сложнее чем бложик, вы будете терять целостность. Ибо бизнес логика и работа БД будет в одном методе. Отладка будет усложняться, ошибок плодиться и т.д.
И не зависит это от программистов. Шаблон сам по себе провоцирует ошибаться.
Далеко за примерами ходить не нужно, уже треш.

Чем больше примеров я смотрю, тем больше не понимаю, как все это дело расширять. Как вставлять прозрачно через весь проект свои собственные аспекстные решения. Например RBAC. Или, если нужно, логику работы приложения отделить от БД и когда нужно, подставлять необходимую реализацию.
Или сделать работу всех экшенов в рамках клиента, но производить авторизацию по пользователю(сотруднику)

Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.
Повеситься. Сложность приложения зашкалит.

Symfony
Только при выходе 2 версии я работал с этим чудом. Разработчики писали его под хапйом dependency injection. Мало того, что они взяли не самую хорошую стратегию для реализации всего костяка фреймворка, так ещё и сделали её не правильно.
Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
Строчку, М**Ь ЕЁ! Не интерфейс — строчку!
И знаете чем это аукнется? А тем, что при разработке своего приложения или очередного бандла, вам будет говорить, что в контейнере лежит что-то не то и вы подохните в конфигурационных настройках. А все потому что, подход: ВСЁ через DIC — строго навязывается.
Расширение этого чуда, тоже причинит вам массу головной боли. Ведь, зачастую, вы будете работать с классами, которые ждут не интерфейс, а что-то из контейнера с ключём "я_твой_дом_шатал".

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

Но, по правде говоря, слепить что-то годное возможность есть.
Если взять микро ядро symfony, прикрутить Doctrine, то получится что-то годное.
Но встаёт вопрос. А зачем вообще symfony, если можно взять doctrine и написать все остальное свое?
И тут вы окажетесь правы — незачем.

Ситуация с Symfony в enterprise очень схожа с ситуацией с Django. Повидал уже с десяток проектов, где последнюю брали для больших приложений. В итоге от Django оставались рожки да ножки. Всю её переписывали.
Спрашивается — и зачем? Просто потратили кучу времени.

Так что, если нужен суровый enterprise. Что бы писать что-то большое, с возможностью расширения — берите Pyramid и переходите на python.
Ничего, даже близко с пирамидкой, по возможностью расширения, даже близко не лежало.

5000 запросов в 1 секунду на PHP скрипт? Давайте начнем с PHP, может, а не с nginx. Считаете время ответа одного запроса T, считаете количество воркеров PHP N = 5000*T. Далее запускаете это число воркеров, делаете одновременные запросы на все воркеры и путем увеличения числа ядер процессора добиваетесь времени ответа сервера такого же, какой был на одном воркере. Ну, это без учета того, что если используется СУБД - ее время ответа тоже нужно будет исправлять на заданной конкурентности. Не хватает ядер, добавляем сервера.

1. Посмотрите пристальнее на BEM, они разработали не только подход, но и многие утилиты под разработку. Въехать сложно, но есть на что посмотреть.

2. TARS - сборщик фронтенда от ДубльГис. Очень интересная штука, позволяет не только внедрить модульность, но и избавить программиста от многих задач. Работает она на основе того же gulp'а, но создавать сборки не нужно, нужно только в конфигах указать, какие препроцессоры использовать, и дальше TARS уже сам разберется.
В TARS используется методология БЭМ, но в отличие от нативного БЭМ-сборщика от яндекса, в TARS гораздо проще въехать и начать работать.
Статья на хабре - она не очень, если честно. Всех фишек TARS не раскрывает.
Документация
Использование вышеуказанного Bemto под TARS позволит дополнительно привнести ясности в код.

Symphony копайте, вам на год хватит.
UPD:ответ вас позлил наверное но я Объясню. Yii хорош, но symphony лучше. Копайте его, залейте клона с официального гита себе и разберитесь что и как работает. Не узнайте как с ним работать, а именно нарежьте его нано скальпелем до переменных, и посмотрите как он устроен. На том же гите поищите проекты на нем и разберитесь как и почему. Если уверены в своих силах закомитьте что нибудь, мелкую фичу. Почему symphony а не что-то ещё? Разберёшся с ним - с остальными проблем не будет. Конечно можно с дуру взять и смотреть Zend, но пожалейте свои мозги и время,года 3-4 на понимание уйдёт. Почему фреймворк а не книги или что-то ещё? Ну как вам сказать, книги это хорошо и читать их нужно, но фреймворки и примеры работ это здесь и сейчас, это то что востребовано то что вас прокормит, а книги можно почитать для общего развития авось где-то пригодится. Но это я именно об php и структуризации кода. Алгоритмы, архитектуры бд и т.д. закидывать не лзя, это читайте.

Вначале, все слова записываем в виде хеша так, чтобы буквы шли по-порядку, но повторные - не повторялись. 'мама мыла раму' => 'ма ылру'
Можно дополнительно создать еще один кэш и отсортировать в порядке убывания кол-во повторов букв:
Приведём новый пример: 'мыла раму мама' (переставим слова местами)
'мыла раму мама' => [м-4][ы-1][л-1][а-4][(пробел)-2][р-1][у-1]=>'ма ылру' (предыдущий пример останется без изменений...)
и поиск вести по половинам хэша (при нечетном кол-ве -округляем в большую сторону) введённой строки 'ма ылру':
1. При не найденных совпадениях, порядок такой: 'ма ы'=>'ма'=>'м'
2. При найденных совпадениях, порядок такой: 'ма ылр'=>'ма ыл' Как выдача будет нулевая - берём предыдущий МИНИМАЛЬНЫЙ! результат выдачи.

Таким образом можно отловить с большей вероятностью пропущенные буквы при вводе.

Можно составить отдельную таблицу по всем словам и привязать их к основным данным.

Затем выборка этажеркой:
1. Преобразуем так же вводимую строку и выбираем LIKE 'ма мыл%'
(возможно несколько выборок с проверкой пропущенной буквы) запоминая результат выборки.
2. По этому результату ищем полную строку с тем же LIKE 'мама мыла раму%'
3. При следующем поиске, если хэш не уменьшился и символы в диапазоне длины предыдущего хэша не изменились - мы ищем СРАЗУ ЖЕ! по результату п.1 (и снова запоминаем результат), экономя время (т.е. поиск как бы идёт по предыдущему кэшу).

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

Не нравится, что в итоге заводится куча тегов, веток, может есть альтернативное решение для такой задачи?

На самом деле это оптимальное решение. У вас создается релизная ветка в которую в случае проблем именно на этой платформе будут вливаться фиксы, не мешающие другим. Далее когда релизный образ оттестирован и дан зеленый свет - они размазывается по проду. То что тегов много - да какая разница?)) У вас есть возможность получить состояние любой сборки.

Схема кажется немного избыточна nginx->nginx->php, в итоге на сервере дофигища разных процессов, особенно nginx.

Тут все зависит от того, можно ли отдавать клиенту доступ на прямую к nginx2. Если нельзя - ваша схема вполне норм. Если же можно - тогда стоит это делать, смотрите в сторону своего балансировщика, который будет отдавать клиенту сервер, который А - жив, Б - минимально нагружен и штук типа consul.

ansible забирает из гита исходный код, грузит на сервер, в контейнеры исходники пробрасываются через volume.

Зачем? Контейнер как бы иммутабельный и все такое. Если у вас там кучка статики подсасывается не под git - смотрите в сторону mogilefs и т.д. Безусловно, для разработки volume - самое оно, но для прода - ну такое..., должна быть веская причина.

Попробуйте почитать тут:
Очень годное руководство по микросервисам: https://www.nginx.com/blog/introduction-to-microse...
node.js: codewinds.com/blog/2015-11-14-microservices-nodeve... (https://github.com/jeffbski/microservices)

Проекты не делаю на данной CMS, но работал с ней. Узнал о ней 2 года назад. Она сейчас мало известна, так как находится в бета-тестировании. Скоро, насколько я знаю, будет релиз. За бета-тестирование это они хорошо развили эту cms. Код шикарен, функционал - шикарен, внешний вид - шикарен и удобен. Глаза радуются, когда работаешь с данной cms. Можно делать те же сайты-визитки, практически не влезая в код, что очень удобно и здорово. Да, и большое преимущество, что он сделан на Laravel. Повторю: скоро релиз, а они уже хорошо всё сделали. После релиза, думаю, будет ещё много чего классного. Поэтому советую Вам хотя бы попробовать сделать пару проектов на нём. Если действительно всё хорошо получится, то почему бы не взять его для разработки Ваших заказов?

Для начала неплохо бы посмотреть документацию, а именно эту.

Затем можно посмотреть доклады по этой теме, например: видео + статья

CRM незнаю, но большинство нужд можно покрыть простым и бесплатным Trello & Trello Apps