[реквестирую матчасть] Распределенный сервер приложений

А какой у тебя протокол распределенной фиксации используется? По какому протоколу репликация?

ЗЫ. Читай доки гугла по Chubby. Гуглится по фразе «paxos made live». Там в конце вроде есть список литературы.

> А какой у тебя протокол распределенной фиксации используется? По какому протоколу репликация?

Скорее всего будет свой велосипед на AMP + Perspective Broker (потому что Twisted во все поля).

Меня в данный момент времени больше занимает именно вопрос прозрачной распределенности, нежели fault tolerance. То бишь сервисы друг друга находят и обмениваются командами, и их не гребет, находятся они в одном процессе, в разных процессах или на разных хостах. Сверху уже можно мутить распределение нагрузок и фейловер.

и их не гребет, находятся они в одном процессе, в разных процессах или на разных хостах

ИМХО зло. С точки зрения API должно быть отражена семантика нижележащих процессов.

> ИМХО зло. С точки зрения API должно быть отражена семантика нижележащих процессов.

ИМХО не такое уж зло. На верхнем уровне все выглядит как обычнейший message passing.

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

Да ты, наверное, шутишь с книгами. Ещё спроси где школа магов и волшебников с недельными курсами.

Смотришь как сделано в похожих решениях, ссылки на статьи по тематике + просто CS. Потом всё это перемешиваешь в голове пробуешь разработать архитектуру для своего случая, далее реализация, практика...

Таненбаум, «Распределённые системы: принципы и парадигмы».

Ну азбука скорее :)

Есть такое еще: «Parallel Processing and Applied Mathematics»

подписался, ибо изобретал подобный велосипед пару лет назад, работает, но тоже хочу матчасти

Читай про эрланг и OTP.

> Есть N сервисов, которые могут между собой общаться, и которые свои услуги экспортируют наружу через M протоколов.
ZeroMQ, чувак.

ZMQ не покатит, там с Twisted интеграция крайне неплотная пока что. AMP, AMQP скорее всего оно самое.

Программирую как раз под такую систему в точности на работе. Внутренняя разработка. Это ужасно

А почему ужасно?
Можешь нам поведать о концептуальных граблях?

Не добавили contracts, потому если нужно написать какой-то flow, то непонятно вообще какие типы сообщений при совместной групировке создают какие типы. Все превращается в унылый поиск через IDE и investigation затягивается на неопределенное время. Представь что лазишь по коду целый день, а потом добавляешь 3 строчки. Потом еще день тестишь

У вас вообще какой-то сипец. Java, что ли? Почему оно с твоих слов такое низкоуровневое?

То, что я хочу сделать, должно быть немного попрозрачнее (для программиста), иначе нафиг оно надо такое.

У автора в голове каша. Он хочет распределенную систему, но не ищет ни одного из свойств распределенности (распараллеливаемости загрузки или fault tolerance или еще чего.

Результат предсказуем - система будет работать не лучше, чем если бы все было запущено на локалхосте, при этом распределенные грабли будут приводить к самым ужасным последствиям. перегрузки сети, death through latency и тд.

пока задача не будет сУжена - можно закапывать.

> У автора в голове каша. Он хочет распределенную систему, но не ищет ни одного из свойств распределенности (распараллеливаемости загрузки или fault tolerance или еще чего.

Скорее распределение нагрузки + динамическая масштабируемость. Об fault tolerance зубы потом сбивать буду. Да, каша, не спорю.

пока задача не будет сУжена - можно закапывать.

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

Когда уже люди откроют для себя Erlang/OTP Тут как то видел костыли на похапе для реализации многопоточности. После ерланга это вызывает приступ смеха и жалости.

http://www.erlang.org/

Уж больно описание смахивает на *MQ (например, ActiveMQ), который раскидывает работу по N сервисам, плюс Apache Camel — те самые M протоколов (в кэмеле их больше, чем M... где-то около L).

Единственное, что это от и до Java. С другой стороны — она для многопоточности гораздо больше подходит, чем питон, да и никто не мешает Jython/Groovy задействовать — система-то получается клеем для кэмела и MQ.

Если неохота связываться с Java, то всегда можно почитать книжки по этим двум штуковинам (серия «* in action»). Там про внутренности ничего не говорится, зато можешь посмотреть, какой интерфейс может иметь система.

Функциональщина наверное многих отталкивает. Видимо суждено ему быть маргинальным и не понятым.

Я вот честно не понимаю такое отношение и причем тут маргинальность. Если есть инструмент, который дает выигрыш во времени реализации решений для некоторых задач, которых становится все больше. Например, те же самые параллельные вычисления или горизонтальная масштабируемость, то почему бы не потратить пару-тройку недель на изучение? И таки еще раз - причем тут маргинальность? Язык более чем успешно используется в продакшене и набирает популярность. А если нельзя повернуть мозг в сторону функционального программирования, то это уже проблема мозга. Плюс, он реально проще многих ООП языков.