nats streaming что это
Русские Блоги
Практика построения микросервисного механизма публикации / подписки на основе NATS
Содержание статьи
1. Введение в потоковую передачу NATS и NATS
Связанная ссылка
Официальная документация:https://www.nats.io/documentation/
Открытый исходный код:
Клиент (многоязычная поддержка):
Конфигурация параметров: обратитесь к введению github
Другое: Недавно присоединился к проекту NATSCNCF
Поскольку существует много связанных введений и официальное введение очень подробное, здесь просто для того, чтобы поделиться некоторыми чувствами и опытом в процессе
1.1 Разница между NATS и NATS Streaming
Самая важная вещь, чтобы понять разницу между NATS и потоковой передачей NATS, заключается в том, что потоковая передача NATS не является функциональным усовершенствованием NATS. Она по-прежнему взаимодействует с NATS через клиента. Их развертывание является независимым. Потоковая передача NATS работает в форме, аналогичной sidecar NATS
1.2 Введение в NATS
Легкий, эффективный и высокодоступный
Следующие пункты заслуживают особого внимания:
1). Аутентификация и авторизация
NATS предоставляет два метода аутентификации клиента на основе токена и имени пользователя / пароля;
Обеспечивает базовое управление разрешениями для подписки и публикации тем;
2). Кластер высокой доступности
NATS очень прост в развертывании кластера высокой доступности, нужно только добавить следующую конфигурацию в файл конфигурации каждого экземпляра, где кластер может установить метод аутентификации отдельно;
3). Автоматически отключать нездоровые клиентские соединения
проверка PING-PONG будет поддерживаться между сервером NATS и клиентом и будет отключена, если будет установлено, что она отключена или неработоспособна;
Это стратегия, обеспечивающая эффективную работу Сервера в течение длительного времени;
4). Относительно простой интерфейс мониторинга
Простой интерфейс веб-мониторинга может быть предоставлен через следующие параметры запуска, но функция очень проста и нуждается в дальнейшем совершенствовании: для устранения недостатков предусмотрен инструмент nats-top для просмотра более подробной информации о сервере;
5). Ограничение размера одного сообщения
Размер одного сообщения NATS ограничен 1M, в основном может соответствовать общей передаче данных;
1.3 Введение в потоковую передачу NATS
Понимание NATS Streaming в основном связано с предоставлением новых функций для NATS Server, основные проблемы заключаются в следующем:
1).At-least-once-delivery & Durable subscriptions
По крайней мере одна доставка и постоянство очень полезны для обеспечения согласованности данных в распределенных сценариях;
2). Историческое воспроизведение сообщения по теме и уникальный глобальный идентификатор клиента
Вы можете выбрать любой узел истории, чтобы начать подписку, чтобы возобновить подписку
3). Разнообразная постоянная поддержка
По умолчанию сообщения хранятся в памяти, и поддерживаются как файлы, так и MySQL;
2. Используйте анализ сценария
Сценарий 1. Эффективная передача (непротиворечивая согласованность не гарантируется)
Фактически, этот режим использовался в первые дни нашего использования NATS и в основном используется для синхронизации информации различных модулей (например, синхронизации личной информации), что не требуется с точки зрения своевременности и согласованности, этот сценарий необходим только для создания NATS. Кластера достаточно;
Сценарий 2: обеспечить окончательную согласованность
Гарантия согласованности в основном достигается за счет функций, предоставляемых потоковой передачей NAT.В архитектуре микросервиса часто существуют цепочки межсервисных вызовов. Как обеспечить согласованность бизнес-данных в случае недоступности или сбоя нисходящих служб, потоковая передача NATS Предоставленный механизм ACK и характеристики как минимум одного прохода очень важны, даже во избежание возможных несоответствий данных во время процесса восстановления после сбоя кластера NATS, например, типичные сценарии включают в себя платежи и ключевые обновления бизнес-статуса;
3. Введение плана практики
первая сцена
В этом сценарии роль NATS заключается в повышении эффективности транспортного уровня (транспорта) для завершения асинхронной передачи данных, поэтому требуется только развертывание кластера NATS, не требуются дополнительные функции, предоставляемые потоковой передачей; примените следующий шаблон, создайте больше Кластера NATS узла достаточно;
Демонстрация развертывания кластера (на примере конфигурации одного узла)
Сцена вторая
Поскольку для сценария 2 требуется поддержка функций, связанных с потоковой передачей, необходимо развернуть потоковый кластер. В то же время, согласно уникальному методу работы между NATS и потоковой передачей NATS, мы можем полностью развернуть потоковую передачу NATS на основе кластера NATS, развернутого в сценарии 1. Другими словами, потоковый кластер NATS все еще подключен к этому кластеру NATS;
Демонстрация развертывания кластера (на примере конфигурации одного узла)
Рекомендуется, чтобы число потоковых узлов было нечетным, и потоковый сервер выбирает узел-лидер с помощью алгоритма Плот;
4. Резюме
Самым очевидным ощущением при использовании NATS является то, что он легкий, эффективный и простой в развертывании (подробное введение в конфигурацию), в то же время благодаря его лучшим распределенным характеристикам никогда не было неожиданного простоя или ненормальной потери данных во время использования;
Интеллектуальная рекомендация
Spring Cloud Micro-Service Framework Set (2) Создайте поставщик услуг
Центр регистрации по строительству услуг поставщика услуг похож на После создания хорошего проекта: Bootstrap.yml Конфигурация выглядит следующим образом Eureka.client.serviceurl.defaultzone: адрес зд.
Java параллельное программирование: синхронизированный и принцип его
Оригинал: http://www.cnblogs.com/paddix/p/5367116.html Java параллельное программирование: синхронизированный и принцип его Java серия параллельного программирования: Java параллельное программировани.
Весенний проект экспортирует и запускает пакет jar
В последнее время необходимо решить проблему импорта исполняемых jar-пакетов из проектов Maven. Если проект не включает Spring, используйте mvn assembly: assembly. 1. Сначала добавьте в pom.xml: 2. За.
SLF4J Ошибка: не может разрешить метод «Информация» (Java.lang.String) ‘
проблема: Произошла ошибка при использовании @ SLF4J: не может разрешить метод «Info (Java.lang.String)», log не имеет информационного метода. Решения: Во-первых, я подозреваю, что нет пла.
Класс Python с Object Part1
1. Строка экземпляра модификации представлена, что делает результат более значимым Если вы не делаете особый процесс, общая ситуация мы распечатаем экземпляр объекта, который является результатом выхо.
Выбор MQ для высоконагруженного проекта
Современные масштабируемые системы состоят из микросервисов, каждый из которых отвечает за свою ограниченную задачу. Такая архитектура позволяет не допускать чрезмерного разрастания исходного кода и контролировать технический долг.
В нашем проекте десятки микросервисов, каждый из которых зарезервирован: две или более абсолютно идентичных копии сервиса установлены на разных физических серверах, и клиент (другой микросервис) может обращаться к любой из них независимо.
Если микросервис перестает отвечать на запросы в результате аварии, его клиенты должны быть мгновенно перенаправлены на резервный. Для управления потоком запросов часто используют так называемые очереди сообщений (message queues).
Недавно используемая нами очередь перестала нас устраивать по параметрам отказоустойчивости и мы заменили ее. Ниже мы делимся нашим опытом выбора.
Проверенное решение
От сервиса управления очередями сообщений естественно ожидать гарантию доставки. Если адресат сообщения недоступен, то очередь сохраняет полученное от отправителя сообщение на диск, а затем повторяет попытку доставки пока не найдется живой получатель.
Лидером по популярности у разработчиков является RabbitMQ. Это проверенное временем решение класса Enterprise с гарантиями доставки, гибкой системой маршрутизации и поддержкой всевозможных стандартов. Руководители проектов любят его, как в начале 80х покупатели компьютеров любили IBM PC. Эта любовь наиболее точно выражается фразой “Nobody ever got fired for buying IBM.”
Нам RabbitMQ не подошел потому, что он медленный и дорогой в обслуживании.
Производительность RabbitMQ не превышает десятки тысяч сообщений в секунду. Это хороший результат для многих применений, но совершенно неудовлетворительный для нашего случая.
Конфигурировать кластер RabbitMQ непросто, это отнимает ценные ресурсы devops. Кроме того, мы краем уха слышали о нареканиях по работе кластера — он не умеет сливать очереди с конфликтами, возникшими в ситуации “split brain” (когда вследствие разрыва сети образуются два изолированных узла, каждый из которых считает, что он главный).
Очередь на базе распределенного лога
Мы посмотрели на Apache Kafka, которая родилась внутри компании LinkedIn как система агрегации логов. Kafka умеет выжимать бОльшую производительность из дисковой подсистемы, чем RabbitMQ, поскольку она пишет данные последовательно (sequential I/O), а не случайно (random I/O). Но никаких гарантий, что запись на диск всегда будет происходит последовательно, получить нельзя.
В Kafka данные делятся по разделам (partition) и чтобы соблюдать порядок доставки каждый получатель сообщений читает данные ровно из одного раздела. Это может приводить к блокировке очереди в случае, когда получатель по каким-либо причинам обрабатывает сообщения медленнее обычного.
Кроме того, для управления кластером Kafka требуется отдельный сервис (zookeeper), что опять же усложняет обслуживание и нагружает devops.
Мы не готовы рисковать в production потерей производительности, поэтому продолжили поиск.
«Гарантированная» доставка сообщений
Есть замечательная табличка от Jeff Dean, ветерана Google (работает там с 1999 года):
Видно, что запись на диск в 15 раз медленнее отправки по сети.
Парадоксально: ваш адресат находится в сети, передать туда сообщение в 15 раз быстрее, чем записать на диск, но вы зачем-то пишете его на диск.
“Понятное дело, это нужно для обеспечения гарантии доставки,” — скажете вы. — “Ведь если адресат получит сообщение, но, не успев его обработать, упадет из-за отказа железа, очередь должна доставить его повторно.”
Это верно, только гарантии никакой нет. Ведь если упадет отправитель в момент передачи сообщения или упадет сам процесс очереди до записи на диск, то сообщение пропадет. Получается, очередь только создает иллюзию гарантии доставки, а сообщения по-прежнему могут теряться.
Высокопроизводительные очереди
Чтобы не терять сообщения внутри процесса очереди можно просто … убрать процесс очереди и заменить его библиотекой, встраиваемой в процесс микросервиса.
Многие разработчики знакомы с библиотекой ZeroMQ. Она показывает фантастическую скорость, переваривая миллионы сообщений в секунду. Однако в ней (по идеологическим причинам) нет встроенных средств мониторинга и управления кластером, поэтому при ее использовании нагрузка на devops еще выше. Мы продолжили искать более практичные варианты.
Очередь на СУБД?
В какой-то момент мы почти отчаялись и нам показалось, что проще уже будет написать очередь самим поверх СУБД. Это может быть SQL-база данных или одно из многочисленных NoSQL-решений.
К примеру, у Redis есть специальные функции для реализации очередей. Поскольку Redis хранит данные в памяти, производительность прекрасная. Этот вариант был разумным, но смущало, что надстройка Sentinel, предназначенная для объединения нескольких узлов Redis в кластер, выглядела несколько искусственно, будто приделанной сбоку.
При использовании классической СУБД для получения сообщений пришлось бы использовать технику “long polling”. Это некрасиво и чревато задержками в доставке. Да и не хотелось писать на коленке.
Интуиция подсказывала, что мы не первые ищем очередь с разумными требованиями к производительности и простоте администрирования, и в 2017 году у нашей задачи должно быть готовое решение.
Решение найдено: NATS
NATS — относительно молодой проект, созданный Derek Collison, за плечами которого более 20 лет работы над распределенными очередями сообщений.
Нас покорила простота администрирования кластера NATS. Чтобы подключить новый узел, процессу NATS достаточно указать адрес любого другого узла кластера, и он мгновенно скачивает всю топологию и определяет живые/мертвые узлы. Сообщения в NATS группируются по темам, и каждый узел знает, какие узлы имеют живых подписчиков на какие темы. Все сообщения в кластере доставляются напрямую от отправителя получателю, без промежуточных шагов и с минимальной задержкой.
По производительности NATS опережает все очереди с “гарантированной доставкой”. NATS написан на языке Go, но имеет клиентские библиотеки для всех популярных языков. Кроме того, клиенты NATS также знают топологию кластера и способны самостоятельно переподключаться в случае потери связи со своим узлом.
Результаты использования в production
Поскольку NATS не записывает сообщения на диск, сервисы-получатели должны аккуратно завершать свою работу — вначале отписываться от новых сообщений, затем обрабатывать полученные ранее и только потом останавливать процесс.
Сервисы-отправители должны в случае ошибок повторять попытку отправки сообщения. (Впрочем, это не специфично для NATS и так требуется делать при работе с любой очередью).
Чтобы знать наверняка об утерянных сообщениях, мы сделали простейшее логирование: записываем время отправки и время получения.
Мы установили процесс NATS на все виртуальные машины с микросервисами. По результатам наблюдения в течение 2 месяцев NATS не потерял ни одного сообщения.
Мы довольны своим выбором. Надеемся, наш опыт окажется полезным вам.
Русские Блоги
Высокопроизводительное промежуточное программное обеспечение для обмена сообщениями-NATS
предисловие
Прежде чем внедрять NAT, поймите, что такое распределенное ПО системы и сообщений.
Часто упоминаемыми преимуществами промежуточного программного обеспечения для сообщений являются асинхронный и разъединяющий промежуточный продукт, часто используемый на рынке: RabbitMQ, ActiveMQ, Kafka и т. Д., Их внимание и использование очень высоки, а также они очень полезны. удобно. Продукт компании WiseCloud интегрирует RabbitMQ. В следующей версии обновления NATS будет использоваться для замены RabbitMQ. Преимущества использования NATS много. Во-первых, его производительность очень хорошая. Ниже приводится сравнение производительности официального сайта:
Модель обмена сообщениями NATS
NATS поддерживает различные модели обмена сообщениями, в том числе:
Чистая модель паб-суб
Кластер серверов (сервер в режиме кластера)
Множество качеств обслуживания (QoS)
NATS реализует модель распространения сообщений публикации / подписки в виде связи «один ко многим». Издатель отправляет сообщение по теме, и подписчики, которые прослушивают эту тему в любом действии, получат сообщение. 
Connection nc = Nats.connect(“nats://127.0.0.1:4222”);
nc.publish(“subject”, “hello world”.getBytes(StandardCharsets.UTF_8));
//subscribe
Subscription sub = nc.subscribe(“subject”);
Message msg = sub.nextMessage(Duration.ofMillis(500));
String response = new String(msg.getData(), StandardCharsets.
UTF_8);
или подпишитесь на основе обратного вызова
String response = new String(msg.getData(), StandardCharsets.UTF_8)
d.subscribe(“subject”);
Запросить ответ
NATS поддерживает два типа сообщений ответа на запрос: точка-точка или многие-ко-многим. Точка-точка предполагает самый быстрый или первый ответ. При обмене сообщениями «один ко многим» необходимо ограничить пределы ответа на запрос.
В процессе запроса на ответ запрос на выпуск публикует сообщение с темой ответа, и ожидается, что он ответит на эту тему.
Connection connection = Nats.connect(“nats://127.0.0.1:4222”);
String reply = “replyMsg”;
// Запрос ответного метода
// Запрос на подписку
connection.publish(“requestSub”, reply, “request”.getBytes(StandardCharsets.
Connection nc = Nats.connect(“nats://127.0.0.1:4222”);
// Зарегистрироваться для подписки
nc.publish(msg.getReplyTo(), “this is reply”.getBytes(StandardCharsets.UTF_8));
dispatcher.subscribe(“requestSub”);
Подписчики очереди и совместная работа
Connection nc = Nats.connect();
System.out.println(«msg: » + new String(msg.getData(),StandardCharsets.UTF_8));
d.subscribe(“queSub”, “queName”);
Интеграция Nats-Spring
Хотя NATS является очень хорошим промежуточным ключом сообщения, его интеграция с Spring не очень хороша. Вот две интегрированные идеи
CloudFoundry-Community/java-nats
Wanlinus/nats-spring
java-nats
Это Java-клиент NATS, в котором доминирует CloudFoundry. Обеспечивает отличие от официального клиента nats, поддерживает настройку аннотаций и обеспечивает лучшую поддержку Spring, но этот проект не обновлялся более года и не поддерживает потоковую передачу NATS. Для соответствующего использования, пожалуйста, обратитесь к Github, который не будет подробно объясняться здесь.
public class NatsDemo2Application <
public static void main(String[] args) <
Приглашаем друзей-инженеров Java присоединиться к обмену архитектурой Java: 874811168
SpringApplication.run(NatsDemo2Application.class, args);
public void message(Message message) <
System.out.println(message.getSubject() + » : » + new String(message.getData()));
Введение в NATS Streaming
NATS родился, потому что NATS не может гарантировать правильность доставки сообщений и других недостатков. Это система потоковой передачи данных, работающая на базе NATS. Она написана на Go. Потоковая трансляция NATS бесшовно встроена и расширена за счет базовой платформы NATS. Помимо функций базовой платформы NATS, он также предоставляет следующие функции:
Функции потоковой передачи NATS
Улучшенный протокол сообщений
Постоянство сообщения / события
По крайней мере, одна передача данных (по крайней мере, один раз доставки)
Ограничение скорости издателя
Соответствие абонентской скорости (ограничение на лимит)
Воспроизведение исторического сообщения по теме
Прежде чем использовать потоковую передачу NATS, сначала используйте сервер. Здесь я решил использовать докер-контейнер.
Порт подключения по умолчанию для клиента 4222
STREAM: Starting nats-streaming-server[test-cluster] version 0.11.0
STREAM: ServerID: bzkKJL3jI4KW9Hqb0bC1Ae
STREAM: Go version: go1.11
Starting nats-server version 1.3.0
Git commit [not set]
Starting http monitor on 0.0.0.0:8222
Listening for client connections on 0.0.0.0:4222
STREAM: Recovering the state…
STREAM: No recovered state
STREAM: Message store is MEMORY
STREAM: Channels: 100 *
STREAM: Subscriptions: 1000 *
STREAM: Messages : 1000000 *
STREAM: Bytes : 976.56 MB *
STREAM: Age : unlimited *
STREAM: Inactivity : unlimited *
// Первый параметр указывает clusterId, который определяется при запуске контейнера потоковой передачи NATS
// Второй параметр представляет clientID, уникальный идентификатор подключенного клиента
StreamingConnectionFactory cf = new StreamingConnectionFactory
// Установить адрес и порт сервера Nats, по умолчанию это nats: //127.0.0.1: 4222
StreamingConnection sc = cf.createConnection();
Publish: sc.publish(“foo”, “Hello World”.getBytes());
System.out.println(new String(msg.getData(), StandardCharsets.UTF_8));
Как отличное промежуточное программное обеспечение для обмена сообщениями, но оно не интегрирует Spring, это очень плохо. Поэтому, чтобы его было удобно использовать на работе, я разработал небольшой плагин. Хотя все еще есть большие улучшения Пространство, но оно может очень хорошо работать в проектах компании. Его идеи развития похожи на идеи nats-spring, поэтому методы использования аналогичны следующим образом:
nats-streaming-spring
Приглашаем друзей-инженеров Java присоединиться к обмену архитектурой Java: 874811168
Предоставьте бесплатные учебные материалы по архитектуре Java в группе
cluster-id: test-cluster
@EnableNatsStreaming
public class StreamingDemoApplication <
public static void main(String[] args) <
// Чтобы опубликовать сообщение, вам нужно только ввести StreamingConnection
private StreamingConnection sc;
public void sendMsg()<
sc.publish(“foo”, “publish message”.getBytes())
@Subscribe(value = “foo”, durableName = “dname”, queue = “queue”)
public void asd(Message message) throws IOException <
System.out.println(new String(message.getData(), StandardCharsets.UTF_8));
Поскольку два плагина написаны для объединения проектов, некоторые их части не являются универсальными. Я буду продолжать абстрагироваться и улучшать в дальнейшем развитии.
Интеллектуальная рекомендация
Spring Cloud Micro-Service Framework Set (2) Создайте поставщик услуг
Центр регистрации по строительству услуг поставщика услуг похож на После создания хорошего проекта: Bootstrap.yml Конфигурация выглядит следующим образом Eureka.client.serviceurl.defaultzone: адрес зд.
Java параллельное программирование: синхронизированный и принцип его
Оригинал: http://www.cnblogs.com/paddix/p/5367116.html Java параллельное программирование: синхронизированный и принцип его Java серия параллельного программирования: Java параллельное программировани.
Весенний проект экспортирует и запускает пакет jar
В последнее время необходимо решить проблему импорта исполняемых jar-пакетов из проектов Maven. Если проект не включает Spring, используйте mvn assembly: assembly. 1. Сначала добавьте в pom.xml: 2. За.
SLF4J Ошибка: не может разрешить метод «Информация» (Java.lang.String) ‘
проблема: Произошла ошибка при использовании @ SLF4J: не может разрешить метод «Info (Java.lang.String)», log не имеет информационного метода. Решения: Во-первых, я подозреваю, что нет пла.
Класс Python с Object Part1
1. Строка экземпляра модификации представлена, что делает результат более значимым Если вы не делаете особый процесс, общая ситуация мы распечатаем экземпляр объекта, который является результатом выхо.