В нашем последнем посте мы задавали вопрос, должны ли стартапы на ранних стадиях внедрять архитектуру микросервисов. Сегодня мы пойдем немного дальше, подчеркнув огромный потенциал распределенных систем, которые могут принести начинающим компаниям, и предложим возможный простой путь внедрения нового поколения распределенных систем с использованием некоторых инструментов, которые мы в настоящее время разрабатываем на сайте Nanosai.com. ».
Зачем внедрять распределенные системы?
Пару лет назад казалось, что преимущества распределенных вычислений связаны только с академическими исследованиями. Часто упоминаемый вариант использования - это способность ученых решать сложные научные проблемы в таких областях, как геномика, посредством междисциплинарного / институционального сотрудничества с использованием грид-вычислений, чтобы легко выполнять огромные задачи обработки / анализа данных, на выполнение которых в противном случае потребовались бы месяцы.
Сегодня мы живем в мире, управляемом данными круглосуточно и без выходных, где, по оценкам, в среднем мы генерируем около 2,5 квинтиллионов байт данных в день, причем большая часть этих данных генерируется пользователями популярных сервисов, таких как Google, Facebook, Amazon, Netflix и т. Д. Недавний отчет Cisco также предсказывает следующее:
● К 2020 году объем всех когда-либо снятых фильмов в гигабайтах (ГБ) будет передаваться через глобальный Интернет каждые 2 минуты.
● В глобальном масштабе IP-трафик достигнет 511 терабит в секунду (Тбит / с) в 2020 году, что эквивалентно 142 миллионам человек, одновременно транслирующим видео высокой четкости (HD) в Интернете в течение всего дня, каждый день.
● Глобальный IP-трафик в 2020 году будет эквивалентен 504 миллиардам DVD в год, 42 миллиардам DVD в месяц или 58 миллионам DVD в час.
Создание более умных распределенных систем для обработки такого большого объема данных представляет огромные возможности как для стартапов, так и для потребителей. Например, для стартапов в сфере финансовых услуг это дает им прочную возможность бросить вызов крупным существующим финансовым учреждениям, которые в основном полагаются на централизованные унаследованные технологии, которые не были разработаны для нынешнего стремительного роста возможностей подключения и больших данных. Для потребителей это открывает больший выбор и лучшее качество услуг по более конкурентоспособным ценам, чем у крупных компаний.
Почему протоколы имеют значение?
Хорошая связь является ключом к бесперебойной работе распределенных систем, поскольку узлы должны иметь возможность правильно взаимодействовать друг с другом внутри, а также часто и снаружи, в зависимости от того, требуется ли системе доступ к третьим сторонам или быть открытыми для третьих сторон.
Фундаментальная проблема, с которой сегодня сталкиваются разработчики при построении современных распределенных систем, заключается в том, что в настоящее время нет жизнеспособных стандартных протоколов, которые облегчили бы им реализацию распределенных систем таким же образом, как это делал HTTP для старой сети. Общий подход к тому, как узлы взаимодействуют друг с другом при работе с современными распределенными системами, такими как микросервисы, заключается в использовании синхронных протоколов (например, HTTP / REST) или асинхронных протоколов (например, AMQP). Мы говорим, что HTTP - это синхронный протокол в том смысле, что он работает по шаблону запрос / ответ, то есть клиент выдает запрос и ждет ответа (часто очень долгое ожидание!). С другой стороны, в отличие от подхода HTTP, подход с передачей сообщений (например, AMQP) является асинхронным в том смысле, что в качестве клиента вам не нужно ждать ответа, и, в частности, ответы на сообщения могут быть отправлены обратно в другом порядке, чем они были отправлены.
Чтобы решить проблемы протокола, с которыми сегодня сталкиваются разработчики, в Nanosai мы разрабатываем новое поколение открытых сетевых протоколов, называемых IAP, направленных на обеспечение более широкой применимости, производительности, простоты и интеллекта в современных распределенных системах как части интеллектуальной экосистемы. Мы разработали IAP с нуля со следующими намерениями;
• Быть жизнеспособной заменой / дополнением HTTP, FTP, SNMP, ODBC, RPC и т. Д.
• Для поддержки большего количества потоков сообщений и, следовательно, большего количества вариантов использования, чем HTTP.
• Быть более простым и универсальным, чем HTTP.
• Быть более компактным, чем HTTP.
• Быть намного умнее HTTP
Что такое протокол IAP?
Вкратце, IAP (см. Спецификацию IAP) - это асинхронный протокол, ориентированный на сообщения со свободным потоком. Под свободным потоком мы подразумеваем, что сообщения могут свободно передаваться в обоих направлениях между взаимодействующими узлами. IAP не ограничивается шаблоном связи запрос-ответ HTTP или других протоколов RPC. Быть протоколом, ориентированным на свободный поток сообщений, означает, например, что допустим любой из следующих сценариев:
- A отправляет N сообщений B, а B.
- A отправляет N сообщений B. B отвечает на каждое M сообщений.
- A отправляет 1 сообщение B. B отвечает 1 сообщением.
- A отправляет 1 сообщение B. Be отправляет N сообщений A.
- B отправляет N сообщений в A, а A не отвечает.
Интересной особенностью IAP является то, что его сообщения кодируются с использованием двоичного кодирования, называемого ION. ION напоминает двоичную версию JSON, но более компактен в сети, проще и быстрее читается и записывается, и в нем несколько больше типов данных, чем в JSON. По сути, IO более универсален, его можно использовать для таких вещей, как файлы данных, файлы журналов и сетевые сообщения. Мы расскажем об ION более подробно в следующих статьях.
Другой интересной особенностью IAP является то, что он позволяет разработчикам определять различные семантические протоколы поверх основного формата сообщения. Базовый формат сообщения содержит набор полей, которые почти всегда используются при сетевой коммуникации. Следовательно, семантические протоколы могут расширять этот формат сообщения и добавлять специфические для протокола поля.
В конечном итоге наша цель - сделать IAP жизнеспособной альтернативой HTTP и способной поддерживать более широкий спектр шаблонов обмена сообщениями. Мы считаем, что для создания более универсального интернет-общения нам действительно нужен более универсальный протокол, чем HTTP. Фактически, наш соучредитель и технический директор Якоб Дженков также написал сообщение Почему HTTP2 и WebSockets недостаточно, обосновывая, почему нам нужно отказаться от HTTP.
Наконец, в ближайшие недели и месяцы мы будем делиться с вами нашим путешествием в виде последующих сообщений, например Акт 2, Акт 3… Акт N . А пока, пожалуйста, посетите github.com/nanosai, чтобы проверить наш код и быть в курсе наших достижений.
Автор: Бамборде Бальде, соучредитель Zaiku.
Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.
Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!
