Шина данных в рисунках (3 видео)

Содержание

Глава 1. Компьютер. Программное и аппаратное обеспечение
Магистраль: шина данных шина адреса и шина управления. Шины периферийных устройств
Магистраль
Шина данных
Шина адреса
Шина управления
События, шины и интеграция данных в непростом мире микросервисов
Что мы сделали?
Что это значит?
Как это работает?
Что мы придумали?
🎥 Видео

Видео:Как работает LIN шина автомобиля. K-Line L-Line шины данных. Лин шина автомобиля. Lin-bus networkСкачать

Глава 1. Компьютер. Программное и аппаратное обеспечение

Магистраль: шина данных шина адреса и шина управления. Шины периферийных устройств

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

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

Северный мост обеспечивает обмен информацией между процессором и оперативной памятью по системной шине. В процессоре используется внутреннее умножение частоты, поэтому частота процессора в несколько раз больше, чем частота системной шины. В современных компьютерах частота процессора может превышать частоту системной шины в 10 раз (например, частота процессора 1 ГГц, а частота шины — 100 МГц).

К северному мосту подключается шина PCI ( Peripherial Component Interconnect bus — шина взаимодействия периферийных устройств), которая обеспечивает обмен информацией с контроллерами периферийных устройств. Частота контроллеров меньше частоты системной шины, например, если частота системной шины составляет 100 МГц, то частота шины PCI обычно в три раза меньше — 33 МГц. Контроллеры периферийных устройств (звуковая плата, сетевая плата, SCSI -контроллер, внутренний модем) устанавливаются в слоты расширения системной платы.

По мере увеличения разрешающей способности монитора и глубины цвета требования к быстродействию шины, связывающей видеоплату с процессором и оперативной памятью, возрастают. В настоящее время для подключения видеоплаты обычно используется специальная шина AGP ( Accelerated Graphic Port — ускоренный графический порт), соединенная с северным мостом и имеющая частоту, в несколько раз большую, чем шина PCI .

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

Устройства хранения информации (жесткие диски, CD — ROM , DVD — ROM ) подключаются к южному мосту по шине UDMA ( Ultra Direct Memory Access — прямое подключение к памяти).

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

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

Для подключения сканеров и цифровых камер обычно используется порт USB ( Universal Serial Bus — универсальная последовательная шина), который обеспечивает высокоскоростное подключение к компьютеру сразу нескольких периферийных устройств.

Клавиатура подключается обычно с помощью порта PS/2 или USB .

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

Рассмотрим структуру магистрали (системной шины), т.к. модульная организация системы опирается на магистральный (шинный) принцип обмена информации.

Магистраль

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

Системная магистраль осуществляет обмен данными между процессором или ОЗУ с одной стороны и контроллерами внешних устройств компьютера с другой стороны.

Обмен информацией между отдельными устройствами ЭВМ производится по трем многоразрядным шинам, соединяющим все модули, —

Шины представляют собой многопроводные линии. Тип системных шин, применяемых в компьютерах с невысокой производительностью — ISA. Это дешевая но «малоинтеллектуальная» шина. Она может обеспечивать обмен с клавиатурой, дисплеем (алфавитно-цифровым), дисководами для гибких дискет, принтерами и модемами. Однако ее возможностей не достаточно для работы с дисководами для жестких дисков, видеоконтроллерами, адаптерами локальных сетей и т.п.

Шина MCA — более производительная, но не совместима с ISA, поэтому не нашла широкого применения.

Шина EISA — совместима с ISA , значительно дороже, чем ISA и не всегда обеспечивая нужную скорость обмена.

Шина VESA (VL) — более дешевая шина, используется в сочетании с ISA или с EISA.

Шина PCI — конкурент шины VESA , используется в PENTIUM в сочетании с ISA или EISA.

Рис 2. Магистрально-модульный принцип

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

Шина данных

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

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

За 25 лет, со времени создания первого персонального компьютера (1975г.), разрядность шины данных увеличилась с 8 до 64 бит.

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

Шина адреса

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

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

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

N =2 I , где I — разрядность шины адреса.

Каждой шине соответствует свое адресное пространство, т. е. максимальный объем адресуемой памяти:

Разрядность шины адреса постоянно увеличивалась и в современных персональных компьютерах составляет 32 бит. Таким образом, максимально возможное количество адресуемых ячеек памяти равно:

N == 2 32 = 4 294 967 296 = 4 Гб

В персональных компьютерах величина адресного пространства процессора и величина фактически установленной оперативной памяти практически всегда различаются. Несмотря на то, что общий объем адресуемой памяти достигает 4 Гбайт, величина фактически установленной оперативной памяти может быть значительно меньше — 32 Мбайта.

Читайте также: Где посмотреть дату изготовления шины континенталь

Аппаратно на системных платах реализуются шины различных типов. В компьютерах РС/286 использовалась шина ISA (Industry Standard Architecture), имевшая 16-разрядную шину данных и 24-разрядную шину адреса. В компьютерах РС/386 и РС/486 используется шина EISA (Extended Industry Standard Architecture), имеющая 32-разрядные шины данных и адреса. В компьютерах PC/ Pentium используется шина PCI (Peripheral Component Interconnect), имеющая 64-разрядную шину данных и 32-разрядную шину адреса.

Шина управления

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

Рассмотрим в качестве примера, как процессор читает содержимое ячейки памяти (см. таблицу). Убедившись, что шина в данный момент свободна, процессор помещает на шину адреса требуемый адрес и устанавливает необходимую служебную информацию (операция – чтение, устройство – ОЗУ и т.п.) на шину управления. Теперь ему остается только ожидать ответа от ОЗУ. Последний, “увидев” на шине обращенный к нему запрос на чтение информации, извлекает содержимое необходимой ячейки и помещает его на шину данных. Разумеется, реальный процесс значительно подробнее.

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

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

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

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

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

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

Видео:СПРОСИ ЭКСПЕРТА: Выпуск 1. Чем отличается шина данных от ETL?Скачать

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

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

Читайте также: Шины авиационные 880 230 модель 31а

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

Видео:Как на шины наносится рисунок протектора #shortsСкачать

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

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

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

Читайте также: Какую разрядность шины адреса имеет интерфейс isa стандарта xt

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