Шина данных в программаторе это что

Шина данных это

Шина данных это система передачи информации в ПК

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

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

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

Компьютерная шина

Компьютерная шина – это электронная магистраль предназначенная для передачи информации между функциональными модулями компьютера. Такими как: центральный процессор, графический адаптер, винчестер, ОЗУ и остальными устройствами. Данная система включает в себя некоторое количество других шин, в частности: шины адреса, шина данных, кстати их может быть несколько, и шина управления.

Основное деление компьютерных шин

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

Одна из самых значимых устройств связи

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

Производительность компьютера

Все основные компьютерные шины в зависимости от предназначения, делятся на несколько категорий:

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

Системные шины в современных компьютерах

Стандартная локальная шина, разработанная ассоциацией VESA, получила компетентное признание в мире компьютерных технологий. Официальное ее название VL-Bus и она же является одной из самых популярных шин локального назначения со дня ее представления. Используя шину VL-Bus можно осуществлять 32-разрядную передачу информации между графическим адаптером и процессором либо винчестером.

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

Компьютерная шина, оперативка, центральный процессор и мосты

Источник

Шины в микропроцессорной системе

В предыдущей главе я рассказывал про цифровую электронику и общее устройство микроконтроллера (МК). А также, что он состоит из процессора, устройств ввода-вывода (УВВ) и устройства памяти. Но я практически ничего не сказал о том, как они общаются между собой. А это весьма важная тема, в которую я и посвящу тебя в этот раз.

Шины и разряды

Как ты уже знаешь, вся информация в цифровой технике стараниями инженеров и математиков представляется в виде двоичных чисел, которые записываются с помощью всего двух цифр: «0» и «1». Обычное десятичное число «3» в двоичной записи будет выглядеть как «11», т.е. 3₁₀ = 11₂. Нижние индексы указывают в какой системе счисления записано число, т.е. 10 – десятичная, а 2 – двоичная. Одна цифра в двоичном числе называется разрядом. У разрядов есть старшинство. Самый правый разряд называется младшим, а самый левый – старшим. Старшинство разряда растет справа налево:

Двоичное число, состоящее из 8 разрядов называется 8-ми разрядным, из 16 – шестнадцатиразрядным и т.д. Разрядность двоичного числа имеет самое прямое отношение к взаимодействию между процессором, памятью и устройствами ввода-вывода.

Дело в том, что в твоем МК бегают такие же двоичные числа. Они ходят от памяти к процессору, от процессора назад к памяти или УВВ, а от последних к процессору. Бегают они естественно по проводам (в МК эти шины спрятаны внутри микросхемы). Каждый провод в определённый момент времени может передавать только один разряд со значением «0» или «1». Поэтому, чтобы передать, к примеру, 8-ми разрядное число от процессора к памяти или назад понадобится минимум 8 таких поводов.

Несколько таких проводов, объединенных вместе называются шиной. Шины бывают нескольких видов: шина адреса, шина данных и шина управления. По шине адреса бегают числа, которые обозначают адрес ячейки памяти или устройства ввода-вывода, откуда ты хочешь получить или куда хочешь записать данные. А сами данные будут передаваться уже по шине данных. Это похоже на почтовую посылку. У посылки есть адрес и есть содержание. Так вот в микропроцессорной системе, каковой МК также является, адрес и данные передаются по разным путям, именуемым шинами.

Сколько проводов должно быть в шине?

Это напрямую зависит от конструкции процессора. Процессор может иметь 32-разрядную шину данных и 16-ти разрядное АЛУ. Такие случаи в истории процессоров и МК встречаются многократно. Поэтому разрядность процессора не определяет 100% разрядность шин данных и шин адреса. Всё зависит от конкретной конструкции.

На что влияет разрядность шины адреса

Самым главным, на что она влияет, является количество адресов, которые можно по ней передавать. Например, в 4-разрядной системе это будет всего 2 4 = 16 адресов, в 64-разрядной числов сдресов будет уже 2 64 =18 446 744 073 709 551 616. Таким образом, чем выше разрядность шины адреса, тем к больше объем памяти и больше устройств ввода-вывода, с которыми может работать процессор. Это важно.

На что влияет разрядность шины данных

Её разрядность определяет сколько данных процессор может считать за один раз. Чем выше разрядность, тем больше данных можно считывать за один раз. Её разрядность, как и разрядность шины адреса целиком определяется конструкцией конкретного процессора или МК. Но при этом всегда кратна восьми. Связано это с тем, что практически во всех устройствах памяти минимальной единицей информации является байт, т.е. двоичное число из 8-ми разрядов.

Зачем было нужно вводить ещё одно название: байт? Оно служит для обозначения количества информации. Если количество разрядов говорит просто о длине двоичного числа, то битность говорит о количестве информации, которую это число несет. Считается, что один разряд двоичного числа может передавать 1 бит информации. При этом биты группируются в байты, килобайты, мегабайты, гигабайты, терабайты и т.д.

Кстати, 1 байт = 8 бит, 1 килобайт = 1024 байтам, 1 мегабайт = 1024 килобайтам и т.д. Почему именно 1024? Все это связано с тем, что размер памяти всегда кратен степени двойки: 2 3 = 8, 2 10 =1024. В свою очередь кратность двойке была выбрана благодаря тому, что она упрощает техническую реализацию устройств памяти. Устройство памяти представляет.

Алгоритм работы микроконтроллера

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

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

RD (read)	сигнал на чтение
WR (write)	сигнал на запись
MREQ (memory request)	запрос обращения к памяти
IORQ (input/output request)	запрос обращения к портам в/в
READY	сигнал готовности
RESET	сигнал сброса

Когда процессору требуется обратиться к памяти он выставляет на шине управления сигнал MREQ, при этом будет выставлен одновременно с ним сигнал RD/WR. Если процессор будет писать в память, то выставляется сигнал WR, если чтение – RD. Тоже самое происходит, если процессор обращается к портам ввода-вывода.

А вот сигнал READY нужен для того, чтобы сообщить процессору, что чтение/запись завершены. Всё довольно просто. Если тебя одолевают вопросы почему несмотря на то, что и память и порты ввода-вывода, через которые подключены внешние устройства, не конфликтуют, то разгадка будет довольно простой. В каждый момент времени процессор обращается только к одному конкретному устройству: либо памяти, либо через порты к портам ввода-вывода. И шина управления обеспечивает правильное разделение доступа.

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

Теперь вырисовывается уточнение к алгоритму работу микроконтроллера, который я описывал в прошлой главе. Когда ты подаёшь питание на МК, то он выставляет сигнал на шине управления MREQ, RD, а на шине адреса адрес, по которому в ячейке памяти программ должна находиться первая команда его программы (чаще всего это нулевой адрес памяти программ). Затем МК её выполнит и в зависимости от этой и последующих команд на шине управления, адреса и данных будут появляться соответствующие сигналы и данные.

Подведу итоги:

Источник

Шины микропроцессорной системы и циклы обмена

Циклы обмена информацией делятся на два основных типа:

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

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

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

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

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

2.1. Шины микропроцессорной системы

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

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

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

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

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

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

Источник

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

Валентин Гогичашвили объясняет микросервисы. Перед вами расшифровка доклада с 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 начал крошиться. Люди начали жаловаться и уходить или просто не приходить.

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

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

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

Они могут выбрать своё собственное технологический стэк. Если команда решила, что они будет писать на 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.

Из 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’ить. Для того что понять и ответить на этот вопрос, нужно ответить на вопросы:

Если вы пойдете на zalando.github.io, там огромное количество проектов на PostgreSQL, очень много библиотек как для бэкенда, так и для фронтенда, очень рекомендую.

У меня кончилось время.

Источник