Сергей: а вы можете подсказать, как сделать чтобы внутреннее состояние системы не нарушилось? У меня похожая задача. Мне нужно записать данные в бд и через определенное время выполнить с ними некие действия. Как можно гарантировать, что при записи данных в бд создастся и сообщение в rabbitmq? Чтобы избежать ситуации, когда данные в бд записались, а сообщение в rabbitmq не создалось. То есть мне нужна атомарность, либо всё (запись данных и сообщение в rabbitmq) либо ничего. Это можно как-то сделать? В качестве бд используется mysql.
На PHP можно писать всё тоже самое, что на питон и руби. Не вводите людей в заблуждение. Демоны на PHP пишут. PHP-PM https://github.com/php-pm/php-pm позволяет любой php-фреймворк поднять как демон с несколькими воркерами. А работает он поверх ReactPHP reactphp.org который является аналогом node.js платформы в мире PHP. Кроме того, PHP 7 производительнее и питона и руби blogerator.ru/page/php-7-kritikujte-dalshe-a-my-bu...
Не пишите, о языке, знания о котором у вас уже давно устарели.
Дмитрий Макаров: Да я уже узнал. В яндексе пишут код, загружают его на тестовый сервер и там уже проверяют как это работает в браузере и прогоняют функциональные тесты. Так сделано из-за того что, нужно много всего настраивать, чтобы поднять проект локально.
Дмитрий Макаров: Я знаком с этим всем. Это подходит только для юнит-тестирования. Я же спрашивал, как локально проверить результат в браузере и писать функциональные тесты. Ни что из выше вами перечисленного, в этом вообще никак не поможет.
Так я думаю, что в этой сервисной архитектуре, можно же сделать какую-то систему сборки. Есть у нас сервис яндекс.фотки, с зависимостью от яндекс.паспорт, мы вытягиваем репозиторий с проектом яндекс.фотки и собираем сервис, в результате чего, нам доставляются необходимые зависимости для этого сервиса.
Тестовые сервера, для разработки это всё не работает. Там что-то вечно будет падать/не работать/ломаться и работа встанет. Пусть тестовые сервера используются для того, для чего они предназначены.
dtony: требуют так как в рунете сейчас распространен подход "classic web app", когда бекенд занимается генерацией html кода. Со временем, в любом случае, смещение произойдет в сторону разделения бекенда и фронтенда. Сегодня иногда встречается, что ищут бекендера для RESTful api, ничего из фронтенда не требуют, но пока что редко конечно. Наверное для бекендера лучше вложиться в чтение rfc2616 (http), rfc6749 (oauth 2.0), rfc6455 (websocket), поизучать что-то в области асинхронного программирования и посмотреть фреймворки для реализации stateless серверов и фреймворки/компоненты для реализации stateful серверов, на том языке/платформе с которым планируете работать. В недалеком будущем, будете специалистом на вес золота.
А так придется пилить какие-нибудь убогие интернет-магазины с убогим кодом в убогой веб студии, за убогую зарплату.
P/S завидую вам, по поводу английского, я вот могу только читать и то далеко не всё, хотя не многим наверное вас младше, мне 25.
Ерунда. Достаточно просто нормально настроить веб-сервер. В nginx например проксировать запрос к php-fpm если только location ~ \.php$ а статику отдавать напрямую.
Станислав Макаров: ну это понятно, я так же делал, чтобы равномерно распределять файлы по директориям, но это в контексте одного сервера. А хотелось бы видеть пример шардинга по хешу на много серверов. Вот вы сами сказали, что решардинг дорогая операция, а в вашем подходе, делать его придется каждый раз когда добавляется новая нода. Это одна из проблем. Также все сервера разные по своим характеристикам. На одной машине может быть объем жесткого диска в 1ТБ, а на другой 500ГБ. Представьте, что на машине с 500ГБ занятно все дисковое пространство, а на машине с 1ТБ его еще полно, но ваш алгоритм по хешу высчитывает, что вот этот конкретный файл нужно сохранить на машину с 500ГБ, но там уже нет места, что делать?
Есть еще пласт проблем, связанный с вашим подходом. Поэтому я думаю, что его никто не использует.
Станислав Макаров: я честно мало что понял из ваших ответов, но думаю что на практике это не будет нормально работать. Обсуждаем мы систему с большими объемами данных, иначе нет смысла вообще все это изобретать. Я бы посмотрел на систему, где используется описанный вами подход. Я такой реально вообще никогда не видел и даже не представляю, как это сделать, чтобы не было кучи разных проблем. Я реально рабочих подходов в бою видел всего два:
1. Сетевая файловая система https://ru.wikipedia.org/wiki/Network_File_System
2. Много независимых серверов для статики, файлы на них заливаются рандомно (или по некому алгоритму), приложение перестает записывать данные на сервера на которых исчерпывается объем жесткого диска и только читает с них. Каждый сервер висит на своем поддомене. В базе вместе со всей метаинформацией сохраняется и номер сервера, на котором располагается файл. Яркий пример - Вконтакте.
Первый вариант проще, но говорят начинаются проблемы, когда возрастает траффик, так как канал между удаленной файловой системой и серверами на которых работает приложение забивается и отдача статики начинает тормозить.
Второй вариант сложнее в реализации (нужно писать свой код), но пишут что работает хорошо, так как нет узкого места, сервера статики получаются распределенными и никак ни от чего не зависят, в отличии от первого варианта.
Станислав Макаров: ну хорошо, тогда расскажите, как приложению получить доступ к файлу на конкретном шарде. И как делать решардинг, когда в кластер добавляется новая нода. И что будет, если по хешу этот файл нужно сохранить на конкретную ноду, но на этой ноде уже полностью занят жесткий диск?
Есть примеры крупных проектов, где файлы шардятся по нодам используя описанный вами подход?
Расскажите тогда сразу, как шардить на несколько серверов. В бд хранить номер шарда (сервера) и локальный путь к файлу? В приложении выбирать только те шарды, на которых достаточно места для хранения файла?
Сергей Протько: в модель буду писать. В контроллерах будет получение данных от модели и передача их во вью. Некоторая бизнес-логика может уходить в компоненты или еще куда-нибудь, если говорить в контексте Yii.
Прошу внимательнее. В качестве примера я выбрал Yii второй версии. Привел пример. И задал четкий вопрос. Вот он
> Можно ли это назвать юнит-тестированием или это всё же интеграционное тестирование?
И далее спросил. Критичен ли тот факт, что в процессе тестирования одного метода, неявно тестируются и некоторые другие методы системы. Я хотел выяснить нужно ли всегда в юнит-тестах мокать все зависимости или нет. Если нужно, тогда почему разработчики Yii посчитали по другому?
Я задал четкий вопрос, на который вы к сожалению дали ответ из которого ничего не понятно.
matperez: Ну я об этом и пишу, что замокав поиск пользователя, смысла от такого теста не будет, потому что логика метода LoginForm::login() очень проста. И думаю, что здесь нужно чувствовать грань, когда писать юнит-тесты, а когда интеграционные и в целом не разделять их на две разные группы.