Основные шины компьютера
Компьютер состоит из множества различных компонентов, это центральный процессор, память, жесткий диск, а также огромное количество дополнительных и внешних устройств, таких как экран, мышка клавиатура, подключаемые флешки и так далее. Всем этим должен управлять процессор, передавать и получать данные, отправлять сигналы, изменять состояние.
Что такое шина компьютера
По способу передачи данных шины делятся на последовательные и параллельные. Последовательные шины передают данные по одному проводнику, один бит за один раз, в параллельных шинах передача данных разделена между несколькими проводниками и поэтому можно передать большее количество данных.
Виды системных шин
Все шины компьютера можно разделить за их предназначением на несколько типов. Вот они:
Также к шинам ввода/вывода подключается шина расширений. Именно к этим шинам подключаются такие компоненты компьютера, как сетевая карта, видеокарта, звуковая карта, жесткий диск и другие и их мы более подробно рассмотрим в этой статье.
Вот наиболее распространенные типы шин в компьютере для расширений:
А теперь давайте более подробно разберем все эти шины персональных компьютеров.
Шина ISA
Раньше это был наиболее распространенный тип шины расширения. Он был разработан компанией IBM для использования в компьютере IBM PC-XT. Эта шина имела разрядность 8 бит. Это значит что можно было передавать 8 бит или один байт за один раз. Шина работала с тактовой частотой 4,77 МГц.
Для процессора 80286 на базе IBM PC-AT была сделана модификация конструкции шины, и теперь она могла передавать 16 бит данных за раз. Иногда 16 битную версию шины ISA называют AT.
Шина MCA
Компания IBM разработала эту шину в качестве замены для ISA, для компьютера PS/2, который вышел в 1987 году. Шина получила еще больше усовершенствований по сравнению с ISA. Например, была увеличена частота до 10 МГц, а это привело к увеличению скорости, а также шина могла передавать 16 или 32 бит данных за раз.
Также была добавлена технология Bus Mastering. На плате каждого расширения помещался мини-процессор, эти процессоры контролировали большую часть процессов передачи данных освобождая ресурсы основного процессора.
Одним из преимуществ этой шины было то, что подключаемые устройства имели свое программное обеспечение, а это значит что требовалось минимальное вмешательство пользователя для настройки. Шина MCA уже не поддерживала карты ISA и IBM решила брать деньги от других производителей за использование этой технологии, это сделало ее непопулярной с сейчас она нигде не используется.
Шина EISA
Эта шина была разработана группой производителей в качестве альтернативы для MCA. Шина была приспособлена для передачи данных по 32 битному каналу с возможностью доступа к 4 Гб памяти. Подобно MCA для каждой карты использовался микропроцессор, и была возможность установить драйвера с помощью диска. Но шина все еще работала на частоте 8 МГц для поддержки карт ISA.
Слоты EISA в два раза глубже чем ISA, если вставляется карта ISA, то она использует только верхний ряд разъемов, а EISA использует все разъемы. Карты EISA были дорогими и использовались обычно на серверах.
Шина VESA
Шина VESA была разработана для стандартизации способов передачи видеосигнала и решить проблему попыток каждого производителя придумать свою шину.
Шина VESA имеет 32 битный канал передачи данных и может работать на частоте 25 и 33 МГц. Она работала на той же тактовой частоте, что и центральный процессор. Но это стало проблемой, частота процессора увеличивается и должна была расти скорость видеокарт, а чем быстрее периферийные устройства, тем они дороже. Из-за этой проблемы шина VESA со временем была заменена на PCI.
Слоты VESA имели дополнительные наборы разъемов, а поэтому сами карты были крупными. Тем не менее сохранялась совместимость с ISA.
Шина PCI
В PCI можно использовать технологию Plug and Play (PnP). Все карты PCI поддерживают PnP. Это значит, что пользователь может подключить новую карту, включить компьютер и она будет автоматически распознана и настроена.
Также тут поддерживается управление шиной, есть некоторые возможности обработки данных, поэтому процессор тратит меньше времени на их обработку. Большинство PCI карт работают на напряжении 5 Вольт, но есть карты, которым нужно 3 Вольта.
Шина AGP
Необходимость передачи видео высокого качества с большой скоростью привела к разработке AGP. Accelerated Graphics Port (AGP) подключается к процессору и работает со скоростью шины процессора. Это значит, что видеосигналы будут намного быстрее передаваться на видеокарту для обработки.
PCI-Express
Это модифицированная версия стандарта PCI, которая вышла в 2002 году. Особенность этой шины в том что вместо параллельного подключения всех устройств к шине используется подключение точка-точка, между двумя устройствами. Таких подключений может быть до 16.
Это дает максимальную скорость передачи данных. Также новый стандарт поддерживает горячую замену устройств во время работы компьютера.
PC Card
Шина Personal Computer Memory Card Industry Association (PCICIA) была создана для стандартизации шин передачи данных в портативных компьютерах.
Шина SCSI
Шина SCSI была разработана М. Шугартом и стандартизирована в 1986 году. Эта шина используется для подключения различных устройств для хранения данных, таких как жесткие диски, DVD приводы и так далее, а также принтеры и сканеры. Целью этого стандарта было обеспечить единый интерфейс для управления всеми запоминающими устройствами на максимальной скорости.
Шина USB
Это стандарт внешней шины, который поддерживает скорость передачи данных до 12 Мбит/сек. Один порт USB (Universal Serial Bus) позволяет подключить до 127 периферийных устройств, таких как мыши, модемы, клавиатуры, и другие устройства USB. Также поддерживается горячее удаление и вставка оборудования. На данный момент существуют такие внешние шины компьютера USB, это USB 1.0, USB 2.0, USB 3.0, USB 3.1 и USB Type-C.
USB 1.0 был выпущен в 1996 году и поддерживал скорость передачи данных до 1,5 Мбит/сек. Стандарт USB 1.1 уже поддерживал скорость 12 Мбит/сек для таких устройств, как жесткие диски.
USB 3.0 появился в 2008 году и поднял стандарт скорости еще выше, теперь данные могут передаваться со скоростью 5 Гбит/сек. Также было увеличено количество устройств, которые можно питать от одного порта. USB 3.1 был выпущен в 2013 и тут уже поддерживалась скорость до 10 Гбит/с. Также для этой версии был разработан компактный разъем Type-C, к которому коннектор может подключаться любой стороной.
Выводы
В этой статье мы рассмотрели основные шины компьютера, историю их развития, назначение шин компьютера, их типы и виды. Надеюсь эта статья была для вас полезной и вы узнали много нового.
На завершение небольшое видео про шины и интерфейсы компьютера:
Спецификация API BUS шина
Техническая спецификация работы API. Данная документация определяет принципы, по которым работает API протокол. Эта спецификация общая для Облачных Операционных Систем и для Облачных Интеграторов.
Определения
JWT – JSON Web Token это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на JSON формате. Как правило, используется для передачи данных авторизации в клиент-серверных приложениях.
Frontend – то, что выполняется в браузере клиента, отвечает за динамический HTML.
Backend – обеспечивает обработку API запросов от Frontend’a и выдачи ответа на запрос, обычно работает на стороне сервера, либо в фоне веб приложения.
Bus – универсальная шина обмена данными и событиями между разными узлами системы
BusProvider – транспорт шины, который обеспечивает обмен сообщениями
SystemBus – внутренняя шина системы между ее элементами или микросервисами.
ExternalBus – внешняя шина, взаимодействия между Backend и Frontend.
Работа шины
Принцип работы шины в следующем. Существуют приложения, облачное ПО и микросервисы. Все они должны обмениваться данными. Обмен данными происходит через брокера сообщений, либо напрямую через TCP или HTTP. Облачная система сама определяет, как она будет осуществлять обмен сообщениями.
Каждое приложение должно обладать уникальным app_name. По этому ID будут отправляться сообщения в это приложение.
Внешний gateway может проверить авторизацию или в какой конкретно экземпляр app_name нужно отправить запрос. Например, существует тестовый экземпляр для отладки. Для него создается отдельный тестовый space_id и все запросы с этим space передаются в экземпляр для отладки. space_id нужен также для того, чтобы иметь возможность запускать разные версии приложений. Один и тот же пользователь может обладать доступом к разным пространствам.
В шину можно посылать разные типы запросов: уведомления о событиях, очереди на обработку данных, RPC вызовы, потоки данных загрузки файла или медиа стримы.
Вызов происходит, направляя соответсвующий запрос к объекту. У вызова есть 3 параметра:
Схема работы
Backend может состоять из нескольких микросервисов. Микросервисы связаны между собой через общую системную BUS шину. Посылая запросы, сообщения и события в шину, можно обащаться с другими микросервисами системы. К микросервисам могут быть отнесено Облачное ПО, которое является частью общей интранет системы.
Аутентификация в системной шине происходит через rabbitmq, grpc и т.п.
К системной шине подключается Bus Gateway. Это API шлюз доступа к системе. API шлюз это фаервол. Он проверяет правильность входного пакета, авторизацию пользователя, сессии и в зависимости от результата отклоняет запрос или передает его в шину. API шлюз может также кэшировать некоторые API запросы, если в этом есть необходимость. Также шлюз может отвечать за раздачу статических файлов. Шлюзов в системе может быть несколько. Они могут обеспечивать балансировку нагрузку системы. Шлюзом может быть Nginx, написанный на OpenResty. С Bus Gateway общаются внешние компоненты: фронтенд пользователя, IoT устройства, внешние облачные системы.
Также системные запросы могут обрабатываться через шлюз Bus Gateway, но тогда должна:
Чтобы подключить две системы друг к другу более тесно, лучше использовать Bus Connector.
Примеры HTTP запросов к шлюзу Bus Gateway
Точка входа запроса для внешней шины:
Точка входа запроса для системной шины:
Подключение двух шин друг к другу
Возможно подключение двух системных или нескольких шин друг к другу. Чтобы это сделать, нужно использовать BUS Connector. В коннекторе требуется указать адреса подключаемых шин. Коннектор сканирует шины на наличие приложений. Приложения в двух шинах должны быть уникальны. После сканирования Коннетор начинает слушать сообщения в двух шинах. И если там возникает сообщения для приложения из другой шины, то он перенаправляет запрос в другую шину и возвращает ответ. Bus Connector требует наличия постоянного соединения к шинам.
Формат запроса и ответа
Запрос
Ответ
Шины Данных (Enterprise Service Bus, ESB)
Почему компании делают выбор в пользу Шины Данных
По мере развития любой компании появляются новые бизнес-процессы, требующие автоматизации, усложняются схемы взаимодействия IT-систем. Таким образом, по прошествии нескольких лет многие IT-директора сталкиваются с проблемой: в состав используемого ПО входит целый набор «проверенных временем» систем, но при этом взаимодействие между ними реализовано лишь частично, плохо структурировано, не подчинено единому стандарту, а необходимость создания новой интеграции IT-систем почти всегда требует использования собственных разработок или приобретения еще одного дорогостоящего программного продукта.
Кроме того, нередко, ввиду отсутствия обратной совместимости, перевод какой-либо системы на новую версию влечет за собой необходимость модификации ПО, реализующего связь с другими подсистемами. Все это неизбежно находит отражение в возрастающем объеме инвестиций в IT-блок организации, т.к. для покрытия требований бизнеса необходимо внедрение новых IT-систем и, как следствие, поиск и обучение дорогостоящих технических специалистов.
В начале 2000 годов на рынке программного обеспечения стали появляться решения, сформировавшие кластер под названием Сервисная шина масштаба предприятия (Enterprise Service Bus, ESB), или сокращенно Шина Данных. Шина Данных – это, в первую очередь, концепция, элемент архитектуры IT-ландшафта, используемый для решения задачи интеграции разрозненных информационных систем в единый программный комплекс с централизованным управлением передачей информации и применением сервис-ориентированного подхода.
Enterprise Service Bus (ESB)
Архитектура ESB строится на 3 компонентах:
Коннекторы используются для подключения к различным системам и обеспечивают прием и отправку данных.
Очередь сообщений (Message Queue, MQ) служит для организации промежуточного хранения сообщений в ходе их доставки.
Платформа обеспечивает связь коннекторов с очередью, а также организацию асинхронной передачи информации между источниками и приемниками с гарантированной доставкой сообщений и возможностью трансформации. В состав платформы входит средство разработки, позволяющее не только задать правила маршрутизации, но также, при необходимости, определить собственные коннекторы, в т.ч. с использованием внешних процедур, реализованных на языках Java, C, C++, C#, Python и др.
К основным преимуществам современных ESB-решений относятся:
Пример действующего решения
К настоящему времени на рынке представлено более двух десятков шин данных, однако наибольшее распространение получили следующие решения:
По результатам проведенного анализа различных Шин Данных нашей компанией был сделан выбор в пользу программного продукта JBoss Fuse. В число критериев входили такие вопросы как: наличие широкого спектра адаптеров (включая работу с web-сервисами), возможности маршрутизации и трансформации сообщений, оркестровка, поддерживаемые протоколы обмена, удобство администрирования, стоимость приобретения и поддержки. Данное решение по своим функциональным характеристикам не уступает аналогам от IBM, Oracle и Microsoft, но при этом доступно для бесплатного использования (лицензия приобретается только на поддержку).
На рисунке показан пример реализации web-сервиса, который по запрошенному идентификатору выдает из базы данных информацию о клиенте. Задача решена в инструменте редактирования JBoss Fuse, входящем в состав Jboss Fuse ESB.
Заключение
Внедрение Шины Данных в IT-ландшафт организации позволяет не только структурировать, привести к единому стандарту и упростить поддержку процедур обмена информацией между системами, но также снизить временные затраты на интеграцию новых подсистем и, как следствие, сократить стоимость поддержки и развития всей IT-инфраструктуры компании.
События, шины и интеграция данных в непростом мире микросервисов
Валентин Гогичашвили объясняет микросервисы. Перед вами расшифровка доклада с 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’ить. Для того что понять и ответить на этот вопрос, нужно ответить на вопросы: