Микросервисы маршрутизация
От: Gattaka Россия  
Дата: 26.07.17 04:16
Оценка:
Коллеги,
Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.
Re: Микросервисы маршрутизация
От: scf  
Дата: 26.07.17 04:33
Оценка: 7 (1) +1
Здравствуйте, Gattaka, Вы писали:

G>Коллеги,

G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.

У каждого микросервиса — собственная выходная очередь. Создание большого кол-ва очередей, их администрирование и аутентификация решается через автоматизацию девопса.
Re: Микросервисы маршрутизация
От: Михаил Романов Удмуртия https://mihailromanov.wordpress.com/
Дата: 26.07.17 06:18
Оценка: 13 (3) +1
Здравствуйте, Gattaka, Вы писали:

G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.

В SOA (которая Service-oriented architecture) есть два подхода к тому, как делается связка сервисов:
Собственно, пляшите отсюда.
Если вам нужны названия конкретных библиотек/продуктов, то надо сначала узнать ваши условия (чем пользуетесь, где хостите, ...).

P.S. По моим ощущениям хореография куда сложнее в поддержке, если число сервисов начинает расти, у оркестровки, за счет того, что весь процесс описан в одном месте, гораздо проще делать сквозные изменения. Но зато этот центральный узел обычно становится узким местом.
Re: Микросервисы маршрутизация
От: pestis  
Дата: 26.07.17 06:32
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.


Любой сервис очередей, от 0mq до Amazon SQS.
Re[2]: Микросервисы маршрутизация
От: Nikolay_Ch Россия  
Дата: 26.07.17 08:20
Оценка:
Здравствуйте, Михаил Романов, Вы писали:

МР>Service choreography — когда каждый сервис передает управление следующему, тот следующему и т.д.. При этом нет какого центрального узла, который бы следил за тем, кто когда и с какими данными получает управление.

МР>Service orchestration — когда есть центральный сервис (business-process management, workflow, ESB, ...) который выстраивает весь процесс работы: там, обычно есть некое описание (часто — графическое) последовательности взаимодействия сервисов (причем нормальная практика, когда процесс инициируется обращением к какому-то сервису)

А как оба варианта организуются технически? Есть где почитать подробнее?
Отредактировано 26.07.2017 10:07 Nikolay_Ch . Предыдущая версия .
Re[3]: Микросервисы маршрутизация
От: Михаил Романов Удмуртия https://mihailromanov.wordpress.com/
Дата: 26.07.17 10:59
Оценка: 37 (7)
Здравствуйте, Nikolay_Ch, Вы писали:

N_C>А как оба варианта организуются технически? Есть где почитать подробнее?

Прямо конкретную литературу я, наверное, не назову...

Если же описать на пальцах, то получится примерно так.
Сhoreography
Каких-то специальных решений я не видел, и, подозреваю, их нет. По большому счету, всё делается путем вызова одних сервисов их других, причем это может быть вызов в режиме Request-Replay, а может быть через передачу сообщения.
В первом случае получается этакое дерево вызовов, где каждый "вышележащий" сервис ждет завершения всех своих дочерних сервисов.
Во втором, как уже писали коллеги, каждый сервис использует входящий endpoint в виде очереди сообщений, которую и разгребает потихоньку, при этом формируя сообщения для других.

Собственно, техническая часть — это протоколы самих сервисов, в первую очередь SOAP (т.к. он поддерживает как режим Request-Replay, так и передачу в очередях сообщений), фреймворки для создания Web Services, а также очереди сообщений.

На самом деле была даже попытка создать некий стандарт для описания хореографий Web Services Choreography Description Language (WS-CDL), который, как я понимаю, так и не дошел до релиза и в народ не пошел тоже.

Orchestration
Вот здесь всё куда интереснее.
Дело в том, что идея очень здорово пересеклась с популярными в 2005-2010 годах концепциями процессного управления (Business process management, BPM) и сервисного подхода в организации (Service-oriented architecture, SOA).

Эти концепции попытались перенести и в IT. Т.е. идея, по сути была в том, что:

В результате образовался целый класс систем для работы с BP.
Там есть достаточно большая терминологическая путаница, но можно с большой долей вероятности утверждать, что BPMS (Business Process Management Systems) и ESB (Enterprise Service Bus) — суть одно и то же.
Такая система обычно включает в себя:

Конкретные системы, которые можно назвать: IBM WebSphere ESB, TIBCO, Vitria, Oracle Enterprise Service Bus, Microsoft BizTalk, OpenESB, ... В большинстве своем они достаточно монструозны и дороги.

Что касается средств описания и разработки...
Тут тоже полно всего (у многих систем долгое время была своя нотация, у некоторых она так и осталась своя ...) но из всего это я бы выделил 2 стандарта:

Первый это язык описания процессов в виде диаграмм.
Он включает в себя и сами диаграммы и формат для их хранения и передачи. Диаграммы выглядят примерно так:
  BPMN диагармма

Второй — это XML язык, который в декларативной форме описывает выполнение процесса. Он, например, позволяет:

Т.е. вообще это чистой воды язык для оркестровки.

  Выглядит примерно так
<?xml version="1.0" encoding="utf-8"?> 

<!-- Asynchrnous BPEL process -->

<process name="BusinessTravelProcess" 
         targetNamespace="http://packtpub.com/bpel/travel/" 
         xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
         xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
         xmlns:trv="http://packtpub.com/bpel/travel/"
         xmlns:emp="http://packtpub.com/service/employee/"
         xmlns:aln="http://packtpub.com/service/airline/" >
   
   <partnerLinks>
      <partnerLink name="client" 
                   partnerLinkType="trv:travelLT"
                   myRole="travelService"
                   partnerRole="travelServiceCustomer"/>

      <partnerLink name="employeeTravelStatus" 
                   partnerLinkType="emp:employeeLT"
                   partnerRole="employeeTravelStatusService"/>

      <partnerLink name="AmericanAirlines" 
                   partnerLinkType="aln:flightLT"
                   myRole="airlineCustomer"
                   partnerRole="airlineService"/>
                   
      <partnerLink name="DeltaAirlines" 
                   partnerLinkType="aln:flightLT"
                   myRole="airlineCustomer"
                   partnerRole="airlineService"/>
                   
   </partnerLinks>

   <variables>
      <!-- input for this process -->      
      <variable name="TravelRequest" messageType="trv:TravelRequestMessage"/>
      <!-- input for the Employee Travel Status web service -->
      <variable name="EmployeeTravelStatusRequest" messageType="emp:EmployeeTravelStatusRequestMessage"/>
      <!-- output from the Employee Travel Status web service -->
      <variable name="EmployeeTravelStatusResponse" messageType="emp:EmployeeTravelStatusResponseMessage"/>
      <!-- input for American and Delta web services -->
      <variable name="FlightDetails" messageType="aln:FlightTicketRequestMessage"/>
      <!-- output from American Airlines -->
      <variable name="FlightResponseAA" messageType="aln:TravelResponseMessage"/>
      <!-- output from Delta Airlines -->
      <variable name="FlightResponseDA" messageType="aln:TravelResponseMessage"/>
      <!-- output from BPEL process -->
      <variable name="TravelResponse" messageType="aln:TravelResponseMessage"/>
   </variables>

   <sequence>

      <!-- Receive the initial request for business travel from client -->
      <receive partnerLink="client" 
               portType="trv:TravelApprovalPT" 
               operation="TravelApproval" 
               variable="TravelRequest"
               createInstance="yes" />

      <!-- Prepare the input for the Employee Travel Status Web Service -->
      <assign>
        <copy>
          <from variable="TravelRequest" part="employee"/>
          <to variable="EmployeeTravelStatusRequest" part="employee"/>
        </copy>
      </assign>
      
      <!-- Synchronously invoke the Employee Travel Status Web Service -->
      <invoke partnerLink="employeeTravelStatus" 
              portType="emp:EmployeeTravelStatusPT" 
              operation="EmployeeTravelStatus"
              inputVariable="EmployeeTravelStatusRequest" 
              outputVariable="EmployeeTravelStatusResponse" />

      <!-- Prepare the input for AA and DA -->
      <assign>
        <copy>
          <from variable="TravelRequest" part="flightData"/>
          <to variable="FlightDetails" part="flightData"/>
        </copy>
        <copy>
          <from variable="EmployeeTravelStatusResponse" part="travelClass"/>
          <to variable="FlightDetails" part="travelClass"/>
        </copy>
      </assign>

      <!-- Make a concurrent invocation to AA in DA -->
      <flow>
      
        <sequence>
          <!-- Async invoke of the AA web service and wait for the callback -->
        
          <invoke partnerLink="AmericanAirlines" 
              portType="aln:FlightAvailabilityPT" 
              operation="FlightAvailability"
              inputVariable="FlightDetails" />

          <receive partnerLink="AmericanAirlines" 
              portType="aln:FlightCallbackPT" 
              operation="FlightTicketCallback"
              variable="FlightResponseAA" />

        </sequence>

        <sequence>
          <!-- Async invoke of the DA web service and wait for the callback -->
        
          <invoke partnerLink="DeltaAirlines" 
              portType="aln:FlightAvailabilityPT" 
              operation="FlightAvailability"
              inputVariable="FlightDetails" />

          <receive partnerLink="DeltaAirlines" 
              portType="aln:FlightCallbackPT" 
              operation="FlightTicketCallback"
              variable="FlightResponseDA" />

        </sequence>

      </flow>

      <!-- Select the best offer and construct the TravelResponse -->
      <switch>
              
        <case condition="bpws:getVariableData('FlightResponseAA','confirmationData','/confirmationData/aln:Price') 
                      &lt;= bpws:getVariableData('FlightResponseDA','confirmationData','/confirmationData/aln:Price')">
                    
           <!-- Select American Airlines -->
           <assign>
             <copy>
               <from variable="FlightResponseAA" />
               <to variable="TravelResponse" />
             </copy>
           </assign>
        </case>
                    
        <otherwise>
           <!-- Select Delta Airlines -->
           <assign>
             <copy>
               <from variable="FlightResponseDA" />
               <to variable="TravelResponse" />
             </copy>
           </assign>
        </otherwise>
      </switch>
      
      <!-- Make a callback to the client -->
      <invoke partnerLink="client" 
              portType="trv:ClientCallbackPT" 
              operation="ClientCallback"
              inputVariable="TravelResponse" />
   </sequence>
</process>

Что на сегодня
Мое глубоко личное мнение: в том виде как описано выше, системы BPMS не прижились. ESB я в основном встречал в банках. Ну и более-менее их подходы сейчас есть в российских системах документооборота. Правда там в основном они используются чисто как Workflow движок, который используется для процессов внутри системы, а оркестровка внешних — чисто в дополнение.

Однако, полностью от идеи оркестровки вендоры отказаться не могут и время от времени появляются более легковесные решения типа Azure Logic Apps или Microsoft Flow

Также большой вопрос по чисто программистским инструментам. В том же .Net выход Windows Workflow Foundation практически напрочь уничтожил конкурентов, но сам WF... ну не то чтобы приказал долго жить, но практически встал в развитии.
Re[4]: Микросервисы маршрутизация
От: scf  
Дата: 26.07.17 13:36
Оценка:
Добавлю про ESB — основная проблема оркестрации, помимо быстродействия, это скоуп. Доработки сервисов влекут за собой доработки правил ESB, на который завязаны все сервисы. Это означает, что сломаться, в принципе, может любая функциональность в любом микросервисе.

Я считаю, что хороший микросервис должен быть максимально изолированным и полезным сторонним разработчикам без доступа к исходникам, а ESB — это фактический монолит, прикрытый фиговым листочком правил роутинга сообщений.
Re[2]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 04.08.17 23:09
Оценка:
Здравствуйте, scf, Вы писали:

scf>У каждого микросервиса — собственная выходная очередь. Создание большого кол-ва очередей, их администрирование и аутентификация решается через автоматизацию девопса.

Это работает ровно до того момента, пока у тебя линейная цепочка сервисов. Это работает в целом ряде юзкейсов. Если же правила игры несколько сложней(например нужен реквест-реплай, броадкастинг и тд), то начинается велосипедостроение и в конечном итоге можем получить неподдерживаемого монстра.
Re: Микросервисы маршрутизация
От: itslave СССР  
Дата: 04.08.17 23:26
Оценка: 6 (1)
Здравствуйте, Gattaka, Вы писали:

G>Коллеги,

G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию? Это похоже на workflow и по факту ей и является.
Решения ессна же есть. Но не зная деталей сложно присоветовать в каком направлении двигаться. Я бы рекомендовал начать с этого, затем перейти к чему нить типа этого или вот этого а потом уверенно асилить это ну и контрольный в голову.
Затем несколько лет практики, набивания шишек — и все получится
Отредактировано 04.08.2017 23:27 itslave . Предыдущая версия .
Re[3]: Микросервисы маршрутизация
От: scf  
Дата: 11.08.17 05:43
Оценка:
Здравствуйте, itslave, Вы писали:

I>Это работает ровно до того момента, пока у тебя линейная цепочка сервисов. Это работает в целом ряде юзкейсов. Если же правила игры несколько сложней(например нужен реквест-реплай, броадкастинг и тд), то начинается велосипедостроение и в конечном итоге можем получить неподдерживаемого монстра.


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

Моё мнение — что очереди нужны только там где есть необходимость данные буферизировать — к примеру, если апстрим хочет отдать и коммитить данные быстрее, чем даунстрим способен их обработать.
Re[4]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 11.08.17 15:28
Оценка:
Здравствуйте, scf, Вы писали:

scf>Моё мнение — что очереди нужны только там где есть необходимость данные буферизировать — к примеру, если апстрим хочет отдать и коммитить данные быстрее, чем даунстрим способен их обработать.


Твое мнение канечна интересно, но есть чуваки, которые с тобой не согласны. В чем я их поддерживаю чуть боле чем полностью.
Re[5]: Микросервисы маршрутизация
От: scf  
Дата: 11.08.17 17:21
Оценка:
Здравствуйте, itslave, Вы писали:

I>Здравствуйте, scf, Вы писали:


scf>>Моё мнение — что очереди нужны только там где есть необходимость данные буферизировать — к примеру, если апстрим хочет отдать и коммитить данные быстрее, чем даунстрим способен их обработать.


I>Твое мнение канечна интересно, но есть чуваки, которые с тобой не согласны. В чем я их поддерживаю чуть боле чем полностью.


Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.

edit: прочитал подглаву "Why Use Messaging?". Судя по набору доводов, книжка и правда устарела. Часть доводов применима и к RPC, часть упирает на отсутствие асинхронности и троттлинга в RPC(давно сделано), часть исходит из надежности железа и ненадежности сети (в современном виртуализованном мире железо ненадежно!), а остальные входят в категорию "нам действительно нужно хранить данные т.к. скорость отправителя выше скорости получателя".

RPC крут именно тем, что он stateless — нам не нужно ничего хранить. Сервис очередей требует внимания DBA, как и база данных. Очередь может переполниться, данные из очереди могут быть потеряны (кто делает бэкапы очередей?), при проблемах в системе нужно смотреть содержимое очередей (для большей части систем такой возможности нет).
Отредактировано 11.08.2017 17:50 scf . Предыдущая версия . Еще …
Отредактировано 11.08.2017 17:45 scf . Предыдущая версия .
Re[6]: Микросервисы маршрутизация
От: Nikolay_Ch Россия  
Дата: 11.08.17 18:14
Оценка:
Здравствуйте, scf, Вы писали:

scf>Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.

А что изменилось за пять лет в HTTP/REST?
Re[6]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 11.08.17 18:15
Оценка:
Здравствуйте, scf, Вы писали:


scf>Этой книге уже 5 лет, а текущий тренд микросервисных архитектур — http/rest, thrift, grpc. Правда, саму книжку не читал, исправлюсь.

В этой книжке устарело только то, что описанные паттерны не надо имплементировать вручную, просто выбрать нужный сервис бас. Все.

scf>edit: прочитал подглаву "Why Use Messaging?". Судя по набору доводов, книжка и правда устарела. Часть доводов применима и к RPC, часть упирает на отсутствие асинхронности и троттлинга в RPC(давно сделано), часть исходит из надежности железа и ненадежности сети (в современном виртуализованном мире железо ненадежно!), а остальные входят в категорию "нам действительно нужно хранить данные т.к. скорость отправителя выше скорости получателя".

В совеременном микросервисном виртуальнмо мире сеть так же ненадежна как и у динозавров rpc.
А книжку почитай по диагонале.
scf>Очередь может переполниться, данные из очереди могут быть потеряны (кто делает бэкапы очередей?), при проблемах в системе нужно смотреть содержимое очередей (для большей части систем такой возможности нет).
Если коротко, то почитай про SLA очередей. Некоторые из них кстате идут as a service в клаудах.
Re[7]: Микросервисы маршрутизация
От: scf  
Дата: 11.08.17 19:13
Оценка:
Здравствуйте, Nikolay_Ch, Вы писали:

N_C>А что изменилось за пять лет в HTTP/REST?


Появились асинхронные клиенты и асинхронные серверы. Количество параллельных подключений уже не является ограничением, сотни и тысячи одновременных коннектов — дешевы.
Окончательно оформилась концепция Future/Promise. Сложный асинхронный код уже не так сложен. Кто писал логику реконнекта с таймаутами и прочей мишурой меня поймет.
Появляются нормальные библиотеки для работы с сетью как для клиентов, так и для серверов. Умеющие таймауты, реконнекты, троттлинг с разнообразным поведением.
Современные стеки json/http могут обрабатывать тысячи запросов в секунду без значительного оверхеда.
Re[7]: Микросервисы маршрутизация
От: scf  
Дата: 11.08.17 19:24
Оценка:
Здравствуйте, itslave, Вы писали:
I>В этой книжке устарело только то, что описанные паттерны не надо имплементировать вручную, просто выбрать нужный сервис бас. Все.
ESB — это для избранных, я себя к ним не отношу.

I>В совеременном микросервисном виртуальном мире сеть так же ненадежна как и у динозавров rpc.

Ненадежность сети, это, право, такая незначительная проблема по сравнению с ненадежностью хранения данных...

I>Если коротко, то почитай про SLA очередей. Некоторые из них кстате идут as a service в клаудах.

SLA означет ресурсы и людей, которые его будут обеспечивать. Силами команды — дорого.
Я двумя руками за as a service, т.к. самому админить хранилище данных — дело непростое и требующее постоянного присмотра. Но помимо чисто технических вопросов (работает не так, как мы хотим) есть еще вопросы финансовые — что в случае всплеска использования ресурсов получается либо даунтайм, либо счет от хостера на произвольную сумму.
Re[8]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 11.08.17 20:13
Оценка:
Здравствуйте, scf, Вы писали:

scf>Здравствуйте, Nikolay_Ch, Вы писали:


N_C>>А что изменилось за пять лет в HTTP/REST?


scf>Появились асинхронные клиенты и асинхронные серверы. Количество параллельных подключений уже не является ограничением, сотни и тысячи одновременных коннектов — дешевы.

У меня для тебя плохие новости. Проблема с10к была сформулирована почти 20 назад и с тех пор ничего не поменялось — хочешь обрабатывать больше 10000 одновременных реквестов — надо приседать, вне зависимости от языка программирования.

scf>Окончательно оформилась концепция Future/Promise. Сложный асинхронный код уже не так сложен. Кто писал логику реконнекта с таймаутами и прочей мишурой меня поймет.

Асинхронность была придумана в 60х, на платформе x86 она реализовывалась прерываниями. Про int 21h ты наверняка не слышал

scf>Современные стеки json/http могут обрабатывать тысячи запросов в секунду без значительного оверхеда.

Ровно тоже самое можно было делать 20 лет назад. Только вместо json-а был xml.
Иех, молодежь.....
Отредактировано 11.08.2017 21:02 itslave . Предыдущая версия .
Re[8]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 11.08.17 20:19
Оценка:
Здравствуйте, scf, Вы писали:

scf>Здравствуйте, itslave, Вы писали:

I>>В этой книжке устарело только то, что описанные паттерны не надо имплементировать вручную, просто выбрать нужный сервис бас. Все.
scf>ESB — это для избранных, я себя к ним не отношу.
Непонятно почему ESB — для избранных. Но ок, есть еще валом просто service bus, без приставки enterprise.

scf>Ненадежность сети, это, право, такая незначительная проблема по сравнению с ненадежностью хранения данных...

Хм, она настолько незначительна что привела всего лишь к CAP теореме, отказу от ACID в пользу BASE, (частично) к event-driven модели....

scf>Я двумя руками за as a service, т.к. самому админить хранилище данных — дело непростое и требующее постоянного присмотра. Но помимо чисто технических вопросов (работает не так, как мы хотим) есть еще вопросы финансовые — что в случае всплеска использования ресурсов получается либо даунтайм, либо счет от хостера на произвольную сумму.

Ну раз есть всплеск — значит бизнес работает, получает прибыль. Отдать небольшую часть хостеру не жалко.
Re[9]: Микросервисы маршрутизация
От: scf  
Дата: 12.08.17 04:49
Оценка:
Здравствуйте, itslave, Вы писали:

Я в недоумении. про с10к — вы последний абзац читали? select/IOCP это не приседания, это уже мейнстрим. IO на тредпулах в 2017 делаться не должно. int21h в досе — это программное прерывание для вызова сервисов DOS и было оно *синхронным*. Аппаратные прерывания — это вообще не то и никто пользовательскому софту не даст переопределить обработчик. Кому в 1997 были нужны XML-сервисы, обрабатывающие 1000 запросов в секунду и на каком языке их писали? Гугль утверждает, что service bus — это ESB. CAP-теорема про *данные* и касается только stateful микросерисов. Нет данных — нет проблем с consistency, пиши AP и радуйся жизни. Нагрузка на систему != прибыль. Это может быть DoS, это может быть баг в системе, в случае очередей под нагрузкой объем хранимых данных зависит не от нагрузки, а от отношения скоростей работы отправителя и получателя (что вообще сложно предсказать в динамике)
Re[10]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 12.08.17 06:42
Оценка:
Здравствуйте, scf, Вы писали:

scf>Здравствуйте, itslave, Вы писали:


scf>Я в недоумении. про с10к — вы последний абзац читали? select/IOCP это не приседания, это уже мейнстрим. IO на тредпулах в 2017 делаться не должно.

Да собственно говоря еще в 70х народ очень четко понимал различие между асинхронностью и многопоточностью. И тогда еще придумали совершенно разные механизмы для этих кейсов и успешно использовали все это время. Если кто-то в 2010 году использовал тред пул для эмуляции асинхронности... то у меня для этого человека есть пару плохих новостей. Ессна ж лавинообразный рос ит индустрии и как следствие — понижение квалификации девов внесли свою лепту, но это же совсем не повод говорить про какие то новые свершения в 2017 году.
Да, синтаксического сахара добавили, порог входа понизили.... и всё

scf>int21h в досе — это программное прерывание для вызова сервисов DOS и было оно *синхронным*. Аппаратные прерывания — это вообще не то и никто пользовательскому софту не даст переопределить обработчик.

А тогда этого и не надо было. Но разработчики операционных систем очень четко понимали что асинхронность — это не многопоточность и провайдили интерфейсы, актуальные для своего времени.

scf>Кому в 1997 были нужны XML-сервисы, обрабатывающие 1000 запросов в секунду и на каком языке их писали?

на С++ есна же. И они были нужны, было относительно много софта для таких кейсов, как правило ентерпрайз, финансы...

scf>Гугль утверждает, что service bus — это ESB.

Он врет.
Всякие кафки, мулы от апачей и даже нсервис басы — это не совсем ентерпрайз(там есть монстры от оракла, майкрософта, тибко).

scf>CAP-теорема про *данные* и касается только stateful микросерисов. Нет данных — нет проблем с consistency, пиши AP и радуйся жизни.

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

scf>Нагрузка на систему != прибыль. Это может быть DoS, это может быть баг в системе, в случае очередей под нагрузкой объем хранимых данных зависит не от нагрузки, а от отношения скоростей работы отправителя и получателя (что вообще сложно предсказать в динамике)

Если нагрузка != прибыль, то это баг который надо чинить. И все. Да, фикс некоторых багов, невыявленных вовремя, стоит очень дорого. Вот сходу вспомнился баг с антенной в айфоне 4(или 3 или 5). Казалось бы мелочь, но сколько он стоил...
PS
какой то сумбурный пост вышел. Наверное потому что ответил на сообщение, в котором тоже смешались кучу кони, люди...
Re: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 13.08.17 03:15
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>Наверное многие сталкивались с проблемой и есть какие-то решения уже готовые. Нужно сделать маршрутизацию. То есть микросервис 1 сделал свою работу и пульнул сообщение в очередь что готово. На это сообщение должен реагировать второй и третий. На результаты работы второго реагирует четвертый и т.д. Как делать такую маршрутизацию?

Из личного опыта:
0) А может нафиг микросервисы не нужны?
1) Все эти ESB и мега-оркестраторы сосут. Очень глубоко сосут.
2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.
3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.

Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.
Sapienti sat!
Re[2]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 13.08.17 04:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.

Даже нашелся кандидат, который не сосет. Это прекрасно.
Почитал доку по диагонале. Я правильно понимаю, что персистентность он не предоставляет, доставку — не гарантирует, очередность доставки — не гарантирует?
Отредактировано 13.08.2017 4:16 itslave . Предыдущая версия .
Re[2]: Микросервисы маршрутизация
От: scf  
Дата: 13.08.17 04:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.


Пользовались? Мультиплексирование запросов (несколько запросов в рамках одного TCP соединения) делать умеет?
Re[3]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 13.08.17 05:01
Оценка:
Здравствуйте, scf, Вы писали:

scf>Пользовались? Мультиплексирование запросов (несколько запросов в рамках одного TCP соединения) делать умеет?

Если умеет — т оето трипл фейспалм. Потому как ето задача транспортного уровня и уже решена в http/2
Который кстате худо-бедно сапортят многие веб сервера.
Re[4]: Микросервисы маршрутизация
От: scf  
Дата: 13.08.17 05:14
Оценка:
Здравствуйте, itslave, Вы писали:

I>Если умеет — т оето трипл фейспалм. Потому как ето задача транспортного уровня и уже решена в http/2

I>Который кстате худо-бедно сапортят многие веб сервера.

HTTP/1.1 pipelining (ссылку на который вы прислали) не панацея, т.к. он фиксирует порядок получения ответов на запросы:

8.1.2.2 Pipelining
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

http/2 java-клиенты и серверы еще сырые. Это слишком новая технология, чтобы на нее завязываться. grpc, кстати, использует http/2 в качестве протокола и многие жаловались на разнообразные проблемы с ним. К тому же, http/2 сложнее и нужно изучать использование цпу и памяти под нагрузкой — http/1.1 может оказаться дешевле.
Re[5]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 13.08.17 05:24
Оценка:
Здравствуйте, scf, Вы писали:

scf>HTTP/1.1 pipelining (ссылку на который вы прислали) не панацея, т.к. он фиксирует порядок получения ответов на запросы:

Фейспалм, промазал. Правильная ссылка и цитата:

Multiplexing multiple requests over a single TCP connection


scf>http/2 java-клиенты и серверы еще сырые. Это слишком новая технология, чтобы на нее завязываться. grpc, кстати, использует http/2 в качестве протокола и многие жаловались на разнообразные проблемы с ним.

Я далек от мира джавы, и не могу не отметить, чт оу нас топик про микросервисы. Которыеподразумевают использвание разных технологических стеков и интеграцию на уровне http контрактов

scf>К тому же, http/2 сложнее и нужно изучать использование цпу и памяти под нагрузкой — http/1.1 может оказаться дешевле.


Любую новую технологию надо изучать и тестировать. Но технологию, которая гарантированно будет стандартом, изучать и тестировать гораздо проще чем самодельный велосипед.
Re[3]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 13.08.17 19:20
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.

I>Даже нашелся кандидат, который не сосет. Это прекрасно.
Он тоже сосёт, но немного меньше, чем альтернативы.

I>Почитал доку по диагонале. Я правильно понимаю, что персистентность он не предоставляет, доставку — не гарантирует, очередность доставки — не гарантирует?

Нет, это не система сообщений. Это система для коммутации микросервисов.
Sapienti sat!
Re[3]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 13.08.17 19:20
Оценка:
Здравствуйте, scf, Вы писали:

C>>Из понравившегося: https://linkerd.io/ — позволяет писать сервисы, которые устойчивы к многим динамическим нестабильностям, и при этом прекрасно сочетается с обычными прямыми запросами. Плюс к этому — замечательная система мониторинга.

scf>Пользовались? Мультиплексирование запросов (несколько запросов в рамках одного TCP соединения) делать умеет?
Да, пользовались. Мультиплексирование — не нужно в принципе, кроме как для клиентских приложений на всяких мобильниках.
Sapienti sat!
Re[2]: Микросервисы маршрутизация
От: Sharov Россия  
Дата: 14.08.17 10:00
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.

C>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.

Можно более подробные обоснования?
Кодом людям нужно помогать!
Re[3]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 15.08.17 00:03
Оценка: 7 (2)
Здравствуйте, Sharov, Вы писали:

C>>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.

C>>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
S>Можно более подробные обоснования?
Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.

Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.

Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).

В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.

В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.

Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.
Sapienti sat!
Отредактировано 15.08.2017 3:19 Cyberax . Предыдущая версия .
Re[4]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 03:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Он тоже сосёт, но немного меньше, чем альтернативы.

Ну как то же умудряются люди делать распределенные системы, которые не сосут, или кака минимум не всегда сосут.
Один из возможных вариантов как им это удается — четенько работают с реквариментами и подбирают решение конкретной задачи, а не заявляют "все сосут, кроме вот этой библиотеки, которая ничего не умеет кроме как логировать сетевые вызовы и показывает лиги на админке".

C>Нет, это не система сообщений. Это система для коммутации микросервисов.

То есть ее применимость очень сильно ограничена, целый ряд проблем коммуникации она не решает в принципе. Понятно.
Re[4]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 03:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Да, пользовались. Мультиплексирование — не нужно в принципе, кроме как для клиентских приложений на всяких мобильниках.

А пацаны то и не знают, наверное от нефиг делать пихают мультиплексирование в следующий стандарт хттп. Они тоже наверное сосут.
Re[4]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 03:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.


Можно и делают. Ессна ж ни разу не силвер баллет, но диапазон применимости достаточно широк.

C>Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.


C>Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).


Нормальные очереди дизайнят так, чтобы они были
— безразмерными
— не тормознутыми
— гарантировали высокий SLA по авайлабилити
При таких вводных, вероятность описанного сценария минимальна(а все в распределенных системах упирается в вероятности в конечном итоге), зато позволяет тротлить нагрузку на бекенд и мониторить логически развязать фронтенд и бекенд(что помимо всего прочего, позволяет делать 0-downtime update для бекенда).

C>В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.

Вопрос исключительно к мониторингу и агрегации логов. Ровно тоже самое может произойти при прямых вызовах — бекенд ответил response code 500 b фиг поймешь что там произошло. Кстате в нормальных очередях есть retries + deed letter queue, что очень сильно помогает уменьшить вероятность таких сценариев — если месседж не сумели обработать несколько раз, то
— там явно что-то пошло не так
— сообщение не потеряется

C>В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.

Как я уже отметил выше — retries + dlq лечит такие варианты. Хотя перфоманс может деградировать, если ретраев больше нуля(те не слать месседж в dlq при первой же ошибке).

C>Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.

Все упирается в SLA. Зачастую очереди — распределенные системы, с SLA выше чем у поставщиков-потребителей этой очереди.
Re[5]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 15.08.17 05:45
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Да, пользовались. Мультиплексирование — не нужно в принципе, кроме как для клиентских приложений на всяких мобильниках.

I>А пацаны то и не знают, наверное от нефиг делать пихают мультиплексирование в следующий стандарт хттп. Они тоже наверное сосут.
Я выделил. Ещё мультиплексирование имеет смысл для Web'а, чтобы сразу несколько запросов на ресурсы отправлять по одному каналу и получать сразу несколько ответов.

Для интер-сервисной коммуникации это нафиг не нужно.
Sapienti sat!
Re[5]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 15.08.17 07:52
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.

I>Можно и делают. Ессна ж ни разу не силвер баллет, но диапазон применимости достаточно широк.
Я видел даже реализации аналогов TCP на сообщениях, с flow control и прочим. Это не значит, что это хорошая идея.

Пока я для себя нашёл два нормальных применения очередей:
1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.

C>>Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).

I>Нормальные очереди дизайнят так, чтобы они были
I> — безразмерными
I> — не тормознутыми
I> — гарантировали высокий SLA по авайлабилити
Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.

I>При таких вводных, вероятность описанного сценария минимальна(а все в распределенных системах упирается в вероятности в конечном итоге), зато позволяет тротлить нагрузку на бекенд и мониторить логически развязать фронтенд и бекенд(что помимо всего прочего, позволяет делать 0-downtime update для бекенда).

Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.

C>>В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.

I>Вопрос исключительно к мониторингу и агрегации логов.
У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?

C>>В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.

I>Как я уже отметил выше — retries + dlq лечит такие варианты. Хотя перфоманс может деградировать, если ретраев больше нуля(те не слать месседж в dlq при первой же ошибке).
Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.

Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.

DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.

C>>Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать.

I>Все упирается в SLA. Зачастую очереди — распределенные системы, с SLA выше чем у поставщиков-потребителей этой очереди.
Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
Sapienti sat!
Re[5]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 15.08.17 08:07
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Он тоже сосёт, но немного меньше, чем альтернативы.

I>Ну как то же умудряются люди делать распределенные системы, которые не сосут, или кака минимум не всегда сосут.
Так и делают — минимизируют внешние зависимости, делают всё как можно проще, продумывают динамическое поведение под нагрузкой, уменьшают возможный blast radius при отказе компонентов и т.п.

ЧСХ, варианты: "А давайте возьмём Tibco/Oracle/ZMQ, у которых ВООООООООООТ ТАКОЙ!!! SLA", — заканчиваются обычно провалом.

Если что, мой код работает в системе, которая обслуживает 2 миллиона (5 миллионов в пике) запросов в секунду. Другая моя (на 100%) система обслуживает "всего" 20000 запросов в секунду.

I>Один из возможных вариантов как им это удается — четенько работают с реквариментами и подбирают решение конкретной задачи, а не заявляют "все сосут, кроме вот этой библиотеки, которая ничего не умеет кроме как логировать сетевые вызовы и показывает лиги на админке".

Некоторые вещи практически неизменны, вне зависимости от требований.

C>>Нет, это не система сообщений. Это система для коммутации микросервисов.

I>То есть ее применимость очень сильно ограничена, целый ряд проблем коммуникации она не решает в принципе. Понятно.
То что она не решает — не нужно (тм).
Sapienti sat!
Re[6]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 13:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я выделил. Ещё мультиплексирование имеет смысл для Web'а, чтобы сразу несколько запросов на ресурсы отправлять по одному каналу и получать сразу несколько ответов.

Тоесть не тлько для мобил, а еще и для обыкновенных веб сатов. Ок, с этим пожалуй соглашусь и не буду углубляться в детали.

C>Для интер-сервисной коммуникации это нафиг не нужно.

Опять таки, смотря какие данные там передаются. в большинстве случаев — не надо, а если это (почти) сплошной поток мелких данных с критичным временем обработки(например котировки акций), то мультиплицирование(в том или ином виде) здесь более чем необходимо.
Re[6]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 13:35
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Пока я для себя нашёл два нормальных применения очередей:

C>1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
C>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
Ну я еще парочку накину:
— буферизирование пиковой нагрузки
— интеграция разнородных систем
— обеспечение high availability + guaranteed delivery
Но это далеко не полный список, уверяю тебя

C>Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.

Пусть ломается, надо делать нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.

C>Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.

Если выделенное — это просто фигура речи интернет бойца, то ради бога. В реале же это гарантированный путь к инвалидности. И что самое интересное — я в принципе двумя руками поддерживаю твой посыл не строить распределенные системы пока совсем не припечет, но выражения, которыми ты его доносишь, резкость как у газировки и ультимативность спермотоксикозной школоты — детский сад.

C>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?

Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.

C>Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.

C>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.

C>DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.

И так тоже dlq можно использовать.

C>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.

Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
Отредактировано 15.08.2017 17:00 itslave . Предыдущая версия . Еще …
Отредактировано 15.08.2017 13:52 itslave . Предыдущая версия .
Re[6]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 13:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>ЧСХ, варианты: "А давайте возьмём Tibco/Oracle/ZMQ, у которых ВООООООООООТ ТАКОЙ!!! SLA", — заканчиваются обычно провалом.

Кэп подсказывает, что раз tibco/oracle/biztalk/zmq — коммерчески успешные проекты на протяжении многих лет, то твое утверждение неверно.

C>Если что, мой код работает в системе, которая обслуживает 2 миллиона (5 миллионов в пике) запросов в секунду. Другая моя (на 100%) система обслуживает "всего" 20000 запросов в секунду.

Пошло членомеряние. С горизонтальным масштабирование после 5х инстансов количество запросов не имеет значения. Ну и давай я отмечу, что у меня свежий бизнес кейс — обработать внезапную балковую заливку +- 10 млн картинок в спец формате на S3 и сгенерить из них видео, предварительно трансформировав и это делается за несколько часов на одном дешевом инстансе. Вариантов оптимизации на порядки — валом, но она не нужна потому что бизнес устраивает эта производительность.

I>>Один из возможных вариантов как им это удается — четенько работают с реквариментами и подбирают решение конкретной задачи, а не заявляют "все сосут, кроме вот этой библиотеки, которая ничего не умеет кроме как логировать сетевые вызовы и показывает лиги на админке".

C>Некоторые вещи практически неизменны, вне зависимости от требований.
Все твои посты просто кричат о твоем (возможно)глубоком, но узком опыте. Ты абсолютно все задачи подгоняешь под свои шаблоны и исходя из них пытаешься решить ультимативно и безапелляционно. Дык от. Это глупо. Мир гораздо многообразней и далеко не всем нужны сообщениядробилки.
Если бы ты окунулся, к примеру, в типичный ентенпрайз то ужаснулся бы от зоопарка сервисов, разрабатываемых десятилетиями, обособленными командами с плохой инженерной культурой, легаси ужасом. Там банально поле невозможно добавить в xml без 125 согласований. Мне как то раз доступ к тестовому серваку полгода открывали. Тут ESB очень сильно помогает с организационной точки.
Есть еще IoT, где большой поток входных сообщений надо буферизировать и потери единичных приемлимы.
Есть просто необходимость частых релизов и это пытаются порешать микросервисами...
В общим задачи бывают совершенно разные, а серебряной пули до сих пор не придумали. Поентому я бы на твоем месте бы не утверждал бы настолько ультимативно про "практически неизменные вещи"

C>То что она не решает — не нужно (тм).

Как я уже отметил выше, узость твоего видения мира не позволяет тебе адекватно оценивать как разнообразие задач, так и методов их решения.
Re[7]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 15.08.17 18:30
Оценка:
Здравствуйте, itslave, Вы писали:

C>>2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.

I>Ну я еще парочку накину:
I> — буферизирование пиковой нагрузки
ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.

I> — интеграция разнородных систем

I> — обеспечение high availability + guaranteed delivery
Ещё хуже.

I>Но это далеко не полный список, уверяю тебя

Ну так плохих идей вообще очень много.

I>Пусть ломается, надо делать нормальный мониторинг, дизастер рекавери и нотификацию о факапе. А если к этому всему прикрутить ивент сорцинг в том или ином виде, то "проиграть" историю по всем сохраненным сообщениям после фикса факапа — плевое дело.

И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.

C>>У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?

I>Correlation id и поиск по логам. 2 минуты дела на таких обьемах, при условии использования нормального лог агрегатора.
Проблема в том, что если сообщения вызывают изменение чего-то, то при пропуске одного сообщения не очень понятно итоговое состояние.

C>>Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.

I>Тут все сильно зависит от контекста. Никто не мешает настроить число ретраев = 0, и вуаля, все сообщения обрабатываются один раз. А еще у сообщений есть волшебное свойство visibility timeout, которое сможет запостпонить ретрай на полчасика.
Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.

I>Как видишь достаточно гибко можно наконфигурить и подстроить под бизнес кейс.

Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.

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

C>>Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.

I>Ну и пусть падает. Главное в контракте штрафные санкции правильно прописать. Тогда глядишь и производитель задумается, во что ему падение выйдет и какие то меры предпримет.
Производители себе не враги, и никакие серьёзные последствия для них не последуют.
Sapienti sat!
Re[7]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 15.08.17 18:34
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Для интер-сервисной коммуникации это нафиг не нужно.

I>Опять таки, смотря какие данные там передаются. в большинстве случаев — не надо, а если это (почти) сплошной поток мелких данных с критичным временем обработки(например котировки акций), то мультиплицирование(в том или ином виде) здесь более чем необходимо.
Ну так открой два канала, какие проблемы-то? Зачем это пихать в протокол?
Sapienti sat!
Re[7]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 15.08.17 19:51
Оценка:
Здравствуйте, itslave, Вы писали:

C>>ЧСХ, варианты: "А давайте возьмём Tibco/Oracle/ZMQ, у которых ВООООООООООТ ТАКОЙ!!! SLA", — заканчиваются обычно провалом.

I>Кэп подсказывает, что раз tibco/oracle/biztalk/zmq — коммерчески успешные проекты на протяжении многих лет, то твое утверждение неверно.
Угу. Благодаря подвигам продажников и ынтерпрайз-орхитектов.

C>>Некоторые вещи практически неизменны, вне зависимости от требований.

I>Все твои посты просто кричат о твоем (возможно)глубоком, но узком опыте. Ты абсолютно все задачи подгоняешь под свои шаблоны и исходя из них пытаешься решить ультимативно и безапелляционно. Дык от. Это глупо. Мир гораздо многообразней и далеко не всем нужны сообщениядробилки.
У меня достаточно широкий опыт, и ни разу я ещё не видел нормальной системы на сообщениях. Зато видел не раз, как после радикальной хирургии сложные системы со всякими workflow и оркестрацией превращались в нормальные и простые системы.

I>Если бы ты окунулся, к примеру, в типичный ентенпрайз то ужаснулся бы от зоопарка сервисов, разрабатываемых десятилетиями, обособленными командами с плохой инженерной культурой, легаси ужасом. Там банально поле невозможно добавить в xml без 125 согласований. Мне как то раз доступ к тестовому серваку полгода открывали. Тут ESB очень сильно помогает с организационной точки.

Я частично в таком окружении работаю.

I>Есть еще IoT, где большой поток входных сообщений надо буферизировать и потери единичных приемлимы.

I>Есть просто необходимость частых релизов и это пытаются порешать микросервисами...
Ой, IoT... Конкретно в IoT сообщения используются как я сказал — для пинга внешней системы, которая затем делает синхронный запрос на обновление состояния. А некоторые вообще хранят вечно-открытый TCP-канал, через который обе стороны могут общаться прямыми вызовами.

I>В общим задачи бывают совершенно разные, а серебряной пули до сих пор не придумали. Поентому я бы на твоем месте бы не утверждал бы настолько ультимативно про "практически неизменные вещи"

Зато есть очень плохие паттерны, которые приводят в итоге к проблемам.
Sapienti sat!
Re[8]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 23:20
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, itslave, Вы писали:


C>ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.

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

C>Ещё хуже.

C>Ну так плохих идей вообще очень много.
Ну раз ты сказал — то значит так и есть
Давай присвоим этой цитате номер
2:45 евангелие от сайберакса


C>И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.

Мониторинг уведомит кого надо. Например админа или там систему дизастер рекавери, которая начнет разворачивать бекенд в другом регионе.


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

Про ент сорсинг я писал выше.

C>Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.

Опять таки, все зависит от сценария и от бизнес контекста.

C>Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.

Вот как раз очередь и делает этот самы тротлинг, о чем я писал выше

C>Производители себе не враги, и никакие серьёзные последствия для них не последуют.

Ну да, канешна. И конкуренции на рынке очередей нет вообще
Re[8]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 23:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну так открой два канала, какие проблемы-то? Зачем это пихать в протокол?

Затем, чтобы не строить велосипедов для поддержания открытых каналов открытыми, с учетом таймаутов, обрывов соединений, ограничения операционной системы на кол-во открытых каналов и так далее.
Re[8]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 15.08.17 23:35
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Угу. Благодаря подвигам продажников и ынтерпрайз-орхитектов.

Ну да, канечна. Раз ты сказал — значит так оно и есть. Евангелие от сайберакса, 2:46

C>У меня достаточно широкий опыт, и ни разу я ещё не видел нормальной системы на сообщениях. Зато видел не раз, как после радикальной хирургии сложные системы со всякими workflow и оркестрацией превращались в нормальные и простые системы.

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

C>Зато есть очень плохие паттерны, которые приводят в итоге к проблемам.

Не бывает плохих паттернов. Бывают паттерны подходящие к решению данной конкретной задачи и неподходящие. Как только это поймешь, то можно двигаться дальше к пониманию NFR/QA/ASR.
Отредактировано 15.08.2017 23:40 itslave . Предыдущая версия .
Re[9]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 16.08.17 17:55
Оценка: 5 (1)
Здравствуйте, itslave, Вы писали:

C>>ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.

I>Ну опять, с чего бы так? Ну вот более чем типичный сценарий в том же амазоне: появилась пиковая нагрузка, увеличилось кол-во сообщений в очереди, автоскейлинг бекенда настроен на это реагирует, начинает запускать дополнительные машины.
Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.

Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.

Всё.

Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.

C>>Ну так плохих идей вообще очень много.

I>Ну раз ты сказал — то значит так и есть
I>Давай присвоим этой цитате номер
I>2:45 евангелие от сайберакса
Ага.

C>>И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.

I>Мониторинг уведомит кого надо. Например админа или там систему дизастер рекавери, которая начнет разворачивать бекенд в другом регионе.
Угу, конечно. И ещё базы данных мигрируют и вообще всё написано так, что может работать через WAN.

C>>Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.

I>Опять таки, все зависит от сценария и от бизнес контекста.
Ну то есть, проблема не решается нормально.

C>>Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.

I>Вот как раз очередь и делает этот самы тротлинг, о чем я писал выше
Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.

C>>Производители себе не враги, и никакие серьёзные последствия для них не последуют.

I>Ну да, канешна. И конкуренции на рынке очередей нет вообще
Примерно так и есть.
Sapienti sat!
Re[9]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 16.08.17 17:57
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Ну так открой два канала, какие проблемы-то? Зачем это пихать в протокол?

I>Затем, чтобы не строить велосипедов для поддержания открытых каналов открытыми, с учетом таймаутов, обрывов соединений, ограничения операционной системы на кол-во открытых каналов и так далее.
Потому гораздо лучше колхозить multiplexing вручную, страдая от head of line blocking и прочих приятностей. Ага.
Sapienti sat!
Re[10]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 17.08.17 04:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Потому гораздо лучше колхозить multiplexing вручную, страдая от head of line blocking и прочих приятностей. Ага.

Ты вообще читаешь мои посты, вот просто интересно.Я где то писал про то, что надо колзозить мультиплексинг вручную? Цитату не затруднит привести?
Re[10]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 17.08.17 04:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.

Ага. И атомная бомба упала на датацентр. И абсолютно все решения надо делать с учетом этих маловероятных событий.

C>Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.

Circuit breaker можно заимплементить по разному.

C>Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.

Это не единствено возможный подход. Идентифицировать что бекенд не спрпвляется и начать рещать клиентов можно разнвми способами, выбор кокретного зависит от конкретных требований.


C>Ну то есть, проблема не решается нормально.


Еще раз. Единственный критерий нормальности решения проблемы — это соотвествия результаьа спецификации. Все. Точка.

C>Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.

А не надо этого делать в предложенном мной подходе.

C>Примерно так и есть.

вопросов больше не имею
Re[11]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 17.08.17 07:06
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Потому гораздо лучше колхозить multiplexing вручную, страдая от head of line blocking и прочих приятностей. Ага.

I>Ты вообще читаешь мои посты, вот просто интересно.Я где то писал про то, что надо колзозить мультиплексинг вручную? Цитату не затруднит привести?
Ну не вручную, а на основе протокола системы сообщений, без разницы. Чтобы оно работало так же надёжно, как системный стек TCP, понадобиться написать аналог системного стека TCP.
Sapienti sat!
Re[11]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 17.08.17 07:17
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.

I>Ага. И атомная бомба упала на датацентр. И абсолютно все решения надо делать с учетом этих маловероятных событий.
Именно так. Вот недавно такая бомба упала на датацентр одной крупной компании — при чистке пола случайно нажали на рубильник и отключили питание для всего датацентра. Упс.

Для того, чтобы рассуждать об SLA и надёжных системах, надо сначала усвоить, что ломается вообще ВСЁ. Например, если речь идёт об autoscaling'е, то он так периодически сбоит: http://status.aws.amazon.com/rss/autoscaling-us-east-1.rss

C>>Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.

I>Circuit breaker можно заимплементить по разному.
Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.

C>>Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.

I>Это не единствено возможный подход. Идентифицировать что бекенд не спрпвляется и начать рещать клиентов можно разнвми способами, выбор кокретного зависит от конкретных требований.
Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?

C>>Ну то есть, проблема не решается нормально.

I>Еще раз. Единственный критерий нормальности решения проблемы — это соотвествия результаьа спецификации. Все. Точка.
Да-да. И в спецификации, конечно, написано: "Можно ломаться и терять данные, если клиенты делают слишком много запросов". Если у вас там такие спецификации, то могу только посочувствовать.

В реальном мире, нормальность решения определяется исключительно практикой использования.

C>>Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.

I>А не надо этого делать в предложенном мной подходе.
Ну тогда прошу описать каким образом будет решаться проблема с перегрузкой в моём сценарии.

C>>Примерно так и есть.

I>вопросов больше не имею
Основной метод продажи этих Tibco выглядит так: продажник приходит и говорит, что если клиент купит Tibco/Oracle/whatever, то у него магически увеличится член число девяток надёжности. При этом в контракте прописаны зверские штрафные санкции за нарушения этого — возврат абонентской платы за последний месяц.
Sapienti sat!
Отредактировано 17.08.2017 8:23 Cyberax . Предыдущая версия .
Re[12]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 19.08.17 08:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну не вручную, а на основе протокола системы сообщений, без разницы. Чтобы оно работало так же надёжно, как системный стек TCP, понадобиться написать аналог системного стека TCP.


Еще раз перечитай, у тебя пока что плохо получилось.
Re[12]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 19.08.17 08:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Для того, чтобы рассуждать об SLA и надёжных системах, надо сначала усвоить, что ломается вообще ВСЁ. Например, если речь идёт об autoscaling'е, то он так периодически сбоит: http://status.aws.amazon.com/rss/autoscaling-us-east-1.rss

Ломается, именно об этом и пишут в SLA. Поломается, бизнес недополучит прибыль, провайдер компенсирует(так или иначе). И отлично в огромном количестве бизнесов.


C>Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.

На уровне api gateway синтегрировав с мониторингом.

C>Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?

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

C>Да-да. И в спецификации, конечно, написано: "Можно ломаться и терять данные, если клиенты делают слишком много запросов". Если у вас там такие спецификации, то могу только посочувствовать.

Прикинь, в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.
Скажи, если каждый десятый пакет данных потеряется(т.е. раз в 10 секунд у нас не будет положения самолета), это вообще важно для данного сервиса?
А если это специализированный софт для диспетчеров посадки? В обоих случаях надо одинаков решать задачу, как думаешь?

C>В реальном мире, нормальность решения определяется исключительно практикой использования.

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

C>Основной метод продажи этих Tibco выглядит так: продажник приходит и говорит, что если клиент купит Tibco/Oracle/whatever, то у него магически увеличится член число девяток надёжности. При этом в контракте прописаны зверские штрафные санкции за нарушения этого — возврат абонентской платы за последний месяц.


Мне вот интересно, ты и вправду считаешь покупателей подобных решений полными дибилами, которым продают полный неликвид на протяжении чуть ли не десятилетий,
Re[7]: Микросервисы маршрутизация
От: andmed  
Дата: 19.08.17 09:25
Оценка:
Здравствуйте, itslave, Вы писали:

I>Ну я еще парочку накину:

I> — буферизирование пиковой нагрузки
I> — интеграция разнородных систем
I> — обеспечение high availability + guaranteed delivery

Может наш случай и нетипичный но мы очереди использовали тоже в основном для guaranteed delivery, и в расчете на скейлинг с подъемом инстансов, да.
Малонагруженная бизнес-система на микросервисах в AWS. Для postmortem и мониторинга dlq, throttling gRPC. Возвращаясь к оригинальному посту, Сhoreography в какой-то момент стала напрягать и решили делать pub-sub service https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern (комбинируя pull семантику SQS и push с мультикастом в SNS) в итоге получается что все сервисы завязаны на один, что вроде как к Orchestration приближает
Re[8]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 19.08.17 10:38
Оценка: 5 (1)
Здравствуйте, andmed, Вы писали:

A>Может наш случай и нетипичный но мы очереди использовали тоже в основном для guaranteed delivery, и в расчете на скейлинг с подъемом инстансов, да.

Дык ет и есть нормальное использование очередей.У сайберакса просто немножко другой кейс: если бекенд поломался, то пользователи жмут 'ретрай' много раз, идет дубликация сообщений в очередь, часть сообщений устаревает и дальше коллапс. Вот он и придумал(точней ему придумал, он руку приложил к реализации наверное) тротлинг на отправке сообщений и велосипедный circuit breaker. Может и правильно для конкретно его случая, без требований непонятно.
Re[13]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 19.08.17 19:22
Оценка:
Здравствуйте, itslave, Вы писали:

I>Ломается, именно об этом и пишут в SLA. Поломается, бизнес недополучит прибыль, провайдер компенсирует(так или иначе). И отлично в огромном количестве бизнесов.

Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.

C>>Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.

I>На уровне api gateway синтегрировав с мониторингом.
Ещё раз, мониторинг позволит (максимум) обнаружить аварийную ситуацию. Он не позволит её исправить.

Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???

C>>Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?

I>Я уже несколько раз писал, читать, как я уже понял, ты не умеешь. Давай попробую зайти с другой стороны: по разному, в зависимости от конкретных требований.
Ну вот объясни. Требования я привёл.

I>Прикинь, в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.

Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.

C>>В реальном мире, нормальность решения определяется исключительно практикой использования.

I>В реальном мире не бывает серебрянных пуль, а если ее начинают лепить из молотка — то получается просто блестящий и дорогой молоток, который даже гвозди с трудом забивает.
Ну вот сообщения не пригодны даже для молотка.

I>Мне вот интересно, ты и вправду считаешь покупателей подобных решений полными дибилами, которым продают полный неликвид на протяжении чуть ли не десятилетий,

Да, именно так я и считаю. И сколько раз уже на практике проверил.
Sapienti sat!
Re[14]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 20.08.17 06:33
Оценка: 5 (1)
Здравствуйте, Cyberax, Вы писали:

C>Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.

Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.

C>Ещё раз, мониторинг позволит (максимум) обнаружить аварийную ситуацию. Он не позволит её исправить.

C>Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???
Ты не понимаешь задачи и возможности мониторинга. Вообще.

C>Ну вот объясни. Требования я привёл.

Если то что ты привел — это требования, то не тебя жаль. Вот так навскидку и не читая реальных требований, я бы начал бороться с дубликатами и резким ростом нагрузки еще на client-side и тупо бы не отправлял бы эти дубликаты(там как раз их вычислить — плевое дело). Там же имитировал бы circute breaker/increase timeouts в случаях если что-то пошло не так. Ну вот так навскидку, повторяюсь, исходя из того минимума что я знаю.

C>Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.

Нет. Очереди пригодны fire-ensure in delivery-and forget вещей. Сервис басы пригодны для более широких применений.

C>Ну вот сообщения не пригодны даже для молотка.

Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что. Это очень смелое заявление. Не, я понимаю у тебя оно с кнопкой 'checkout shopping bag' не взлетело по каким-то причинам, но нельзя же все задачи программирования натягивать на кнопку checkout?

C>Да, именно так я и считаю. И сколько раз уже на практике проверил.

Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.
Re[15]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 21.08.17 05:42
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.

I>Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.
Ага. Ну вот смотрим SQS SLA. Упс. А его нету.

Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.

Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.

C>>Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???

I>Ты не понимаешь задачи и возможности мониторинга. Вообще.
Я в недоумении оглянулся на систему мониторинга, которую я написал и которая следит более за тысячами показателей в каждом из 19 регионов, которые мы поддерживаем.

Чем мониторинг должен помочь?

C>>Ну вот объясни. Требования я привёл.

I>Если то что ты привел — это требования, то не тебя жаль. Вот так навскидку и не читая реальных требований, я бы начал бороться с дубликатами и резким ростом нагрузки еще на client-side и тупо бы не отправлял бы эти дубликаты(там как раз их вычислить — плевое дело).
Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.

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

I>Там же имитировал бы circute breaker/increase timeouts в случаях если что-то пошло не так. Ну вот так навскидку, повторяюсь, исходя из того минимума что я знаю.

То есть? Я не понимаю что это значит в данном контексте. Очередь сообщений ни к каким таймаутам непричастна, сообщения туда штатно кладутся с обычной задержкой.

C>>Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.

I>Нет. Очереди пригодны fire-ensure in delivery-and forget вещей. Сервис басы пригодны для более широких применений.
Если нужна гарантированная доставка, то я могу почти на 100% сказать, что сообщения используются неправильно.

C>>Ну вот сообщения не пригодны даже для молотка.

I>Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что.
Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).

Сами по себе асинхронные системы вполне себе нормально живут. Но даже там их лучше применять только для некритичных по времени вещей.

C>>Да, именно так я и считаю. И сколько раз уже на практике проверил.

I>Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.
Principal engineer.
Sapienti sat!
Re[16]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 21.08.17 10:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

I>>Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.

C>Ага. Ну вот смотрим SQS SLA. Упс. А его нету.
А оно есть, хотя канечна аптайм они не гарантируют. Зато гарантируют доставку принятого сообщения:

Q: Does Amazon SQS guarantee delivery of messages?

Standard queues provide at-least-once delivery, which means that each message is delivered at least once.

FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.

А вот мелкософт дает полноценный sla на свой azure service bus.

C>Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.

Это всего лишь говорит о том, что всех все устраивает. Это бизнес и ничего более. Как только в амазон начнет регулярно фейлить sla и это начнет приводить к существенным убыткам клиентов — бизнес мигрирует в ажур или куда там еще. Как только это станет трендом, акции амазона пойдут вниз(или не будут показывать прогнозируемого роста), акционеры вставят пистон CEO, он начнет исправлять ситуацию тем или иным способом(улучшать качество, снижать цену, увеличивать штрафные санкции за даунтайм...) как то так оно и работает.

C>Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.

А с чего ты взял что убытки будут многомиллионными? Как считал? Под какую нагрузку/какой бизнес?

C>Я в недоумении оглянулся на систему мониторинга, которую я написал и которая следит более за тысячами показателей в каждом из 19 регионов, которые мы поддерживаем.

C>Чем мониторинг должен помочь?
Если твой мониторинг для твоего супер нагруженного/всегда доступного решения не умеет автоматически запускать disaster recovery procedure при детектировании того что все упало, то я в недоумении.

C>Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.

Таки у тебя определенные проблемы с чтением. Не будет дубликатов — очередь не будет распухать, существующие сообщения не будут "протухать".
Далее, кто мешает клиенту по таймеру читать из специального ендойнта текущую загрузку системы и изменять величину отклика(время показа окошка please wait) клиенту чтобы тот не так сильно дергался и при полной жопе показывать окошко "попробуйте через 10 минут".

C>Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.

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

C>Если нужна гарантированная доставка, то я могу почти на 100% сказать, что сообщения используются неправильно.

Я тебе еще раз повторяю, все зависит от контекста. 99.99% бекенд сервисов написаны в десятки(если и сотни) раз менее стабильными, доступными, надежными чем тот же sqs. Переписывать их заново с нужным уровнем надежности банально слишкеом дорого и никому нафик не надо. Но гарантировать доставку сообщений с вероятность в 99.9+ задешево — мечта бизнеса. Вот тут очереди/сервис басы решают.

I>>Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что.

C>Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).
Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).

C>Сами по себе асинхронные системы вполне себе нормально живут. Но даже там их лучше применять только для некритичных по времени вещей.

Наконец то хоть какие то проблески понимания что "а у людей может быть и не такие задачи как у меня"

I>>Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.

C>Principal engineer.
Тоесть "прокачанный сеньор". Адекватно, в своей специализации ты прокачался, но по сторонам смотреть пока еще не очень научился, а может тебе оно и не сильно нужно.
Отредактировано 22.08.2017 9:52 itslave . Предыдущая версия .
Re[17]: Микросервисы маршрутизация
От: Cyberax Марс  
Дата: 22.08.17 23:24
Оценка:
Здравствуйте, itslave, Вы писали:

C>>Ага. Ну вот смотрим SQS SLA. Упс. А его нету.

I>А оно есть, хотя канечна аптайм они не гарантируют. Зато гарантируют доставку принятого сообщения:
Не гарантируют. В случае падений SQS сообщения ещё как теряются, хотя они в последнее время исправились и падать почти перестали.

I>А вот мелкософт дает полноценный sla на свой azure service bus.

Аж 25% скидки за последний месяц. Прямо как санкции против Северной Кореи по своей жестокости.

C>>Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.

I>Это всего лишь говорит о том, что всех все устраивает. Это бизнес и ничего более.
Именно так. И никакие Tibco не дадут существенно лучший SLA, потому нечего на него кивать.

C>>Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.

I>А с чего ты взял что убытки будут многомиллионными? Как считал? Под какую нагрузку/какой бизнес?
У меня есть данные от нескольких очень крупных падений Oracle, с многомиллионными убытками. Во всех случаях Oracle не заплатил напрямую ничего. Про Tibco аналогично слышал из первых рук, но сам не присутствовал.

C>>Чем мониторинг должен помочь?

I>Если твой мониторинг для твоего супер нагруженного/всегда доступного решения не умеет автоматически запускать disaster recovery procedure при детектировании того что все упало, то я в недоумении.
Что она даст, если критические компоненты не работают? Куда будет disaster recovery, если состояние системы неопределенное из-за того, что очередь сообщений скопытилась?

C>>Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.

I>Таки у тебя определенные проблемы с чтением. Не будет дубликатов — очередь не будет распухать, существующие сообщения не будут "протухать".
В моём примере очередь распухает не из-за дубликатов, а из-за того, что уникальные обращения перестают обрабатываться.

I>Далее, кто мешает клиенту по таймеру читать из специального ендойнта текущую загрузку системы и изменять величину отклика(время показа окошка please wait) клиенту чтобы тот не так сильно дергался и при полной жопе показывать окошко "попробуйте через 10 минут".

Как это будет выглядеть на уровне API для клиентов?

C>>Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.

I>Еще как поможет, разгребет потихоньку если входной поток ограничить как я описал выше.
А нафиг он тогда нужен? Не проще ли использовать синхронные вызовы?

I> их заново с нужным уровнем надежности банально слишкеом дорого и никому нафик не надо. Но гарантировать доставку сообщений с вероятность в 99.9+ задешево — мечта бизнеса. Вот тут очереди/сервис басы решают.

А бэкэнд всё равно должен быть надёжен, так как иначе никакие 100500 девяток в SLA не помогут.

C>>Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).

I>Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).
В случае с синхронным вызовом состояние системы не хранится в сетевом соединении, кроме как для статуса последнего запроса.

I>Тоесть "прокачанный сеньор". Адекватно, в своей специализации ты прокачался, но по сторонам смотреть пока еще не очень научился, а может тебе оно и не сильно нужно.

Это очень прокачанный сеньор. И как раз на системы клиентов и внутренние системы Amazon'а я насмотрелся вдоволь.
Sapienti sat!
Re[18]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 23.08.17 07:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не гарантируют. В случае падений SQS сообщения ещё как теряются, хотя они в последнее время исправились и падать почти перестали.

У меня первый проект с sqs стартовал года 4 назад. Уже более 2х лет в проде. Через sqs идут сотни тысяч(если не миллионы) сообщений в месяц. Ни единого нарекания на sqs за все это время. Что я не так делал?

C>Аж 25% скидки за последний месяц. Прямо как санкции против Северной Кореи по своей жестокости.

Еще раз повторюсь,. ты упорно демонстрируешь неумение читать. Просто дофига бизнесов с этим ок, его все устраивает и они прекрасно понимают что велосипеды будут стоить гораздо дороже.

C>Именно так. И никакие Tibco не дадут существенно лучший SLA, потому нечего на него кивать.

Я бы так не обобщал, ну да ладно.

C>У меня есть данные от нескольких очень крупных падений Oracle, с многомиллионными убытками. Во всех случаях Oracle не заплатил напрямую ничего. Про Tibco аналогично слышал из первых рук, но сам не присутствовал.

Даже опуская выделенное, это ОБС.

C>Что она даст, если критические компоненты не работают? Куда будет disaster recovery, если состояние системы неопределенное из-за того, что очередь сообщений скопытилась?

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

C>В моём примере очередь распухает н е из-за дубликатов, а из-за того, что уникальные обращения перестают обрабатываться.

Давай я процитирую
Автор: Cyberax
Дата: 16.08.17
тебя же, в этом же треде:

Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает.

Ты уж сам определись, какие сценарии мы рассматриваем а потом озвучивай их консистентно, ок?

C>Как это будет выглядеть на уровне API для клиентов?

Я уверен ты и сам прекрасно сможешь спроектировать REST API endpoint. И может быть даже реализовать

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

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

C>А бэкэнд всё равно должен быть надёжен, так как иначе никакие 100500 девяток в SLA не помогут.

Кому должен, зачем должен и главное кто будет все это оплачивать?

I>>Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).

C>В случае с синхронным вызовом состояние системы не хранится в сетевом соединении, кроме как для статуса последнего запроса.

Еще раз повторюсь:

Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что. Это очень смелое заявление. Не, я понимаю у тебя оно с кнопкой 'checkout shopping bag' не взлетело по каким-то причинам, но нельзя же все задачи программирования натягивать на кнопку checkout?

Re[19]: Микросервисы маршрутизация
От: A13x США  
Дата: 29.08.17 06:17
Оценка:
Здравствуйте, itslave, Вы писали:

I>...


Меня очень заинтересовала эта ветка обсуждения, жаль, что до конструктива не добрались.

Пока суммируя недостатки озвученные выше вижу следующее — если еще осталось желание поправьте меня:
* Системы на сообщениях будут иметь меньшую availability из-за потерь сообщений, это можно отмести для систем, где availability самой message queue system вполне достаточна для бизнеса.
* С точки зрения сопровождения восстановление состояния системы при ошибке будет более сложным -- насколько я вижу correlation id / request id частично решает вопрос, но в случае потерь сообщений это становится сложным.
* Сложная обработка случаев типа multicast storm. Необходимо в архитектуру закладывать способ работы со сценарием когда система позволяет накопить больше сообщений, чем может обработать.
* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).

Да, и отвечая на вопрос выше про альтернативы асинхронным сообщениям для критических сервисов используют workflow / orchestration engines типа Amazon SWF или Uber Cadence — последний уберовцы построили уже имея внутреннюю "durable and scalable" message queue system — cherami.

Пока вроде бы очевидна неприменимость message queue-based систем для построения систем требующих максимальной надежности типа обработки заказов от пользователя, которые часто строят на подобии orchestration engines и мне кажется тут у вас консенсус —

Cyberax:

Пока я для себя нашёл два нормальных применения очередей:
1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.


itslave:

в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.


Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce.

И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?
Re[20]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 29.08.17 10:33
Оценка: 5 (2)
Здравствуйте, A13x, Вы писали:

A>Здравствуйте, itslave, Вы писали:


I>>...


A>Меня очень заинтересовала эта ветка обсуждения, жаль, что до конструктива не добрались.



A>* Системы на сообщениях будут иметь меньшую availability из-за потерь сообщений, это можно отмести для систем, где availability самой message queue system вполне достаточна для бизнеса.

Вот имха, выделенное очень сильно зависит от используемых компонентов, сценариев, квалификации команды, бюджета на разработку и многих других факторов. Из моего опыта, надежность и availability промышленных очередей в разы выше любых велосипедов(включая прямые вызовы), напедаленых среднестатистической командой в (обычно) сжатые сроки.
С другой стороны, при нагрузках в миллионы операций в секунду, как у сайберакса, естественно что 90% промышленных очередей тупо не справятся и велосипеды придется строить. Но тут наверняка и бюджеты другие, и квалификация команды и так далее.
С третьей стороны, подобные нагрузки — ну оочень редки, хотя и интересны.

A>* С точки зрения сопровождения восстановление состояния системы при ошибке будет более сложным -- насколько я вижу correlation id / request id частично решает вопрос, но в случае потерь сообщений это становится сложным.

Строя любую распределенную систему процессинга/сохранения даных, надо помнить о том что eventual consistency — это плата за распределенную систему. Это надо учитывать с самого начала и временами оно бьет очень больно. Поэтому я всячески не рекомендую распределенные системы в тех случаях, когда без них можно обойтись. Еще один способ борьбы с eventual consistency системы — event log/event sourcing. Что в свою очередь привносит новые сложности, которые надо героически решать.

A>* Сложная обработка случаев типа multicast storm. Необходимо в архитектуру закладывать способ работы со сценарием когда система позволяет накопить больше сообщений, чем может обработать.

Да, это надо учитывать с самого начала.

A>* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).

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

A>Да, и отвечая на вопрос выше про альтернативы асинхронным сообщениям для критических сервисов используют workflow / orchestration engines типа Amazon SWF или Uber Cadence — последний уберовцы построили уже имея внутреннюю "durable and scalable" message queue system — cherami.

Да, по сути — actor model в разных ипостасях. Еще можно делать централизированно на ESB.
A>Пока вроде бы очевидна неприменимость message queue-based систем для построения систем требующих максимальной надежности типа обработки заказов от пользователя, которые часто строят на подобии orchestration engines и мне кажется тут у вас консенсус -
Вот опять, все зависит от требований, нагрузки и так далее. ИМХА просто нельзя сравнивать решения для клепания сайта веб магазина аквариумных рыбок в мухосранске и для того же амазона. Соглашусь с сайбераксом, что в последнем случае любое лишнее звено привносит дополнительные риски и надо все упрощать настолько, насколько возможно.

A>Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce.

Из моего опыта, сейчас обычно бизнес требует 99.95% availability для client-oriented веб сайтов. И это число легко достигается очередями. Более того, очереди позволяют увеличить availability системы по сравнению с прямыми вызовами в целом ряде сценариев — можно делать даунтайм consumer-ам очередей (почти)незаметно для пользователя с гарантированной сохранностью данных.

A>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?

Уже штук несколько, самый крупный пожалуй — аналог coursera для "реальных" американских университетов, вроде как лидер в своей отрасли.
Re[20]: Микросервисы маршрутизация
От: Sharov Россия  
Дата: 29.08.17 11:10
Оценка:
Здравствуйте, A13x, Вы писали:

A>* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).


Судя по статьям из интернета (читал на msdn), cb это просто умный retry. Я так понимаю, что по уму его всегда и надо использовать. Но в имплантации он сложнее.

A>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?


Создание асинхронных сервисов. Можно почитать кто и зачем пользует те же rabbit mq
Кодом людям нужно помогать!
Re[21]: Микросервисы маршрутизация
От: A13x США  
Дата: 29.08.17 20:10
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, A13x, Вы писали:


A>>* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).


S>Судя по статьям из интернета (читал на msdn), cb это просто умный retry. Я так понимаю, что по уму его всегда и надо использовать. Но в имплантации он сложнее.


Да. Тут очевидна необходимость использовать комбинированный подход и тут, видимо, можно придумать много решений — например если очередь используется для асинхронной обработки объектов описание которых хранится в некоторой БД, то можно добавить описание состояния асинхронной обработки и сделать retry возможным только по прошествию некторого дельта t от момента начала и ввести Janitor Job который бы рестартовал зависшие таски путем переотправки сообщений. Тогда клиенты не порушат систему ретраями и по достижению насыщения системы сообщениями часть будет отработана через janitor job.

A>>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?


S>Создание асинхронных сервисов. Можно почитать кто и зачем пользует те же rabbit mq


Да это понятно, просто было бы интересно разобрать спор выше на примере конкретных бизнес требований, чтобы просто оценить применимы будут альтернативные решения.
Re[21]: Микросервисы маршрутизация
От: A13x США  
Дата: 29.08.17 20:27
Оценка:
Здравствуйте, itslave, Вы писали:

I>...

I>Вот опять, все зависит от требований, нагрузки и так далее. ...
A>>Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce.
I>Из моего опыта, сейчас обычно бизнес требует 99.95% availability для client-oriented веб сайтов. И это число легко достигается очередями. Более того, очереди позволяют увеличить availability системы по сравнению с прямыми вызовами в целом ряде сценариев — можно делать даунтайм consumer-ам очередей (почти)незаметно для пользователя с гарантированной сохранностью данных.

Ну тут у нас консенсус, у меня нет явного неприятия очередей, по сказанному выше можно сделать вывод — очереди могут упростить ряд задач, но сами по себе не панацея и их использование в production системе требует учета факторов связанных с fault сценариями — обвязка специализированным логированием, хранение состояния обработки для предотвращения перенасыщения сообщениями и для введения если нужно janitor job позволяющего рано или поздно закончить асинхронную обработку.

A>>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?

I>Уже штук несколько, самый крупный пожалуй — аналог coursera для "реальных" американских университетов, вроде как лидер в своей отрасли.

Я хотел предложить разобрать конкретный кейс и альтернативные реализации для одних и тех же требований — было бы интересно сравнить решение предлагаемое cyberax'ом против решения на очередях.
Re[22]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 30.08.17 09:59
Оценка:
Здравствуйте, A13x, Вы писали:

A>Я хотел предложить разобрать конкретный кейс и альтернативные реализации для одних и тех же требований — было бы интересно сравнить решение предлагаемое cyberax'ом против решения на очередях.

Ну давай попробуем, все равно проект заканчивается, скучаю.

Сценарий 1(несколько упрощенней чем в реальности)
Преподаватель загружает лекцию на сервер(S3 де факто) для того чтобы студенты могли ее просмотреть.
После загрузки надо
— проанализировать формат видео
— запустить транскодинг в необходимые форматы(mp4, aac)
— сгененировать thumbnails
— по окончанию всего что выше — отметить лекцию как новую и готовую к просмотру
— послать нотификацию студентам которые включены в соответсвующий курс
Все операции (транскодирование, thumbnails, нотификация) организована на сообщениях в очереди. Агрегация — в бд.

Сценарий 2
Преподававтель заходит на веб сайт и меняет  description к видео.
Изначально планировалось делать асинхронно через очереди, с обновлением кеша. Это было связано с тем что проектировался multiregional deployment и соотвсетвенно репликая БД во все регионы. По результатам тестов, это занимало до 10 минут, в среднем 2-3.
Но потом решили деплоиться в один регион и сделали синхронный вызов.

Сценарий 3
Студент заходит на страницу лекции. Надо послать соотвествующее сообщение для сбора статистики — какие видео популярны и так далее.
Сделано опять таки на очередях.

Сценарий 4(другой проект)
Имеется несколько сервисов, которые общаются друг с другом. Разрабатываются разными командами, деплоятся независимо друг от друга и достаточно внезапно, с даунтаймами. Коммуникация между командами плохая(разные компании, разные континенты). Тут Внедрение сервис баса сильно все упростило. Появилось полное tracebility коммуникации, формат сообщений валидируется сервис басом, retry полечил проблемы независимого деплоймента, dlq, помогло при траблшутинге, минорные изменения формата сообщений полечилось трансформацией на сервис басе и закончился пинг-понг между командами что "у нас все работает".
Re[23]: Микросервисы маршрутизация
От: scf  
Дата: 31.08.17 08:22
Оценка: 3 (1)
Здравствуйте, itslave, Вы писали:

Первые три сценария — очереди используются там и только там, где обработка запроса может занимать неприличное (больше 1 минуты) время.

Четвертый сценарий — проблемы менеджмента и технологического стека. Микросервисы без единой системы логгирования и трассировки просто не взлетят, умение писать и поддерживать стабильное сетевое API тоже обязательно.

Я так понял, у вас малонагруженные системы, где хранилища никогда не переполняются, а ресурсов всегда хватит, чтобы обработать запрос вовремя. В высоконагруженных системах всё не так — при отказе консумера очередь может переполниться за несколько минут, периодически кончается место на диске, одна из машин в кластере может "заболеть" непредсказуемым образом — от выключения до длительного раздумия над каждым запросом, ресурсов периодически не хватает для обработки всех запросов от клиентов.

И все перечисленные ситуации не являются авралом или критическими ошибками — система должна либо не допускать их вообще, либо восстанавливаться автоматически.

В таких системах очереди нужно использовать очень осторожно, т.к. они передают данные в одном направлении, не позволяя консумеру предупредить паблишера о потенциальных проблемах в системе.
Re[24]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 31.08.17 10:13
Оценка:
Здравствуйте, scf, Вы писали:

scf>Здравствуйте, itslave, Вы писали:


scf>Первые три сценария — очереди используются там и только там, где обработка запроса может занимать неприличное (больше 1 минуты) время.

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

scf>Четвертый сценарий — проблемы менеджмента и технологического стека.

Но esb порешал же с минимальными усилиями. Налаживать процессы. было бы больно, дорого и не факт что получилось бы.
scf> Микросервисы без единой системы логгирования и трассировки просто не взлетят, умение писать и поддерживать стабильное сетевое API тоже обязательно.
И полностью автоматизированный деплоймент. IaaC.
scf>Я так понял, у вас малонагруженные системы, где хранилища никогда не переполняются, а ресурсов всегда хватит, чтобы обработать запрос вовремя.
Все в мире относительно — десчтки(в пике сотни) тысяч конкурентных сессий система держит и все хорошо.


cf> В высоконагруженных системах всё не так — при отказе консумера очередь может переполниться за несколько минут, периодически кончается место на диске, одна из машин в кластере может "заболеть" непредсказуемым образом — от выключения до длительного раздумия над каждым запросом, ресурсов периодически не хватает для обработки всех запросов от клиентов.

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


scf>В таких системах очереди нужно использовать очень осторожно, т.к. они передают данные в одном направлении, не позволяя консумеру предупредить паблишера о потенциальных проблемах в системе.

Опять таки, почему нотификация паблишера о проблемах — это задача консьюмера, а не мониторинга?
Re[25]: Микросервисы маршрутизация
От: scf  
Дата: 31.08.17 12:11
Оценка: 3 (1)
Здравствуйте, itslave, Вы писали:

I>Но esb порешал же с минимальными усилиями. Налаживать процессы. было бы больно, дорого и не факт что получилось бы.

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

I>Опять таки, все относительно. Я с трудом представляю что надо сделать, чтобы забить амазоновский sqs. Мониторинг, автоматическое масштабирование групп серверов, деплоймент всей стстемы в другой регион(и даже к другому клаудному провайдеру при первых признаках жопы решают огромное кол-во сценариев.

SQS оплачивать под высокой нагрузкой — никаких денег не хватит. Значительно дешевле все-таки разобраться с кафкой.

I>Опять таки, почему нотификация паблишера о проблемах — это задача консьюмера, а не мониторинга?

Т.е. когда мониторинг собирает статистику с консьюмера и при превышении некоторых метрик говорит паблишеру снизить скорость? Имхо, слишком сложно и не взлетит. Встроить такого рода логику в сетевой клиент (разные коды ошибок, таймауты, реконнекты) значительно проще.
Re[26]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 31.08.17 12:25
Оценка:
Здравствуйте, scf, Вы писали:

scf>Ну да, в данном случае ESB — тот самый вариант, когда взяв технологию вместо технической культуры, получаешь быстрый результат со сложными последствиями.

"Сложные последствия" существуют исключительно в твоих фантазиях

scf>SQS оплачивать под высокой нагрузкой — никаких денег не хватит. Значительно дешевле все-таки разобраться с кафкой.

Это будут доли процента от оплаты EC2, других сервисов и бизнеса вообще. У SQS не "забивается" очередь(кроме масштабов сайберакса наверное), не заканчивается место на диске, его не надо деплоить, он с гораздо меньшей вероятностью упадет и так далее.

scf>Т.е. когда мониторинг собирает статистику с консьюмера и при превышении некоторых метрик говорит паблишеру снизить скорость? Имхо, слишком сложно и не взлетит. Встроить такого рода логику в сетевой клиент (разные коды ошибок, таймауты, реконнекты) значительно проще.

Почему? Мониторить загрузку все равно надо. Реагировать на то что жопа наступает все равно надо. Почему бы еще одним шагом в этой цепочке не поставить нотификацию паблишеру? Гораздо проще вынести это в отдельное место, чем тулить в бизнес логику.
Re[24]: Микросервисы маршрутизация
От: Sharov Россия  
Дата: 31.08.17 15:07
Оценка:
Здравствуйте, scf, Вы писали:

scf>В таких системах очереди нужно использовать очень осторожно, т.к. они передают данные в одном направлении, не позволяя консумеру предупредить паблишера о потенциальных проблемах в системе.


В чем проблема 2 очереди использовать -- одну для задач косумерам, другую для репорта от них же паблишера?
Кодом людям нужно помогать!
Re[25]: Микросервисы маршрутизация
От: scf  
Дата: 31.08.17 15:19
Оценка:
Здравствуйте, Sharov, Вы писали:

S>В чем проблема 2 очереди использовать -- одну для задач косумерам, другую для репорта от них же паблишера?

Если паблишеров несколько? Если проблема с конкретным запросом? Если реакция нужна сразу, а не когда паблишер получит сообщение от консумера? Если получит вообще — консумер может быть перегружен или поломан.
Две очереди в разные стороны — это популярная схема "нас заставляют сидеть на тибке, а нам нужно RPC".
Re[26]: Микросервисы маршрутизация
От: Sharov Россия  
Дата: 31.08.17 17:33
Оценка:
Здравствуйте, scf, Вы писали:

scf>Если паблишеров несколько?


У каждого своя очередь. Хотя этот вариант не очень масштабируется.

scf>Если проблема с конкретным запросом?


Тут уже пляски намечаются -- попытаться изобразить тайм-аут в асинхронной системе.

scf>Если реакция нужна сразу, а не когда паблишер получит сообщение от консумера? Если получит вообще — консумер может быть перегружен или поломан.


В этом случае очередь не подходит.

scf>Две очереди в разные стороны — это популярная схема "нас заставляют сидеть на тибке, а нам нужно RPC".


Обычный асинхронный дуплекс.
Кодом людям нужно помогать!
Re[26]: Микросервисы маршрутизация
От: itslave СССР  
Дата: 31.08.17 18:42
Оценка: 3 (1)
Здравствуйте, scf, Вы писали:

scf>Если паблишеров несколько? Если проблема с конкретным запросом? Если реакция нужна сразу, а не когда паблишер получит сообщение от консумера? Если получит вообще — консумер может быть перегружен или поломан.

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

scf>Две очереди в разные стороны — это популярная схема "нас заставляют сидеть на тибке, а нам нужно RPC".

ЕМНИП тибко поддерживает request-reply, и даже умеет делать ретраи в обе стороны.
Re[4]: Микросервисы маршрутизация
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.09.17 10:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).


Это не проблема конкретно очередей. Это проблема асинхронной обработки в принципе. Как обычно тут трейдофф — либо у нас нет reliability, либо мы должны быть готовы к неожиданному распуханию очередей. Второе не так уж и сложно, если в системе нет серьезных ошибок — резерв по размеру и хорошо настроенный скейлинг вполне успешно с таким борются.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.