Здесь нужно много распаковать, извините за длину.
Заголовок вашего вопроса рисует ложную дихотомию. Эти две идеи не являются конкурирующими, на самом деле как раз наоборот, до такой степени, что реактивный Kafka это вещь.
Однако верно и то, что сообщество реактивного программирования создало несколько отличных проектов, таких как Project Reactor или RxJava, которые превращают HTTP-коммуникации в решение, управляемое псевдосообщениями.
Реактивные библиотеки в Java, безусловно, хорошо подходят для решений, управляемых сообщениями, но они могут быть использованы почти для чего угодно (и, возможно, часто используются в тех случаях, когда они не всегда подходят лучше всего!)
Могут ли микросервисы RSocket / Reactive считаться решениями, управляемыми событиями?
Rsocket и реактивные микросервисы - это разные вещи; хотя они прекрасно играют вместе и часто используются вместе, они не одно и то же. RSocket намного новее для начинающих, поэтому большинство реактивных микросервисов, вероятно, уже не используют его.
Реактивные микросервисы или микросервисы, написанные реактивным образом, в основном связаны с тем, как они написаны внутри. Будучи реактивным, серверная часть не является блокирующей, поэтому, возможно, они более эффективны - особенно в тех случаях, когда поток данных должен быть отправлен через долгосрочное соединение. Нереактивные службы должны будут держать отдельный поток открытым в течение всего этого времени для управления этим соединением, тогда как реактивная служба может просто бездействовать, если сообщение не отправляется активно.
Реактивные микросервисы, безусловно, внутренне управляются событиями. Однако это ничего не говорит о средствах, которые реактивный микросервис может использовать для связи. Он может использовать RSocket, простой HTTP, MQTT - вы не можете гарантировать, что он использует, только на основе этого протокола.
Однако RSocket - это протокол, который особенно хорошо работает с реактивными службами, работает с несколькими транспортами и (как бинарный протокол) более эффективен. Это приводит к следующему пункту:
Разве они не просто способ повысить производительность традиционных систем запрос-ответ?
RSocket, безусловно, может быть. Вы можете использовать его как традиционную систему запроса / ответа и просто повысить производительность, при этом все остальное останется классическим. Однако он также поддерживает потоки данных (одно- и двунаправленные), а также семантику «запускать и забывать» и возобновляемые потоки на уровне протокола, поэтому имеет преимущества в функциях, а также в производительности.
Это может быть причиной некоторой путаницы, поскольку (без RSocket) можно выбрать использование промежуточного программного обеспечения исключительно потому, что оно упрощает управление этими потоками (а не для отдельного разделения чего-либо). В этом случае тогда да, промежуточное программное обеспечение не будет не требуется.
Работая поверх транспортного уровня, RSocket также не заботится о том, где он используется или что отправляется через него - поэтому он так же хорошо работает в среде сервер-сервер через TCP, как и в двунаправленной среде сервер-клиент через веб-сокет. .
Разве эти микросервисы Rsocket + Reactor по-прежнему не связаны точно так же, как раньше?
Да, они все еще связаны - это не та проблема, которую пытается решить Rsocket. Это протокол, а не промежуточное ПО. Например, Kafka может позже изначально поддерживать Rsocket. (На данный момент я не вижу никаких признаков того, что это произойдет, но нет ничего, что могло бы технически остановить это.)
В каких сценариях каждый из них более рекомендован?
Если единственная причина, по которой вы используете промежуточное программное обеспечение, заключается в том, чтобы легко генерировать поток данных и управлять им (а не ограничиваться запросом / ответом), тогда Rsocket в сочетании с реактивными библиотеками теперь, возможно, удовлетворяет этим критериям на уровне протокола.
Однако, если вы используете промежуточное программное обеспечение для целей развязки, вы почти наверняка захотите и дальше его использовать. Однако продолжающееся использование указанного промежуточного программного обеспечения, безусловно, не мешает вам использовать реактивные библиотеки и / или Rsocket в вашей реализации.
person
Michael Berry
schedule
16.12.2019
