Микросервисы: что такое умные конечные точки и тупые трубы?

15
architecture distributed messaging microservices soa

6 ответов

Я не читал статью, поэтому я могу только предполагать, что он может означать точно, но поскольку он дает ESB в качестве примера против микросервисов и ZeroMQ в качестве примера для микро-сервисов, я надеюсь, что мои предположения будут довольно точными:

одной из идей Unix (и Linux) является создание небольших независимых приложений и подключение их через каналы. Вероятно, наиболее распространенным набором из двух команд, которые я использую, является ps и grepтакой: ps aux | grep PROCESS_NAME - здесь вы можете увидеть тупую трубу, которая только вперед вывод ps к stdin grep.

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

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

примером может быть - если вы хотите выполнить некоторые предварительные действия в системе, например, изменить требования в уже запущенном проекте, это может запустить рабочий процесс, где ESB будет автоматически отправлять различные уведомления различным субъектам вокруг этих измененных требований и ждать, пока 1 или более из этих субъектов подтвердят, прежде чем это изменение будет применено. Что было бы в основном наоборот-тупые конечные точки (которые просто отправляют / получают данные to / from the bus) и очень умный канал (шина, которая может быть настроена или запрограммирована для обработки всех возможных корпоративных сценариев).

Я уверен, что существуют корпоративные служебные шины, которые обрабатывают аналогичные сценарии, и они противоположны простым "тупым" ZeroMQ-подобным фреймворкам передачи сообщений.

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

14

Я думаю, что статья Мартина Фаулерса прискорбно коротка, неправильно характеризуя концепцию "ESB". Этот mischaracterisation широко распространена. Сколько раз вы видели диаграмму, которая представляет "шину" как канал, по которому текут сообщения? Я определенно сбился со счета и каждый раз морщусь. "Автобус" - это не труба. Это механизм обеспечения доступности "стимулирующих услуг" в распределенной, ориентированной на обслуживание среде. Классическая аналогия шины в фабрика. Хотя электричество течет через автобусный бар, это не то, почему это "автобус". Это "автобус", потому что он проходит по всей длине производственного этажа. Любое оборудование (сервисные реализации) может легко подключиться к панели, чтобы получить питание (от генерирующей службы), где бы это оборудование ни находилось. Автобус вездесущий enabler который поддерживает гибкость и изменение с течением времени.

единственные, кто живет на автобус услуг и т. п. принцип они наиболее хорошо снабжены как микросервисы где возможный или желательный. Мантра "умные конечные точки, тупые трубы" восходит еще до появления микросервисов. Я впервые услышал это от члена команды Microsoft BizTalk много лет назад в публичных дебатах с ведущим адвокатом ESB. Парень ESB выступал за желательность очень мелкозернистых автономных служб преобразования (микросервисов), а не типичного подхода BizTalk, где преобразования применяется в конечных точках (smart endpoints). Парень из ESB критиковал BizTalk, утверждая, что он "монолитен" и поэтому не может использоваться для реализации таких мелкозернистых, независимо развертываемых сервисов. Парень BizTalk указал, что он был фактически неправ (как показано впоследствии в инструментарии BizTalk ESB), но что главным моментом была общая желательность выполнения преобразования в конечных точках сообщения (с точки зрения интеграции), а не вниз по течению в некоторых промежуточная услуга, вызываемая в обмене (концептуально, далее по "трубе").

Это был взрослый спор между серьезными практиками. Я согласился с парнем BizTalk в этом вопросе – умные конечные точки, тупые трубы. По иронии судьбы, парень из ESB эффективно продвигал микросервисный подход в контексте ESB. Для меня это отличный пример того, как мантру микрослужб, как и любая другая философия, может быть принято слишком далеко.

12

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

Это:

  • проверки безопасности
  • маршрут
  • бизнес-поток / проверка
  • трансформация

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

"умные конечные точки и тупые трубы" выступают за противоположный сценарий. Что каналы связи должны быть лишены бизнес-обработки и логики и должны буквально только распределять сообщения между компонентами. Это тогда компоненты сами, которые делают обработку / логику / проверку и т. д... на этих сообщениях.

5

Это очень общие вопросы. Я постараюсь сохранить это таким образом

умный конечные точки

умные конечные точки просто означают фактические бизнес-правила и любые другие проверки происходят за теми конечными точками, которые никому не видны потребителям этих конечных точек, думайте об этом как о месте, где происходит настоящая магия.

стремно трубопроводов

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

1

тупые трубы просто означают соединения точка-точка. Конечные точки выполняют всю работу, и любая сложность вынимается из механизма их соединения. Я думаю, что люди говорят об ESBs в этом разговоре, потому что тупые трубы (точечные соединения) - ужасная идея в корпоративной обстановке (и во многих других). Эсбс не стремно труб. Эсбс очень хорошее определение очень умный труб. И они помогают получить контроль над невероятно волосатым беспорядком, который точка в точку соединения создаются всякий раз, когда у вас есть более нескольких служб, которые должны общаться друг с другом.

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

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

0

по словам Мартина Фаулера: "второй подход в общем использовании-это обмен сообщениями по облегченной шине сообщений. Выбранная инфраструктура обычно немой (немой, как в действует только как маршрутизатор сообщений)".

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

для поддержки последнего микро-сервис должен быть толерантен к своему потребителю. Е. Г. добавление обязательный входной аргумент позже разобьет интерфейс, и поэтому его следует избегать. Вместо этого следует использовать стратегии компенсации, такие как defaults, или поддерживать какую-то внутреннюю "маршрутизацию", чтобы микросервис все еще мог дать действительный ответ. Это своего рода умная "конечная точка".

0