Доброго времени суток! Пишу клиент-серверное приложение на PHP для набивки шишек. Решил разработать его таким образом, что оно устанавливается на два сервера, один из которых раздает верстку и формы, а другой держит API и общается с клиентом по XML или JSON. В предположительном абстрактном случае сервер, раздающий практически статичную верстку, справится с достаточно высокой нагрузкой, а сервер с API будет выполнять тяжелые(гипотетически) операции и на всех его не хватит. Как спроектировать приложение таким образом, чтобы за API могли отвечать 2+ серверов? На серверах: Linux, Apache2, PHP5.x, MySQL. Насколько я понимаю, одно из решений - вычислительное облако, когда несколько серверов работают как одна машина с одной операционной системой и добавление новых серверов увеличивает вычислительные ресурсы общего, виртуального сервера. Но это решение и дорогостоящее, и не подходящее по изначальному замыслу, поэтому мог бы кто пояснить, как масштабирование, в котором новый сервер просто повышает производительность всей системы, можно реализовать на уровне PHP приложения? Вопрос, вероятно, ламерский, но вся информация, которую мне удалось найти, сугубо абстрактная и как ее применить, пока не понял. Возможно, упускаю что-то значительное. Заранее благодарю за информативные ответы.
Как же сложно, оказывается, можно описать форнтенд<->бекенд архитектуру Не парьтесь, все уже украдено и изобретено до вас. И реализуется все хоть на одной машине. Ставите nginx, под ним apache. Нджинкс легок и принимает запросы от юзера. Если может их сам выполнить(запросы к статике), отдает сам, если нужны вычисления, проксирует запрос к папачу. Папач возвращает ответ нджинксу, нджинкс пользователю. Соль в том, что nginx таким образом является некоей точкой входа и может раздавать задания разным апачам. Балансировка, туда-сюда. И вот оно - горизонтальное масштабирование. Никакое супер-API при этом не нужно. И...сколько у вас посетителей? Вы же еще ничего не написали, но уже волнуетесь о нагрузках? Масштабирование - последняя ступень, а не первая. Первая - надо правильно кодить.
Благодарю за ответ, по большей части это то, что мне было нужно. Но как в таком случае реализовать синхронизацию БД или ФС на десятке серверов? Ладно, у серверов БД есть репликации и кластеры. А что до ФС? Добавлено спустя 52 секунды: Я же сделал акцент на том, что приложение не боевое, а совершенно учебное и высокие нагрузки исключительно гипотетические.
Это точно подмечено. Везде по-разному. Где-то делают распределенные ФС, а где-то не заморачиваются и под таки вещи выделяют отдельный сервер или серверы. У вконтакта, например, отдельные сервера для картинок, для порно и для музыки. Над серверами контроллер. Приходит запрос ему на такую-то картинку, он делает запрос в БД, бд говорит: картинка сия хранится на 2039 серваке по такому-то адресу, и он такой - окай, дергает с того сервака картинку и отдает вопрошающему фронтенду. Тут соль в том, что все зависит от проекта. Абстрактно все везде одинаково, но тонкости вырисовываются в зависимости от реализации. Почитайте отчеты фейсбука, вконтакте, гугла, твиттера. В общем у всех все одинаково. Но если рассмотреть подробнее - у всех все адово различается. И да, вы забыли про еще одну ступень синхронизации: синхронизация оперативной памяти, а точнее, оперативного кэша