Что такое шина в программировании

Что означает шина(bus) в программировании?

Изучая исходники, столкнулся с абстрактным понятием шина или bus. Т.к. огромный python-пакет завязан на этом понятии, мне трудно уловить суть. Не могли бы вы, товарищи трукодеры разжевать это понятие в программировании? Гугл посылает на схемотехническое определение шины.

• python
• шаблоны-проектирования

Отслеживать

561 5 5 серебряных знаков 25 25 бронзовых знаков

ESB (enterprise service bus): назначение, функционал, новые подходы к развитию

ESB — это программное обеспечение, благодаря которому возможен обмен данными между разными информационными системами предприятия. Иначе оно называется интеграционной или сервисной шиной. Наличие ESB можно считать конкурентным преимуществом, ведь быстрая связь между корпоративными приложениями экономит время и рабочие ресурсы. Рассказываем, как устроена интеграционная шина, как она работает, какие процессы может осуществлять.

Что такое интеграционная шина и как она устроена

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

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

Важно

Понятие интеграции многогранно. В него входят такие задачи, как использование несколькими системами общих справочников (например, списка клиентов, каталога товаров), действия одного сервиса в ответ на событие в другом, организация одних и тех же бизнес-процессов в двух и более приложениях. Автоматический обмен данными с клиентами и партнерами, обеспечение единого стандарта взаимодействия между филиалами — это тоже примеры корпоративной интеграции программного обеспечения. [1]

Для наглядности рассмотрим на примере, как это работает. Предположим, пользователь входит в личный кабинет на сайте страховой компании. Он видит свое имя, даты окончания страховки, новые предложения от компании. Все эти данные собраны из разных систем и предоставляются через различные интерфейсы. Более того, каждое приложение может быть создано на различных технологических стеках разными командами разработчиков.

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

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

Если в одну из систем потребуется внести изменения, это никак не повлияет на работу других корпоративных приложений. За все эти задачи будет отвечать только шина данных ESB [2] .

Таким образом, ESB-подход, в отличие от традиционной архитектуры «точка-точка» (когда сервисы напрямую взаимодействуют друг с другом), обладает большей гибкостью. Сценарии интеграции можно модифицировать с минимальным вмешательством разработчиков. [3]

Преимущества решения очевидны. Упрощение интеграции приложений путем внедрения ESB дает экономию времени и денег, улучшает функционирование сервисов, что в конечном итоге работает на повышение эффективности организации и на увеличение прибыли предприятия.

Несколько слов о том, как устроена интеграционная шина. Решение включает в себя несколько компонентов:

• Брокер сообщений — обеспечивает управление очередностью сообщений и выступает посредником между приложением-источником и приложением-приемником;
• Комплект адаптеров — программных компонентов, которые служат для связи приложений с ESB и преобразуют один интерфейс в другой. Чем больше различных адаптеров заложено в интеграционную шину, тем шире ее функционал;
• В современных ESB-решениях реализованы принципы микросервисной архитектуры. В соответствии с ними весь функционал системы распределяется между микросервисами, каждый из которых может работать независимо от других;
• Средства для контроля и мониторинга.

Интеграция программных модулей

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

Маршрутизация сообщений

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

Преобразование сообщений

Данные из разных систем могут быть представлены в различных форматах — XML, CSV, JSON, DBF и других. При классическом подходе «точка-точка» это затрудняет процесс «общения» приложений между собой. Сервисная шина предприятия решает проблему, преобразуя данные из неподходящего формата в подходящий. Например, если нужно отправить одно и то же сообщение и в ERP, и в CRM, ESB трансформирует данные нужным образом и передаст в соответствующие системы.

Масштабируемость

Благодаря этому свойству ESB может работать с различным количеством информационных систем и различными объемами данных, распределяя нагрузку между приложениями. Интеграционная шина обеспечивает передачу данных любого объема, разбивая крупные массивы на более мелкие. Обработка информации по частям в случае сбоя предотвращает потерю данных и необходимость заново передавать уже отправленные пакеты. Масштабируемость также обеспечивает возможность неограниченного наращивания информационных мощностей предприятия, причем IT-ландшафт не обязательно должен быть однородным.

Традиционная SOA-архитектура с ESB в качестве центрального компонента еще несколько лет назад была на пике популярности. Но совершенству нет предела, и классический подход получает новое развитие. Следующим этапом эволюции технологий интеграции с ESB стала микросервисная архитектура. Она позволила решить типичные проблемы, обнаружившиеся в процессе «обрастания» шины бизнес-логикой: тяжеловесность, многослойность с тесной взаимосвязью слоев, сложность внесения изменений и другие недостатки, свойственные монолитности.

На заметку

В сервис-ориентированной архитектуре, частью которой является ESB, объединяются все API, что обеспечивает сквозную интеграцию. API — это своего рода контракт, в котором описаны условия «общения» программ между собой: входные и выходные данные, типы операций. Использование API значительно упрощает взаимодействие: он связывает воедино возможности разных сервисов, образуя доступные разным пользователям интерфейсы [4] .

Чем отличается микросервисная архитектура от традиционного подхода с ESB шиной?

Ее функциональность разбита по маленьким сервисам, каждый из которых отвечает за отдельную бизнес-задачу (решая ее в совершенстве), поддерживается одной командой и может работать изолированно от других. Централизованной базы данных здесь нет, у каждого сервиса — свое хранилище информации. ESB при этом выполняет лишь функцию транспорта, являясь по сути просто брокером сообщений. Взаимодействие между пользователем и сервисами также осуществляется через API, но программный интерфейс не содержит бизнес-логики [5] .

Независимость микросервисов друг от друга обеспечивает ряд преимуществ с точки зрения эксплуатации и развития информационной системы предприятия:

• простота внесения изменений в приложения, не требующая обновлений всей системы;
• легкость тестирования и автоматизации отдельных компонент системы;
• лучшее понимание процесса командой поддержки — когда каждый компонент обслуживается 1-2 разработчиками, все четко осознают свои задачи.

Выбирая платформу для интеграции, лучше рассмотреть гибкое решение, отвечающее всем современным потребностям. В настоящий момент это ПО с открытым исходным кодом и технологии интеграции на основе микросервисной архитектуры.

• 1,6 https://compress.ru/article.aspx?id=21413
• 2 https://habr.com/ru/company/pnn/blog/191600/
• 3 https://coderlessons.com/tutorials/java-tekhnologii/uznaite-mulesoft/mulesoft-kratkoe-rukovodstvo
• 4 https://habr.com/ru/company/piter/blog/431176/
• 5 https://habr.com/ru/company/dataart/blog/280083/, https://microarch.ru/blog/soa-vs-msa

Что такое шина в программировании

Одно из основных требований современного клиентского программного обеспечения — синхронизация состояния между несколькими устройствами. Это как устройства в рамках концепции «Интернета вещей», так и пользовательские приложения, которые должны работать на различных устройствах одного пользователя.

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

Для организации реактивного поведения программного обеспечения используют в основном две архитектурные концепции:

• очередь сообщений
• шина сообщений

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

Об основных принципах построения, технических ограничениях, горизонтальном масштабировании поговорим в этом стриме.

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

Интересно рассмотреть следующие особенности шины, используемой в вычислительно технике:

Шина это просто провод

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

Примечание: на практике есть окно в рамках которого шина сохраняет свое состояние — это либо окно синхронизации (время которое нужно чтобы сообщение распространено на все узлы системы), либо время необходимое для пассивного предоставления данных.

У шин есть два варианта реализации:

• последовательная
• параллельная

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

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

Под каждую задачу своя шина

В компьютере шины делят по своему назначению «шина данных», «адресная шина», «шина управления». Это позволяет упростить обработку данных, находящихся в шине и решет проблему одновременной обработки данных. параллельно можно обрабатывать данные только в нескольких шинах.

Шина не определяет когда из нее должны быть считаны данные

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

Очередь как расширение ограничений шины

Так как шина не хранит данные, не оповещает о изменении данных, не гарантирует целостность данных, то для в программном обеспечении как правило используется комбинация «шина» + «очередь сообщений». Очередь — это реализации классической структуры данных, функционирующей по принципу FIFO. В задачи такого решения входит и накопление сообщений, и оповещение клиентов о получении новых сообщений, и гарантии доставки сообщений.

Таким образом очередь сообщений — это усовершенствованная идея «шины» из вычислительной техники. Однако на практике реализация простой шины в реактивных приложениях может оказать сильно проще и предпочтительнее использования «очереди сообщений»

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

Так как шина не имеет истории сообщений, то в момент доставки сообщения существует два варианта поведения шины:

• новые сообщения не принимаются в доставку;
• доставка предыдущего сообщения прекращается и все клиенты начинают получать новое сообщение;

Основная проблема, которую должен решить архитектор при использовании шины сообщений — это отказ в обслуживании в момент, когда очередь занята доставкой сообщения своим клиентам. Для решение этой проблемы можно модифицировать шину сообщений, добавив буфер для хранения принятых сообщений, порядок обработки в буфере определяется принципом FIFO (очередь).

Очередь — это усовершенствованная идея работы шины сообщений. Для реализации вносятся следующие изменения:

• сообщения сохраняются в очередь
• доступ к сообщениям по принципу очереди (сообщения извлекаются из очереди)
• информация о изменениях очереди направляется через события (опционально)

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

Прием сообщения осуществляется в несколько этапов:

• сначала сообщение принимается в буфер обмена;
• затем сообщение обрабатывается (приводится из текстового вида в структуры данных);
• затем отправитель уведомляется об успешной приемке сообщения.

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

Для проектирования необходимо принять решение о стратегии доставки сообщений. Выделяют следующие стратегии доставки сообщений:

• Доставка без подтверждения (0, 1 или много);
• Доставка минимум одной копии сообщений (1 или много — at most once) ;
• Доставка максимум одной копии сообщения (0 или 1 — at least once);
• Доставка только одной копии сообщения (только 1 — exactly once).

Для шины сообщений используется как правило доставка без подтверждения или доставка максимум одной копии, для очереди как правило используется все варианты кроме доставки без подтверждения.

Шина сообщений организуется на базе двух вариантов доставки:

• широковещательная
• адресная

Широковещательная

в случае широковещательной доставки, всем клиентам подключенным к серверу предоставляется копия сообщения (режим «чата»). Клиенты сами решают нужно ли обрабатывать сообщений, или сообщение должно быть откинуто. Для того чтобы сообщения могли быть обработаны, в структуре сообщения должна быть служебная информация, необходимая для принятия решения.

• простая схема;
• хорошо масштабируется (могут быть построены гетерогенные схемы где клиенты являются пользователями или серверами);

• Большой overhead
• плохая безопасность (все получат сообщение, даже если оно им не предназначается)

Адресная

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

• низкий overhead
• возможность маршрутизации сообщений

Способы получения сообщений

Разделяют активный и пассивный способ получения данных или push/pull подходы

Push

Это активный способ, при котором сообщение не хранится на сервере (или хранится только в рамках окна синхронизации), а отправляется всем клиента, имеющим активное подключение (push).

Либо сообщение отправляется во все эндпоинты серверов, неподключенных к шине

Pull

В шине не реализуется

Сообщения

Способ рассылки оповещений не используется в шине, так как шина не хранит данные долгосрочно (кроме технологических временных окон).

Очередь поддерживает так же pull и push режимы работы, но кроме этого дополнительно может оповещать клиентов о получении сообщений.

Очередь не поддерживает широковещательный способ доставки сообщений, но на практике такой способ доставки поддерживается и в таком случае очередь функционирует как обычная шина.

Режимы работы очереди следующие:

Общий режим

В этом режиме к очереди сообщений имеют доступ все пользователи и сообщения извлекаются из очереди первым обратившимся клиентом

Приватный режим

В этом режиме для каждого клиента ведется своя очередь сообщений, при этом возможно копирование одного и того же сообщения нескольким приватным адресатам (широковещательная рассылка)

Способы получения сообщений

Push

Может быть реализована только в приватном режиме, в таком случае все клиенты получают свои сообщения сразу после получения на сервере

Pull

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

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

События

В случае pull режима очередь может оповещать клиентов о получении сообщений через рассылку событий.

События — это по сути облегченный вариант сообщения. Такой вариант имеет смысл, когда объем данных, передаваемый в сообщении через очередь будет слишком велик, тогда существует возможность «легкого» оповещения клиента и предоставление ему возможности длительной загрузки сообщения.

Шина

Шина – совокупность линий, иногда просто проводников, соединяющая несколько компонентов в цифровой системе. Эти линии делятся на 3 типа – адреса, данных и управления. Иногда по одним и тем же проводникам в разные моменты времени передаются и адрес и данные – в этом случае говорят, что шина мультиплексирована. Подключенные к шине устройства подразделяются на 2 основных типа – master ( главный, способный управлять шиной, обычно это контроллер шины) и slave ( подчиненный). Остальные типы, встречающиеся гораздо реже, являются комбинациями первых двух.

Одна из первых шин в РС была 8-битная шина, вначале не имевшая никакого названия. Если взглянуть на современную материнскую плату, можно увидеть, что шина ISA состоит из двух неравных частей. Большая часть и является той предшественницей современной, вернее, теперь уже устаревшей шины ISA .

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

Со временем производительность микропроцессора и переферийных устройств возросла, мощность периферийных устройств тоже. 8-битная шина стала узким местом системы, не справляясь с возросшим потоком проходящей по ней информации. Нужна была новая шина, но при этом она должна быть совместимой с картами расширения, использовавшимися ранее – при покупке новой системы пользователи могли использовать некоторые компоненты старой. В отношении стоимости это был небольщой выигрыш (контроллеры дисков, старые видеокарты, порты ввода-вывода стоили уже тогда довольно дешево), но это сильно действовало психологически – при покупке машины можно было сэкономить на некоторых компонентах. Новая шина вначале называлась АТ -bus , но потом прижилось название ISA (Industry Standard Architecture) . Шина была совместима с своей 8-битной предшественницей, отличалась только частота тактового сигнала (до сих пор некоторые 8-битные карты работают на современных платах с Pentium III , заменяя сгоревшие встроенные порты ввода-вывода)

Шина имеет раздельные линии адреса, управления и данных. Частота тактового сигнала шины – 8 МГц(иногда в материнской плате предусмотрено ее повышение до 10МГц, но оно может привести к нестабильной работе старых ISA- карт). Следует иметь в виду, что скорость передачи данных по шине гораздо меньше, чем 8*10 6 *2 = 16 Мбайт / сек, так как передача одного слова данных происходит в течение 4-5 циклов тактового генератора.

Шина ISA 16-разрядная, с возможностью ввода состояний ожидания. Так как сохранена совместимость с 8-битными картами, на шине имеется контакты( MEM16 – для памяти и IO16 – для карт ввода-вывода) позволяющий определить, какая карта – 8 или 16-битная присутствует на шине. Если сигнал активен – 16 бит записываются или читаются за 1 такт, если неактивен – за 2 такта, по 8 бит в каждом такте.

На шине есть линии прерывания IRQ (Interrupt Request) и прямого доступа в память DMA (Direct Memory Access). О них стоит рассказать подробнее.

Линии прерывания служат для того, чтобы сигнализировать процессору (в нашем случае – контроллеру шины, который транслирует прерывания шины в прерывания процессора) о том, что на шине произошло некоторое событие, требующее переключения процессора с выполнения основной задачи на задачу обработку этого события. В некоторой области памяти существует таблица, где хранятся адреса процедур обработки прерывания (эта таблица называется таблицей векторов прерываний). Как только сигнал прерывания получен процессором, он выполняет команду перехода (безусловного или условного) на строку таблицы, соответствующей данному прерыванию. Затем по адресу, полученному из таблицы, производится переход в ту область памяти, где хранится процедура обработки прерывания.

Прямой доступ к памяти ( DMA) – процедура, позволяющая освободить центральный процессор от задачи чтения данных из устройства ввода-вывода и записи их в память для выполнения других задач. В этом случае операция чтения – записи производится самим внешним устройством ( которое должно быть достаточно «интеллектуально”) или контроллером DMA. Для выполнения прямого доступа в память устройство ввода-вывода вставляет на соответствующих линиях шины (они называются DRQ 1-DRQ7 –DMA Request) сигнал запроса прерывания. Если прямой доступ к памяти возможен, процессор выставляет сигнал DACK 1-DACK7 (DMA Acknowledge) разрешения DMA и передает управление шиной внешнему устройству или контроллеру DMA , которые и формируют все необходимые сигналы управления и синхронизации. Процессор в это время может выполнять другие задачи, требующие его » внимания ” .

Адресное пространство, или диапазон адресов, к которым можно обращаться с шины ISA составляет 2 24 или 16 Мслов. Однако на практике редко встречаются карты, позволяющие адресовать все адресное пространство шины. Дело в том, что многие старые карты не анализируют разряды адреса старше 10 и поэтому могут пересекаться по адресам с картами, которые их используют. Так, например, для старых карт адреса 0 xF3F0 и 0x3F0 будут одинаковыми (регистр данных жесткого диска) , поэтому при установке двух карт – новой с адресом 0xF3F0 и старой с адресом 0x3F0 на шине возникнет конфликт (так называется ситуация, когда несколько устройств пытаются в одно и то же время выдать данные на шину)

Шина ISA сохранилась в комьютерах до сих пор, несмотря на многочисленные попытки гигантов компьютерной индустрии (Intel, Microsoft) убрать ее из PC. По сегодняшним меркам, ISA – очень медленное устройство, обращение к которому тормозит работу всей системы. Но простота проектирования устройств на ней и огромное количество уже выпущенных для нее карт расширения, в том числе специальных, не позволяют отказаться от ее использования. Кроме того, для некоторых устройств (например, модемов) скорость шины ISA вполне достаточна.

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