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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Это может сделать:

• Проверки безопасности
• Routing
• Бизнес-поток/проверка
• Преобразование

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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