Микросервисы маршрутизация
От: 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
какой то сумбурный пост вышел. Наверное потому что ответил на сообщение, в котором тоже смешались кучу кони, люди...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.