Как реализовать конкурирующего потребителя с помощью http

Мне очень понравилась презентация Джеймса Льюиса "Микросервисы: Java, путь Unix".

В этой презентации Джеймс рассказывает о реализации службы регистрации пользователей путем написания механизма обработки очередей, который считывает события из потока атомов и предоставляет конечную точку, которую несколько потребителей могут считывать для обработки и превращения в пользовательские объекты.

Примечания к конкретному слайду (около 18 :40 в видео) говорят, что это было реализовано с помощью конкурирующего потребительского EIP:

«Подсистема обработки очереди реализовала шаблон конкурирующего потребителя, используя условные GET, PUT и Etags для коллекции атомов, представленной очередью событий»

Такой вид очереди (и то, как они говорят о разнородных потребителях) предполагает, что это канал публикации-подписки.

Я не очень понимаю, как это можно реализовать, в книге EIP написано, что конкурирующие потребители работают только:

[...] с каналами «точка-точка»; несколько потребителей на канале публикации-подписки просто создают больше копий каждого сообщения

Я предполагаю, что процессор очереди предоставляет ресурс REST, который конкурирующие потребители вызывают, отправляя запросы GET для новых элементов, но где в него попадают запросы PUT и etags?


http architecture rest event-driven atom-feed
person plasma147    schedule 12.08.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Использование тегов сущностей с методом PUT в этом контексте объясняется в RFC 5023, Протокол публикации Atom, раздел 9.5:

После редактирования клиент может ПОМЕСТИТЬ запись и отправить значение объекта ETag в заголовке If-Match, информируя сервер о необходимости принять запись при условии, что отправленное значение объекта по-прежнему соответствует серверу.

   PUT /edit/first-post.atom HTTP/1.1
   Host: example.org
   Authorization: Basic ZGFmZnk6c2VjZXJldA==
   Content-Type: application/atom+xml;type=entry
   Content-Length: nnn
   If-Match: "e180ee84f0671b1"

   <?xml version="1.0" ?>
   <entry xmlns="http://www.w3.org/2005/Atom">
     <title>Atom-Powered Robots Run Amok</title>
     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
     <updated>2007-02-24T16:34:06Z</updated>
     <author><name>Captain Lansing</name></author>
     <content>Update: it's a hoax!</content>
   </entry>

Однако с тех пор сервер получил более новую копию, чем у клиента, и отвечает кодом состояния 412 («Не удалось выполнить предварительное условие»).

   HTTP/1.1 412 Precondition Failed
   Date: Sat, 24 Feb 2007 16:34:11 GMT

Другими словами, клиент не хочет редактировать ресурс, если это уже сделал кто-то другой, поэтому он отправляет тег сущности в заголовке If-Match с запросом PUT. Клиент говорит серверу: «Принимайте мое редактирование только в том случае, если никто другой уже не редактировал этот ресурс».

person Andre D    schedule 23.08.2013
comment
Таким образом, я предполагаю, что потребитель может выдать запрос PUT для записи, чтобы изменить ее, чтобы обозначить ее требование, и если другой потребитель уже заявил о ней, тогда он создаст другой etag, который прервет запрос, позволяя потребителю искать другое событие, чтобы сожрать вверх. - person plasma147; 13.09.2013
comment
Одним из преимуществ AtomPub является наличие нескольких ролей для потребителей. Заставить этот подход работать для нескольких ролей потребителей кажется выполнимым, но также кажется, что потребители, вероятно, должны сами управлять своим потреблением. - person Seth; 19.11.2014

arrow_upward
2
arrow_downward

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

Просто используйте одну потребляющую службу и настройте мониторинг, чтобы убедиться, что вы предупреждены, если она выйдет из строя.

person plasma147    schedule 01.06.2014
comment
Я также получил этот совет от нескольких старших архитекторов. Этот единственный потребитель может просто передать события в очередь конкурирующего потребителя, если масштабирование действительно необходимо. - person Seth; 19.11.2014