В чем плюсы stateless сервера? [re: выбор технологии для ria]
Разве это проще сделать без состояний?проще эту блокировку хранить в базе, чем на сервере.
главное - это потом проще масштабировать.
проще эту блокировку хранить в базе, чем на сервере.Если я храню блокировку в базе, а клиент отвалился, когда и кто разлочит? То есть я понимаю как это можно сделать, и всё же не понимаю, почему это проще.
главное - это потом проще масштабировать.Очевидно, что такие решения тривиально масштабируются (горизонтально).
То есть я понимаю как это можно сделать, и всё же не понимаю, почему это проще.смотри - какой код самый сложный, и чаще всего меняется? ответ: код в сервере
но делая сервер stateless ты получаешь очень полезный подарок: теперь в самом сервере не надо отслеживать взаимосвязи между отдельными частями.
и соответственно, изменения одной части слабо влияют на изменение другой части.
поэтому меньше времени уходит на анализ, как это изменение повлияет на все остальное; на перетестирование и т.д.
при этом перенося состояние в базу - ты получаешь бонус в виде готового инструмента по просмотру эту состояния, возможности разных выборок и т.д.
В том то и дело, что я не совсем понимаю, почему это упрощение требований. Взять например задачу, когда один документ может редактировать только один пользователь (такие бизнес требования). Разве это проще сделать без состояний? Хотя не исключено, что подобные вопросы возникают у меня из-за недостатка опыта.А, вот оно что. Есть такое, только это уже непосредственно к ria или gwt/gxt отношения не имеет.
Ну да, сложнее, хоть и не неосуществимо (тот же compareAndSet).
Тут, на мой взгляд, скорее возникает вопрос о целесообразности stateless подхода =)
но делая сервер stateless ты получаешь очень полезный подарок: теперь в самом сервере не надо отслеживать взаимосвязи между отдельными частями.
Честно говоря, я ничё не понял...
Тут, на мой взгляд, скорее возникает вопрос о целесообразности stateless подхода =)почему для блокировки будет плох stateless подход?
допустим, раз в минуту продляем действие блокировки в базе.
ps
кстати, еще бывает подход - в виде комбинирования stateless и stateful.
когда stateful используется лишь для построения кэшей.
т.е. по бизнес-логике так и считается, что блокировка лежит в базе, и что она валидна без продления на две минуты.
и при этом все остальные смотрят именно базу.
но для уменьшения трафика между клиентом и сервером - между клиентом и сервером держится соединение.
и сервер обновляет блокировку сам, пока живо соединение от клиента.
это подходит, если считается, что таких редактирований(наложений блокировок) будет немного.
почему для блокировки будет плох stateless подход?Никто не говорил о том, что он плох. Просто он явно не проще (для реализации чем stateful. Ладно, мы уже сильно отклонились от темы.
допустим, раз в минуту продляем действие блокировки в базе.
делая сервер stateless ты получаешь очень полезный подарокмы выпустили продукт с таким архитектурным ограничением и получили подарок : тормоза некоторых функций
тормоза можно лечить точечными ударами в виде кеширования, однако нафига был о вводить тогда это странное архитектурное ограничение - неясно
в итоге появился мутант, притворяющийся stateless
база должна быть тупой, хранить документы, поддерживать некую консистентность и всё
бизнес решения\правила должны быть сконцентрированы на другом уровне (это мое непрофессиональное мнение)
Честно говоря, я ничё не понял...допустим:
есть бизнес-требования:
блокировка на редактирование документа
при показе документа должно показываться, что на документе уже есть блокировка(что документ уже редактируется).
если у тебя состояние хранится внутри сервера, то придется теперь "дружить" между собой редактор и все вьюверы этого документа.
т.к. редактор блокировку накладывает, а вьюверы - ее используют.
появилась зависимость - теперь работоспособность вьюверов зависит от работоспособности редактора, и наоборот.
значит изменение одного из них может уронить другого.
итого, придется теперь или верить разработчикам на слово, что они при изменении редактора не уронили нечаянно вьюверы (и наоборот либо после каждого изменения перетестировать и вьюверы, и редакторы.
при хранении состояния в базе:
1. во-первых, очень легко контролируется когда и какие изменения были внесены в базу (по коду мы не сможем отличить - когда были изменения, которые влияют на хранение, а когда были изменения - которые влияют лишь на логику; или на удобство доступа)
2. во-вторых, такие изменения можем сделать редкими - что позволит сократить необходимости в полном перетестировании
тормоза некоторых функцийчто были за функции, и связи с чем наблюдались тормоза?
база должна быть тупой, хранить документы, поддерживать некую консистентность и всёимхо, наложение блокировки - это такой же документ - особенно с точки зрения бизнеса.
бизнес решения\правила должны быть сконцентрированы на другом уровне (это мое непрофессиональное мнение)
т.к. обычно любого руководителя интересует какая сволочь наложила блокировку еще с утра, и до сих пор ее не сняла - парализовав работу остальных.
почему для блокировки будет плох stateless подход?Возможно я тебя не понял, что ты хотел сказать этими продлениями и пр, но блокировка в базе под конкретного клиента - это, имхо, уже не есть stateless подход.
допустим, раз в минуту продляем действие блокировки в базе.
Ведь у тебя есть клиент, при смерти которого тебе надо подчищать нечто (блокировку). То есть надо уметь отличать клиента-овнера блокировки от остальных клиентов, понимать момент когда он умер (по таймауту или еще как и уметь подчищать за ним его стейт (блокировку). То, что эта блокировка в базе а не в сервере ничего не меняет.
Вполне себе full-blown statefull подход.
Поправь, если где не так.
если у тебя состояние хранится внутри сервера, то придется теперь "дружить" между собой редактор и все вьюверы этого документа.Что за ерунда? Кто сказал, что будет такая неправильная архитектура? Никаких связей между двумя представлениями документа быть не должно и не будет. И блокировка при этом будет легко покрыта автотестами.
т.к. редактор блокировку накладывает, а вьюверы - ее используют.
Ведь у тебя есть клиент, при смерти которого тебе надо подчищать нечто (блокировку). То есть надо уметь отличать клиента-овнера блокировки от остальных клиентов, понимать момент когда он умер (по таймауту или еще как и уметь подчищать за ним его стейт (блокировку).при ошибках - блокировки не чистятся, они могут только чистится при явном действии: окончании/отмена редактирования.
Вполне себе full-blown statefull подход.
Поправь, если где не так.
в блокировке хранится время до которого она действует.
и соответственно запрос на проверку блокировки так составлен, что он игнорирует блокировку которая истекла.
это позволяет не заморачиваться смертью клиента.
фактически, это применение leasing pattern-а
Что за ерунда?ок. проехали.
А, дошло.
Тебе все равно придется различать овнеров блокировки от не-овнеров - тоже смахивает на стейт, хоть и самый примитивный.
Хотя еще можно верить клиентам на слово. Но это, ясень пень, не везде прокатит.
В общем, вернусь к своим первоначальным словам - тут надо всегда смотреть, стоит ли то, за что мы боремся (те стейтлесс) наших усилий.
Тебе все равно придется различать овнеров блокировки от не-овнеров - тоже смахивает на стейт, хоть и самый примитивный.
Хотя еще можно верить клиентам на слово. Но это, ясень пень, не везде прокатит.
В общем, вернусь к своим первоначальным словам - тут надо всегда смотреть, стоит ли то, за что мы боремся (те стейтлесс) наших усилий.
Что за ерунда?попробую так.
ты руководитель проекта?
задача руководителя проекта минимизировать ущерб для всего проекта от ошибок отдельных участников.
когда все состояние хранится в базе - то задача минимизации ошибки проще решается: т.к.
намного проще проводить сферы ответственности,
проще строить систему - чтобы она продолжала жить даже при ошибках в отдельных модулях.
проще отслеживать изменение какого модуля на работу какого модуля влияет
и т.д.
ps
как пример - довольно распространенные проблемы для еще сырого сервера: это deadlock-и, утечки памяти, падения, отжирание ресурсов.
и можно бить себя в грудь и говорить, что наши программисты никогда не допустят наличие таких ошибок в коде; а можно сделать - чтобы даже такие ошибки не мешали нормальной работе пользователей.
на stateless сервере - все эти тяжелые проблемы прозрачно для пользователя легко решаются перезапуском сервера, или подхватом запросов резервным сервером
что были за функции, и связи с чем наблюдались тормоза?браузинг ftp\tape\archives
юзер браузит ftp сервер через stateless сервер
таким образом, нажимая очередной плюсик рядом с именем папки на сервере идет реконнект к ftp-серверу
Тебе все равно придется различать овнеров блокировки от не-овнеров - тоже смахивает на стейт, хоть и самый примитивный.так это решается через идентификатор блокировки.
при наложении блокировки - клиент или сервер генерит идентификатор блокировки - соответственно дальнейшие действия по изменения документа маркируются этим идентификатором.
соответственно, если маркер не совпал с идентификатором блокировки в базе - то изменение отвергается.
также это позволяет легко и надежно решать такие задачи как:
временный отвал клиента - во время которого блокировка в базе сдохла, а клиент об этом не знает,
перебитие блокировки более высокоприоритетной (допустим, админ прибивает блокировку секретаря, ради того, чтобы прошла блокировка главбуха)
и т.д.
задача руководителя проекта минимизировать ущерб для всего проекта от ошибок отдельных участников
Моя задача сделать проект в срок.
намного проще проводить сферы ответственностиПочему?
проще строить систему - чтобы она продолжала жить даже при ошибках в отдельных модуляхПочему?
проще отслеживать изменение какого модуля на работу какого модуля влияет
Да почему же? Если два модуля влияют друг на друга неявно через БД - это и сложнее тестировать, и сложнее поддерживать, и сложнее такие зависимости выявлять.
и можно бить себя в грудь и говорить, что наши программисты никогда не допустят наличие таких ошибок в коде; а можно сделать - чтобы даже такие ошибки не мешали нормальной работе пользователей
Это всё никак не связано с простотой разработки кода, о чём вначале и говорилось. Из плюсов нам было достаточно и масштабируемости.
на stateless сервере - все эти тяжелые проблемы прозрачно для пользователя легко решаются перезапуском сервера, или подхватом запросов резервным сервером
В том же ASP.NET пользовательские сессии выносятся в отдельный сервис, или на SQL. И вот тебе и перезапуск, и масштабирование.
браузинг ftp\tape\archivesимхо, надо различать логический stateless от технического(физического) stateless.
юзер браузит ftp сервер через stateless сервер
таким образом, нажимая очередной плюсик рядом с именем папки на сервере идет реконнект к ftp-серверу
логический stateless говорит, что все должно работать даже если каждый раз клиент заново коннектиться к серверу.
технический stateless говорит, что клиент обязан закрывать подсоединение после каждого запроса.
в данном случае, лучше было делать логический stateless с техническим stateful - это позволяет получить плюсы обоих подходов. логический stateless нам дает легкую и надежную эксплуатацию, а технический stateful - дает оптимизации подключений.
тогда клиент создает соединение и запросы гонит через него, при падении соедиения оно прозрачно поднимается заново, также клиент может рвать соединение после каждого запроса если это необходимо.
так это решается через идентификатор блокировки.Да, я понял. Это я и назвал примитивным стейтом.
Впрочем, это уже, конечно, вопрос спорный, ибо избавляет от почти всех упомянутых здесь проблем стейтфулла.
почему?штатная проблема - при сдаче представитель заказчика говорит - что периодически документы оказываются заблокированными - при этом (что опять же штатно) представитель заказчика не готов внятно ответить - на какие документы блокировка возникает, что при этом делали пользователи, уверен ли он до конца, что это проблемы именно кода и т.д.
...
В том же ASP.NET пользовательские сессии выносятся в отдельный сервис, или на SQL. И вот тебе и перезапуск, и масштабирование.
твои дальнейшие действия:
если блокировки хранятся в коде?
если блокировки хранятся в сессии?
Да, я понял. Это я и назвал примитивным стейтом.так это же state клиента.
так при stateless и утверждается, что все состояние хранится либо в клиенте, либо в хранилище - но не в промежуточных звеньях.
твои дальнейшие действия:Ты не ответил на вопрос "почему". И какие твои действия во всех трёх случаях, включая хранение состояния в БД? А то я как-то не вижу разницы, чем отличается явное blocked = false и неявное "delete/update/insert from/to BLOCKED_DOCS where ID=XXX".
если блокировки хранятся в коде?
если блокировки хранятся в сессии?
так при stateless и утверждается, что все состояние хранится либо в клиенте, либо в хранилище - но не в промежуточных звеньях.При такой трактовке - да, чистый стейтлесс =)
А то я как-то не вижу разницы, чем отличается явное blocked = falseкак ты уже узнал - какие виды блокировок в коде вообще есть, и с какой блокировкой надо разбираться?
как ты уже узнал - какие виды блокировок в коде вообще есть, и с какой блокировкой надо разбираться?Я ничего ещё не узнавал и спрашиваю у тебя. Ты пока что на вопросы не отвечаешь и задаёшь их мне. Ещё раз повторю: как ты будешь решать поставленную тобою проблему в обоих случаях и почему она проще решается при хранении состояния в БД?
Ещё раз повторю: как ты будешь решать поставленную тобою проблему в обоих случаях и почему она проще решается при хранении состояния в БД?на базе легко решается задача построение монитора блокировок (логирование, отображение текущих блокировок и т.д.)
причем вообще без изменения кода - т.е. можно даже тригеры не делать, а просто периодически прогонять внешний запрос - который будет архивировать текущие блокировки - т.к. раз на них жалуются пользователи - то они длительные, и такой архиватор их все равно увидит.
раз монитор блокировок внешний (сделан без внесения изменений в код то и вероятность - что он вносит какие-то проблемы в нормальную работу программы - очень низкая.
при хранении сессии в базе - добавляется задача распознавания - способа хранения состояния в базе, и попыток понимания что есть блокировка, а что нет.
в первом случае - у нас такое понимание уже автоматически было - т.к. пока мы писали основной код - мы уже поняли как база устроена и как там хранятся блокировки; но с сессией - при написании основного кода - мы не получили опыта - как это состояние кодируется в базе.
при хранения состояния в коде - все еще сложнее - т.к. придется грузить монитор блокировок в сам сервер, разбираться с поточностью, как-то учиться перебирать экземпляры объектов где хранятся блокировки, как-то понимать что мы ничего не забыли и т.д.
> база должна быть тупой, хранить документы, поддерживать некую
> консистентность и всё
> бизнес решения\правила должны быть сконцентрированы на другом уровне
> (это мое непрофессиональное мнение)
Как ты относишься к мнению профессионалов?
---
...Я работаю антинаучным аферистом...
> консистентность и всё
> бизнес решения\правила должны быть сконцентрированы на другом уровне
> (это мое непрофессиональное мнение)
Как ты относишься к мнению профессионалов?
---
...Я работаю антинаучным аферистом...
при хранения состояния в коде - все еще сложнее - т.к. придется грузить монитор блокировок в сам сервер, разбираться с поточностью, как-то учиться перебирать экземпляры объектов где хранятся блокировки, как-то понимать что мы ничего не забыли и т.д.И так для решения задачи ты предлагаешь реализовать какой-то "монитор блокировок" во всех трёх случаях? И каким образом из этого сделан вывод что: намного проще проводить сферы ответственности, проще строить систему - чтобы она продолжала жить даже при ошибках в отдельных модулях, проще отслеживать изменение какого модуля на работу какого модуля влияет?
Мало того, не понятна ещё куча моментов. Куда при реализации блокировки на сервере пропали логи (никакой "монитор блокировок" качественных логов не заменит, то есть нафиг не нужен)? Как в случае реализации состояния в БД ты собрался исправлять проблему, когда с блокировками в базе всё в порядке, а вот пользователи открывать документы по-прежнему не могут? Почему ты считаешь, что неявные связи между модулями легче понять и проще протестировать (один модуль записал null, другой прочитал и шлёпнулся)?
Как ты относишься к мнению профессионалов?во-первых, он там рассматривает единственную проблему - это скорость работы приложения
я, конечно, понимаю - что для 2000 года - это было очень актуально, но прошло десять лет и железо стало еще дешевле, в отличие от кол-ва задач и стоимости разработки.
во-вторых: он разделяет application server и web server, хотя сейчас - это скорее одно и тоже.
Web software vendors sometimes try to convince people that the three standard tiers are the following:
relational database management system (RDBMS)
application server
web server
> во-первых, он там рассматривает единственную проблему -
> это скорость работы приложения
> я, конечно, понимаю - что для 2000 года - это было очень
> актуально, но прошло десять лет и железо стало еще дешевле,
Как-то, по-моему, ты странно измеряешь стоимость железа.
Производительность выросла, да, но и потребности выросли,
сегодня тебе надо не десять одновременных соединений
обрабатывать.
> в отличие от кол-ва задач и стоимости разработки.
Вот и прочитай то, что он пишет про стоимость разработки.
> во-вторых: он разделяет application server и web server,
> хотя сейчас - это скорее одно и тоже.
Тут уже всем стало очевидно, что ты если и прочитал статью,
то по диагонали. Ну, либо с мыслительными способностями у тебя
совсем плохо.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> это скорость работы приложения
> я, конечно, понимаю - что для 2000 года - это было очень
> актуально, но прошло десять лет и железо стало еще дешевле,
Как-то, по-моему, ты странно измеряешь стоимость железа.
Производительность выросла, да, но и потребности выросли,
сегодня тебе надо не десять одновременных соединений
обрабатывать.
> в отличие от кол-ва задач и стоимости разработки.
Вот и прочитай то, что он пишет про стоимость разработки.
> во-вторых: он разделяет application server и web server,
> хотя сейчас - это скорее одно и тоже.
Тут уже всем стало очевидно, что ты если и прочитал статью,
то по диагонали. Ну, либо с мыслительными способностями у тебя
совсем плохо.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
надо различать логический stateless от технического(физического) statelessгде можно почитать про эти понятия?
я оперирую тем, что написано на википедии
A stateless server is a server that treats each request as an independent transaction that is unrelated to any previous requestсобственно, первоначально в нашем проекте была нацеленность на веб-сервисы, поэтому следовали архитектурному ограничению, затем доказали друг другу, что ничего из этого не получится, вот и получился мутант с тормозами в некоторых местах
где можно почитать про эти понятия?хз
я оперирую тем, что написано на википедиисейчас ты рассматриваешь сервер как что-то монолитное - которое может быть либо сверху до низу stateless, либо stateful.
A stateless server is a server that treats each request as an independent transaction that is unrelated to any previous request
но сервер правильнее рассматривать как многоуровневную систему: тогда даже если взять http-протокол, который, в целом, stateless, то окажется - что он построен поверх tcp - который совсем даже наоборот - stateful.
уровни сервера можно условно разделить на логические и технические.
на логическом уровне: идет логическая обработка запроса пользователя
на техническом: создаются соединения, формируются пакеты и сообщения и т.д.
ps
стоит понимать, что stateless - это лишь один из способов борьбы со сложностью и способ для уменьшения кол-ва рассматриваемых вариантов (http://blog.metatech.ru/post/slojnost.aspx) и уменьшение кол-ва рассматриваемых вариантов а не серебрянная пуля.
соответственно, например - замена готового атомарного stateful кубика на свой stateless-велосипед - может приводить к обратному - к увеличению сложности решения.
Оставить комментарий
kokoc88
Ясно. Большое спасибо за информацию.Понятно. Да, в Windows Forms тоже проще начать клепать окна. Беда только в том, во что это в итоге выливается...
В том то и дело, что я не совсем понимаю, почему это упрощение требований. Взять например задачу, когда один документ может редактировать только один пользователь (такие бизнес требования). Разве это проще сделать без состояний? Хотя не исключено, что подобные вопросы возникают у меня из-за недостатка опыта.