Архитектура с наличием информационной шины (6 видео)

Шина – набор проводников, объединенных едиными функциями. В структуре с общей шиной все устройства ВМ подключаются к системной шине (магистрали). Все устройства ввода-вывода (УВВ) имеют встроенную небольшую микросхему – контроллер, управляющий операциями обмена данными.

Рис. 1.3. Архитектура на основе общей шины

— простота изменения конфигурации.

— единственная шина для разнообразных потоков данных, сильно отличающихся по скорости (например, процессор-память и процессор-принтер);

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

Архитектура с иерархией шин

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

Рис. 1.4. Архитектура с иерархией шин

Структуры вычислительных систем

ВС с общей памятью

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

Рис. 1.5. Структура вычислительной системы с общей памятью

Распределенная ВС

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

Рис. 1.6. Структура распределенной вычислительной системы

Содержание

Архитектура с наличием информационной шины
Архитектура шины данных
Архитектура системы с общей шиной
События, шины и интеграция данных в непростом мире микросервисов
Что мы сделали?
Что это значит?
Как это работает?
Что мы придумали?
📺 Видео

Видео:Шины - ключевой элемент качественной архитектуры | Андрей ПутинСкачать

Архитектура с наличием информационной шины

главная >> наши решения >> информационная шина данных

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

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

Объекты автоматизации и пользователи

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

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

Единая информационная шина

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

Каждый из АПК может быть зарегистрирован на информационной шине, как публикатор информационных сообщений. Это означает, что в момент наступления определенного события в АПК, он оповещает об этом шину данных, передавая ей регламентированную информацию. Например: в АПК2 произошло изменение информационного справочника, и, поскольку АПК2 зарегистрирован как публикатор данного справочника в информационной шине, он информирует шину о том, что в справочник внесено изменение, передавая регламентированный документ в XML- формате.

Каждый из АПК может быть зарегистрирован на информационной шине, как подписчик на публикуемые информационные сообщения. Это означает, что для этого АПК, информационная шина будет накапливать информацию из одного или нескольких источников, на которые он подписан. Например: АПК1 подписан на любые изменения информационного справочника в АПК2, и при проверке сообщений для АПК1, шина информирует о наличии сообщения для АПК1 от АПК2, далее АПК1 извлекает это сообщение как документ в XML- формате.

Если информацию об изменении информационного справочника АПК2 необходимо получить в АПК3, достаточно подписать АПК3 на изменения информационного справочника АПК2.

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

Видео:Архитектура шины DATAREON ESBСкачать

Архитектура шины данных

К распространенным типам архитектуры шины данных относятся ISA, EISA, Micro Channel® и PCI. Каждая из них физически отличается от остальных.

· ISA (Industry Standard Architecture).

ISA — это архитектура, используемая в компьютерах IBM PC, XT™, AT и совместимых с ними. Чтобы дополнить систему различными адаптерами, необходимо установить платы в слоты расширения. В 1984 году (когда IBM представила IBM PC/AT) ISA была расширена с 8 разрядов до 16. ISA — это название самого слота (8- или 16-разрядного). 8-разрядные слоты короче 16-разрядных, которые состоят из двух слотов, следующих один за другим. Поэтому 8-разрядная плата может быть вставлена в 16-разрядные слоты, но не наоборот.

ISA была стандартной архитектурой персональных компьютеров, пока Compaq и несколько других компаний не разработали шину EISA.

· EISA (Extended Industry Standard Architecture).

Этот стандарт шины был представлен в 1988 году консорциумом из девяти компьютерных компаний: AST® Research, Inc., Compaq, Epson®, Hewlett-Packard®, NEC®, Olivetti®, Tandy®, Wyse® Technology и Zenith®.

EISA предлагает 32-разрядную шину, совместимую с ISA. Кроме того, она поддерживает дополнительные возможности, которыми обладает шина Micro Channel Architecture, разработанная IBM.

· MCA (Micro Channel Architecture).

IBM представила этот стандарт в 1988 году как часть своего проекта PS/2. Эта архитектура электрически и физически несовместима с шиной ISA. В отличие от ISA, Micro Channel работает и как 16-разрядная, и как 32-разрядная шина. Несколько процессоров контроля шины могут независимо управлять ею.

· PCI (Peripheral Component Interconnect).

Это 32-разрядная локальная шина, которая используется в большинстве компьютеров с процессором Pentium и в компьютерах Apple Power Macintosh®. Современная архитектура PCI удовлетворяет большинству требований технологии Plug and Play. Plug and Play — это одновременно и философия построения персонального компьютера, и набор спецификаций его архитектуры. Цель технологии Plug and Play — возможность изменить конфигурацию персонального компьютера без вмешательства пользователя, т.е. максимально упростить подключение любого устройства. Одной из операционных систем, поддерживающих спецификацию Plug and Play, является Microsoft Windows 95.

Видео:АПС Л14. ШиныСкачать

Архитектура системы с общей шиной

Архитектура распределенной системы промышленной автоматизации на основе общей шины показана на рис. 1.7. Для того, чтобы получить данные из модуля или контроллера, компьютер (или контроллер) посылает в шину его адрес и команду запроса данных. Микропроцессор, входящий в состав каждого модуля или контроллера, сверяет адрес на шине с его собственным адресом, записанным в ПЗУ, и, если адреса совпадают, исполняет следующую за адресом команду. Команда позволяет считать данные, поступающие на вход устройства, или установить необходимые данные на его выходе.

Распределенная система с общей шиной порождает две новые проблемы по сравнению с топологией «точка-точка» (когда соединяются только два устройства, как на рис. 1.1): необходимость адресации устройств и необходимость ожидания в очереди. Добавление адреса в коммуникационный пакет снижает скорость обмена при коротких сообщениях, а обмен по общей шине приводит к тому, что каждое устройство для передачи сообщения должно ждать, когда шина станет свободной. Это замедляет скорость обмена между устройствами по сравнению с топологией «точка-точка». Задержка в сетях с большим количеством устройств становится существенным ограничением на применение топологии с общей шиной [Kim] в некоторых приложениях, в частности, в случае ПИД-регулирования, когда задержка в сети ограничивает тактовую частоту работы контура регулирования. Для таких случаев используют локальные подсети или локальные технологические контроллеры.

Читайте также: Степень износа шин нокиан

Архитектура с наличием информационной шины

Рис. 1.7. Пример архитектуры распределенной системы сбора данных и управления на модулях RealLab! Расшифровку обозначений см. во введении к разделу «Разновидности архитектур» и «Требования к архитектуре».

Распределенные системы позволяют решить также следующую проблему. С ростом количества датчиков в системе, показанной на рис. 1.1, увеличивается число и суммарная длина проводов, соединяющих датчики с устройством ввода. Это приводит не только к росту стоимости кабельного оборудования, но и к проблемам, связанным с электромагнитными наводками, особенно если датчики распределены по большой площади (например, в промышленной теплице датчики распределены по площади около 6 Га, а в элеваторе число датчиков достигает 3. 5 тыс. шт.). В распределенной системе модули ввода-вывода изготавливаются с небольшим количеством входов (обычно от 1 до 16), а сами модули располагаются вблизи места установки датчиков. Увеличение количества датчиков (входов) достигается путем наращивания числа модулей и объединения их с помощью общей шины. Это сокращает общую длину проводов в системе, а также длину проводов с аналоговыми сигналами.

Связь отдельных устройств в распределенной системе может осуществляться с помощью любой промышленной сети, см. раздел»Промышленные сети и интерфейсы». Наиболее распространены в России сети Profibus, что связано с популярностью изделий фирмы Siemens, а также сети Modbus с физической шиной RS-485 благодаря распространенности модулей и контроллеров фирм ICP DAS, Advantech и НИЛ АП. За последние годы стремительно возросло количество используемых сетей Ethernet (точнее, Industrial Ethernet) в качестве промышленных сетей при скорости передачи 10, 100 и 1000 Мбит/с.

Некоторые модули ввода-вывода, входящие в состав распределенных систем, позволяют по команде из компьютера выполнять функции автоматического регулирования (например, модули NL-8TI, NL-16AI фирмы НИЛ АП). Для этого в них посылают значение уставки и параметры ПИД-регулятора (пропорциональный, дифференциальный и интегральный коэффициенты), затем команду запуска процесса регулирования. Наличие ПИД-регулятора в модулях распределенной системы позволяет осуществить локальное регулирование (например, поддержание стабильной температуры в камере тепла и холода), разгрузив общую шину для выполнения других задач.

Распределенные системы строятся, как правило, из коммерчески доступных компонентов (ПЛК, модулей ввода-вывода, датчиков, исполнительных устройств). Однако для однотипных тиражируемых систем может быть выгодно строить специализированные системы, состоящие из полностью заказных (вновь спроектированных) аппаратных и программных средств [Garcia]. Граница целесообразности такого подхода определяется объемом выпуска изделий.

Программирование распределенных систем автоматизации выполняется стандартными средствами, рассмотренными в разделе»Программное обеспечение».

* Валидация — подтверждение соответствия системы требованиям ее назначения. Выполняется с участием потребителя. Не путать с верификацией — доказательством достоверности. Валидация — это верификация с участием потребителя (терминология стандарта ИСО 9001)

** Отображение — закон, по которому каждому элементу одного множества ставится в соответствие единственный элемент другого множества.

Видео:Различия SOA и микросервисной архитектуры за 9 минутСкачать

События, шины и интеграция данных в непростом мире микросервисов

Валентин Гогичашвили объясняет микросервисы. Перед вами расшифровка доклада с Highload++.

Добрый день, я Валентин Гогичашвили. Все слайды я сделал латиницей, надеюсь не будет проблем. Я из Zalando.

Что такое Zalando? Наверное, вы знаете Lamoda, Zalando был папой Lamoda своё время. Чтобы понять, что такое Zalando, нужно представить Lamoda и увеличить в несколько раз.

Zalando – это магазин шмоток, мы начали продавать обувь, очень хорошую между прочим. Начали расширяться всё больше и больше. Снаружи сайт выглядит очень просто. За 6 лет что я работаю в Zalando и за 8 лет существования — эта компания была одной из самых быстрорастущих в Европе в какое-то время. Шесть лет назад, когда я пришел в Zalando, она росла где-то 100%.

Когда я начинал 6 лет назад, это был маленький стартап, я пришёл довольно поздно, там уже было 40 человек. Мы начинали в Берлине, за эти 6 лет мы расширили Zalando Technology на много городов, включая Хельсинки и Дублин. В Дублине сидят data-science’ы, в Хельсинки сидят mobile developer’ы.

Zalando Technology растёт. На данный момент мы нанимаем в районе 50 человек в месяц, это страшное дело. Почему? Потому что мы хотим построить самую крутую fashion-платформу в мире. Очень амбициозно, посмотрим, что получится.

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

Zalando начинался как маленький сервис у которого было 3 уровня: web applicaton, backend и база данных. Мы использовали Magento. К тому моменту, когда меня позвали в Zalando, мы были самыми большими пользователями Magento в мире. У нас были огромные головные боли с MySQL.

Мы начали проект REBOOT. Я и пришел на этот проект 6 лет назад.

Что мы сделали?

Мы переписали все на Java, потому что мы знали Java. Мы поставили везде PostgreSQL, потому что я знал PostgreSQL. Ну и Python – это дело техники. Практически любой нормальный человек меня поддержит, что Python для tooling’a — это единственное правильное решение (люди из мира Perl, не убивайте меня). Python это хорошая шутка для написания tooling.

У нас начала развиваться такая схема:

У нас была система macro services. Java Backend, PostgreSQL storage c PostgreSQL шардингом. Я два года назад на этой же конференции рассказывал о том, как мы делаем PostgreSQL-шардинги, как мы управляем схемами, как мы выкатываем версии без downtime, было очень интересно.

Как я сказал, Java мы все знали. SOAP использовался для объединения macro-сервисов друг с другом. PostgreSQL давал нам возможность иметь очень чистые данные. У нас была схема, чистые данные, транзакции и хранимые процедуры, котором мы научили всех java-developer’ов или тех, кто еще остались из PHP-мира, которых мы научили Java и хранимым процедурам.

Один хинт: если вы находитесь в режиме меньше 15 миллионов пользователей в месяц, то вы можете использовать систему Java SProc Wrapper для автоматического шардирования PostgreSQL из Java. Очень интересная штука, которая PostgreSQL в RSP-систему, по существу.

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

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

Мы им говорили: вы должны писать на Java, если вы уйдете, что мы будем делать? Если вы напишите что-то на Haskell или на Clojure и уйдете что мы будем делать? А они нам отвечали fuck you.

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

Читайте также: Ситроен ds4 размеры шин

Видео:Андрей Путин. Интеграционные шины – ключевой элемент качественной архитектурыСкачать

Что это значит?

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

Они могут выбрать своё собственное технологический стэк. Если команда решила, что они будет писать на Haskell или Clojure, то пусть так и будет. Но за это надо платить. Команды должны поддерживать сервисы, которые они написали сами, просыпаться ночью сами. Включая выбор персистент стэка. Мы вам научили PostgreSQL, если вы хотите выбрать MongoDB, а нет стоп, MongoDB у нас заблокирован. У нас есть радар технологий в котором мы проводим помесячные опросы и технологии, которые считаем опасными, ставим на красный сектор. Это означает, что команда могут выбирать эти технологии, но они пенять полностью на себя, если что-то пойдет не так.

Мы сказали, что команды будут изолированы своими AWS-аккаунтами. До этого мы были в своих собственных дата центрах, выбрав AWS, мы пошли на сделку с дьяволом. Мы сказали, мы знаем, что это будет стоить дороже, но мы будем двигаться быстрее. У нас не будет ситуаций как до этого, в собственных дата центрах: для того, чтобы заказать один жесткий диск, требовалось 6 недель. Это было невыносимо и невозможно. Мы не могли двигаться вперед.

Очень многие люди считают, что автономия — это анархия. Автономия — это не анархия. С автономией приходит очень много ответственности, особенно для Zalando, которая publicly traded company. Мы на бирже и как в любую publicly traded company к нам приходят аудиторы и они проверяют, как работают наши системы. Мы должны были создать какую-то структуру, которая позволит нашим developer’ам работать с AWS, но всё же оставаться способными отвечать на вопросы аудиторов уровня: «Почему у вас это IP-адрес в публичном доступе без идентификаций?»

Получилась вот такая система:

Мы хотели сделать её максимально простой, она действительно простая. Но все ругаются, когда видят её.

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

Конечно же мы сказали, что для того чтобы поддерживать разнородный стэк технологий мы поднимаем уровень стандартизации с Java и PostgreSQL на более высокий уровень. Мы поднимаем уровень стандартизации на уровень REST APIs.

Что это значит? Я отмечал это на предыдущем докладе о том, что нам нужна система описания API. Описание системы того как микросервисы общаются друг с другом. Нам нужен порядок. На каком-то уровне нам нужно стандартизироваться. Мы объявили о том, что у нас будет система API first. И что каждый сервис перед тем как его начнут писать, команда должна прийти в API гильдию и уговорить их принять API в состав утвержденных API. Мы написали REST API guidelines, очень интересные. На них даже ссылались в некоторых ресурсах. API first библиотеки, которые позволяют использовать Swagger (OpenAPI) в качестве руторов для сервера. Например, connection — это рутор для flask’a в Python, а play-swagger — это рутор для play-системы в Scala. Для Clojure есть такой же рутор, это очень удобно. Вы пишите сперва Swagger файл, описываете то, чего вы хотите добиться от своего микросервиса, а потом просто указываете, какие функции в вашей системе должны исполнять те или иные операции в API.

Но проблема с микросервисами. Я хочу несколько раз повторить эту фразу. Микросервисы — это ответ на организационные проблемы, это не технический ответ. Я не буду советовать микросервисы никому, кто маленький. Я не буду советовать микросервисы тем, у кого нет проблем с разношерстной технологической базой, кому не нужно писать один сервис на Scala, другой сервис на Python или Haskell. Количество проблем с микросервисами довольно высокое. Этот барьер. Для того, чтобы его преодолеть, нужно довольно много боли испытать перед этим, как сделали это мы.

Одна из самых больших проблем с миркосервисами: микросервисы по своей дефиниции закрывают доступ к системе персистирования данных. Базы спрятаны внутри микросервиса.

Таким образом классический extract transform load process не работает.

Давайте сделаем один шаг назад и вспомним, как работаем в классическом мире. Что у нас есть? У нас есть классический мир, у нас есть developer’ы, junior developer’ы, senior developer’ы, DBA и Business Intelligence.

Как это работает?

В простом случае у нас бизнес логика, база, ETL процесс достаёт прямо из базы наши данные и засовывает в Date Warehouse (DWH).

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

Конечно это всё — не без проблем. Это всё очень трудно автоматизировать. В мире микросервисов у нас всё не так.

Когда мы объявили о микросервисах, когда мы объявили о Radical Agility, когда мы объявили об этих всех прекрасных нововведениях для developer’ов, бизнес-аналитики были очень недовольны.

Как собирать данные из огромного количества микросервисах?

Речь идет не о десятках, а о сотнях или даже тысячах. Потом приходит Валентин на коне и говорит: мы всё будет писать в поток, в queue. Потом архитекторы говорят: почему queue? Кто-то будет использовать Kafka, кто-то будет использовать Rabbit, как мы будет это всё интегрировать? Наши security-officer’ы сказали: никогда в жизни, мы не позволим. Наши бизнес-аналитики сказали: если там не будет схемы, мы повесимся и не сможем понять, что течёт, это же будет просто сточная канава, а не система транспорта данных.

Мы сели и начали совещаться и решать, что же делать. Наши основные цели: простота использования нашей системы, хотим, чтобы у нас не было single point of failure, не было такого монстра, который если он упадёт, то всё упадёт. Должна быть безопасная система, и эта система должна удовлетворять потребностям бизнес-аналитики, система должна удовлетворять наших data-science’ов. Она должна в хорошем случае дать возможность другим сервисам использовать эти данные, которые текут через шину.

Из Event Bus мы сможем вытаскивать Business Intelligence или в какие-то Data heavy services. DDDM это любимое понятие в последнее время. Это data driven decisions making system. Любой менеджер будет в восторге от такого слова. Machine learning and DDDM.

Что мы придумали?

Nakadi. Вы наверно поняли, что у меня фамилия довольно грузинская. Nakadi по-грузински значит поток. Например, горный поток.

Мы начали делать такой поток. Основные принципы, которые мы туда вложили, немножко повторюсь.

Мы сказали, что у нас будет стандартный HTTP API. По возможности — restful. Мы сделаем централизованную или по возможности не очень централизованную event type registry. Мы введём разные классы event types. Например, на данный момент у нас поддерживается два класса. Это data capture и business events. То есть если у нас меняются сущности, то мы можем event capture записывать с всей необходимой метаинформацией. Если у нас просто информация о том, что в бизнес-процессе что-то произошло, то это обычно намного более простой случай, и мы можем писать более простой event. Но всё равно бизнес-аналитики требуют, чтобы у нас была организована структура, которую можно будет автоматически парсить.

Читайте также: Шины мигом в пскове

Имея огромный опыт работы с PostgreSQL и со схемами, мы знаем, что без поддержки версионирования схем ничего не будет работать. То есть если мы скатимся до уровня, где программисты должны будут описывать order created, затем order created 1,2,3, мы будем, по существу, делать систему похожую на Microsoft Windows, и это будет очень трудно, особенно для того чтобы понимать, как развиваться сущность, как версионируется сущность. Очень важно, чтобы этот интерфейс позволял стримить данные, чтобы можно было реагировать как можно быстрее на приход сообщений и оповещать всех желающих о приходе сообщения.

Мы не хотели изобретать велосипед. Наша цель — сделать максимально минимальную систему, которая будет использовать существующие системы. Поэтому на данный момент мы взяли Kafk’у, как underline систему и PostgreSQL для хранения метаданных и схемы.

Nakadi Cluster — это то, что у нас есть. Существует в виде open source проекта. В данный момент он валидирует схему, которую регистрировали до этого. Он умеет записывать дополнительную информацию в метаполя для event’a. Например, время прихода или если клиент не создал уникальные id для event’a, то и уникальные id туда можно запихнуть.

Также мы посчитали, что нужно взять на себя управление offset’ами. Те, кто знает, как работает Kafka. Кто-нибудь знает? Хорошо, но не большинство. Kafka – классическая pub/sub-система, в которой продюсер записывает данные последовательно, а клиент не хранит, как в классических message-системах.

Для клиента не создаются отельные копии message, единственное, что нужно клиенту, — это offset. То есть сдвиг в этом бесконечном потоке. Можете представить, что Kafka — это такой бесконечный поток данных, в котором пронумерована каждая сточка. Если ваш клиент хочет забрать данные, он говорит: читай с позиции X. Kafka даст ему эти данные из позиции X. Таким образом гарантируется упорядоченность данных, таким образом гарантируется что на сервере не надо хранить очень много информации, как обычно делается в классических message-системах, которые позволяют комитить часть прочитанных event’ов. В данной ситуации у нас есть проблема в том нельзя закомитить кусок прочитанного блока. Сейчас пошёл offtext, про Kafk’y не хотел говорить, извините.

High level interface делает чтение из kafk’и очень простым для клиентов. Клиенты не должны обмениваться информацией, кто из какого раздела читает, какие offset’ы они хранят. Просто приходит клиент и получает то, что нужно из системы. Мы решили по пути минимального сопротивления. Zookeeper уже есть для Kafk’и, какой бы ужасный Zookeeper не был, он у нас уже есть, нас уже нужно его manage’ить и мы используем его для хранения offset’ов и дополнительной информации. PostgreSQL — для метаданных и хранения схем.

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

Мы движемся очень быстро. Поэтому, когда я вернусь в Берлин, какие-то части будут уже сделаны.

На данный момент у нас есть Nakadi Cluster, у нас есть Nakadi UI, который мы начали писать на Elm, чтобы заинтересовать других людей. Elm крутой, люблю его.

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

Наш кластер не успевает масштабироваться. Мы хотим, чтобы у нас были разные кластеры по разным типам данных. Стандартизацию интерфейса мы делали специально так, чтобы не было никакой завязки на Kafk’y.

Мы можем переключиться с Kafk’и на Redis. А с Redis’a на Kinesis. По существу, идея такая, что в зависимости от необходимости сервиса и свойств event’ов, которые они пишут, если кому-то не интересен ordering, упорядоченность, то можно использовать систему, которая не поддерживает ordering и более эффективна, чем Kafka. На данный момент у нас есть возможность абстрагировать это, используя наш интерфейс.

Nakadi Scheme Manager нужно вытаскивать из кластера, потому что он должен быть зашерен. Следующий шаг — такая идея, чтобы у нас схемы детектировались. То есть поднимается микросервис, публицирует свой swagger-файл, публицирует список event’ов в том же формате, что и swagger. Автоматически crawker забирает это всё и избавляет developer’ов от необходимости дополнительно перед deployment’ом inject’ить схему в message bus.

Ну и конечно, topology manager, чтобы можно было каким-то образом рутить продюсером и консюмеров на разные кластеры. Тут рассказывали, что Kafka работает как слон. Нет, не как слон, а как паровоз. В нашей ситуации этот паровоз всё время ломается. Не знаю, кто производил этот паровоз, но для того, чтобы управлять Kafk’ой в AWS, оказалось, что это не так просто.

Мы написали систему Bubuku, очень хорошее название, очень русское.

У меня был большой слайд, на котором было указано что делает Bubuku, но он получился очень большим. Всё можно посмотреть по ссылке.

В прицепе Bubuku имеет цели делать то, что не делают другие с Kafk’ой. Основные идеи что это автоматически reportition, автоматический scaling и возможность пережить попадания молнией, crazy monkeys которые убивают инстансы.

Кстати, у нас систему тестирует Chaos Monkey, и очень даже неплохо всё это работает. Всем рекомендую, если вы пишите микросервисы, всегда думайте, как эта система переживает Chaos Monkey. Это — Netflix-система, которая рандомно убивает ноды или отключает сеть, портит вам систему

Какую бы вы систему ни построили, если вы её не тестируете, то она не будет работать, если что-то поломается.

Заключая свой поверхностный рассказ, хочу сказать: то, о чем я рассказывал, сейчас мы разрабатываем в open source. Почему open source? Мы даже написали, почему Zalando делает open source.

Когда люди пишут в open source, они пишут не для компании, а для себя отчасти. Поэтому мы видим, что качество продуктов лучше, мы видим, что изолируемость продуктов от инфраструктуры лучше. Никто не записывает внутрь zalando.de и не правят ключи, не комитят в Git.

У нас есть принципы о том, как open source’ить. Есть ли у вас вопросы в компании должны ли мы open source’ить или нет? Есть принцип open source first. Перед тем как начать проект, мы думаем, стоит ли его open source’ить. Для того что понять и ответить на этот вопрос, нужно ответить на вопросы: