Зачем использовать внутренний сервер и RPC в инфраструктуре веб-сервера? - PullRequest
0 голосов
/ 30 января 2012

Я заинтересован в создании веб-приложения, и я только что провел исследование того, что делает хороший веб-сервер.Я ищу через Facebook, Twitter и Foursquare.Они делятся тем, какое программное обеспечение они использовали для построения своей инфраструктуры.

Для меня часть используемого программного обеспечения является новой.Я хотел бы задать несколько вопросов здесь.зачем создавать внутренний сервер, разве недостаточно веб-сервера с PHP?Зачем использовать Java / Scala для бэкэнда?Нужна ли нам RPC-инфраструктура, такая как буфер обмена / протокол?Для чего используется этот каркас RPC?Используется ли он для связи между внешним и внутренним серверами?

Очень признателен тем, кто отвечает на мои вопросы, или, если есть какие-то книги, вы бы посоветовали мне прочитать.

Спасибо.

Ответы [ 2 ]

3 голосов
/ 04 июня 2012

Звучит так, как будто вы хотите создать масштабируемую бэкэнд-инфраструктуру, которая в конечном итоге будет использоваться для следующих действий:

  1. Обслуживание контента. Это слой веб-сервера.
  2. Выполнение некоторого типа внутренней обработки пользовательских запросов. входя из уровня веб-сервера и связываясь с хранилищем данных. Назовите это уровнем сервера приложений.
  3. Сохранение состояния сеанса и пользовательских данных в распределенном, отказоустойчивом, в конечном итоге согласованном хранилище значений ключей.

Кроме того, звучит так, как будто вы хотите сделать это, используя обычное аппаратное обеспечение ПК.

Это высокий заказ.

Foursquare использует Scala с фреймворком Lift для своего веб-сервера. Вот больше . И больше .

Facebook использует много разных технологий. Я знаю, что для своего хранилища данных они используют HBase (они использовали Cassandra)

Yahoo использует HBase для отслеживания статистики пользователя.

Twitter начался как веб-сайт на Ruby-сервере. Они переехали в Скалу. Twitter постепенно перемещается из mysql (я полагаю, sharded) в Cassandra, используя их собственный инструмент инкрементного преобразования баз данных.

Что касается масштабирования на стороне сервера приложений и веб-сервера, я знаю, что на самом деле важно иметь язык, способный порождать новые пользовательские процессы в пространстве пользователя, и процесс менеджера, который назначает новых рабочих, обрабатывает поступающие запросы. в. Думайте об этом как об управлении очень эффективной компанией. Чем больше работы ты получаешь, тем больше людей нанимаешь. Это модель Actor. В некоторые языки встроены акторы, (erlang), в других акторы реализованы в виде каркасов (akka) или библиотек (родной Scala). Судя по всему, нативные актеры Scala глючат, поэтому некоторые люди собрались и внедрили инфраструктуру akka для Scala и Java. В Интернете много дискуссий об актерах, а также о том, какой язык и библиотеки следует использовать. В Erlang много чего готово, однако Scala работает в JVM и позволяет вам повторно использовать множество существующих веб-библиотек Java (что может иметь некоторые проблемы, если в них объявлены статические объекты) Erlang имеет актеров и OTP-библиотеки, но, очевидно, не имеет богатых библиотек, которые есть в Java. Так что для меня все сводится к Скале (с аккой) или Эрлангу.

Для веб-сервера с Scala вы можете использовать любой сервер приложений Java. Foursquare использует причал для большинства вещей. Это не написано на Scala, но, поскольку Scala компилируется в байт-код, который работает на JVM, он легко взаимодействует с любым сервером приложений Java.
Люди также говорят, что не так много программистов на Erlang и что Erlang сложнее выучить ( функциональное программирование против императивное программирование ) Scala является функциональной и императивной одновременно (то есть вы можно сделать либо)

Эрланг работает. Теперь у функционального программирования есть много вещей, потому что один опытный функциональный программист может сделать намного больше, чем опытный программист. Магазины Yahoo изначально создавались и поддерживались на Лиспе (функциональном языке) одним человеком. С другой стороны, императивное программирование легче изучать и широко использовать в командных условиях. Императивные языки хороши для некоторых вещей, функциональные языки для другие. Правильный инструмент для правильной работы.

Возвращаясь к обсуждению веб-сервера, с Erlang вы можете использовать рыскания или запустить фреймворк (Chicago Boss)

Вот больше о дебатах Скала против Эрланга.
Другая ссылка .
Подробнее здесь .
И другой .
Другое мнение .

В конце базы данных у вас есть много вариантов. См. здесь. Вы даже можете полностью отказаться от базы данных и сохранить свои данные в mnesia (хранилище данных времени выполнения Erlang)

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

0 голосов
/ 12 апреля 2012

Например, я сталкиваюсь с множеством проблем при разработке сложных веб-приложений с использованием только PHP.В PHP нет потоков, в php отсутствует много хороших вещей, в которых есть scala, или другой хороший современный язык с богатым синтаксисом.PHP медленнее, чем скомпилированный язык JVM.PHP менее безопасен, на мой взгляд.Хорошо получить кучу данных и отобразить их в виде HTML-страницы, но обработка для высокой нагрузки не является ее плюсом.RPC, как вы предлагаете, служит коммуникационным уровнем.

...