Распределённые системы

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

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

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

Но теперь мы спим лучше. Мы научились распознавать сценарии системного апокалипсиса и обрабатывать их. Ниже расскажу, как мы обеспечиваем стабильность системы.

Привет, Хаброжители!

Мы решили поделиться переводом главы «Системы на основе очередей задач» Из готовящейся к выходу новинки «Распределенные системы. Паттерны проектирования» (уже в типографии).

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

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

Хорошо известно, что Ethereum, самая популярная dApps платформа, обрабатывает меньше чем 20 транзакций в секунду. Из-за этого ограничения цена транзакций и время на их подтверждение очень высоки: несмотря на то, что блок в Ethereum публикуется раз в 10-12 секунд, согласно ETH Gas Station время между отправкой транзакции и тем как она действительно попадает в блок в среднем 1.2 минуты. Низкая пропускная способность, высокие цены и долгое подтверждение транзакций не позволяет запускать на Ethereum какие-либо высокопроизводительные сервисы.

Основная причина того, что Ethereum не может обрабатывать больше 20 транзакций в секунду заключается в том, что каждая нода в Ethereum должна проверить каждую транзакцию. За пять лет с выхода Ethereum было предложено много идей как решить эту проблему. Эти решения можно грубо разбить на две группы: те, которые предлагают делегировать выполнение транзакций небольшой группе нод с очень хорошим железом, и те, которые предлагают каждой ноде обрабатывать только подмножество всех транзакций. Пример первого подхода — это Thunder, в котором блоки создаются только одной нодой, что позволяет, по утверждениям разработчиков, получать 1200 транзакций в секунду, что в 100 раз больше чем у Ethereum. Другие примеры из первой категории — это Algorand, SpaceMesh, Solana. Все эти протоколы улучшают разные аспекты протокола и позволяют выполнять больше транзакций чем в Ethereum, но все ограничены скоростью одной (пусть и очень мощной) машины.

Несколько слов о том, чем мы занимаемся. DINS участвует в разработке и поддержке UCaaS сервиса на международном рынке для корпоративных клиентов. Сервис используют как малые компании и стартапы, так и большой бизнес. Клиенты подключаются через интернет по SIP протоколу поверх TCP, TLS или WSS. Это создает довольно большую нагрузку: почти 1,5 миллиона соединений от оконечных устройств — телефонных аппаратов Polycom/Cisco/Yealink и софт-клиентов для PC/Mac/IOS/Android.

В статье я рассказываю о том, как устроены VoIP точки входа в систему.

На фотографии: к.ф.-м.н. Николай Дуров, автор протокола шифрования MTProto, ряда ключевых подсистем «ВКонтакте» и блокчейн-платформы TON

Telegram в течение месяца покажет инвесторам блокчейн-платформу TON (Telegram Open Network) для криптовалюты Gram. Несколько источников издания The Bell и газеты «Ведомости» подтвердили, что встреча состоится в Дубае, хотя точная дата ещё не назначена. Запуск основной сети запланирован на март.

О плане разработать блокчейн-платформу с собственной криптовалютой Павел Дуров объявил в январе 2018 года. TON должен решить ключевую проблему современных криптовалют — низкую производительность, что мешает полноценно заменить глобальные платёжные системы. Если Visa и Mastercard обрабатывают около 50-60 тыс. операций в секунду, то Bitcoin и Etherium — всего 7 и 15 операций в секунду, соответственно.

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

Я описывал ранее типичное кодинг-интервью. Помимо кодинга почти всегда есть вопрос на проектирование систем. (Large) System Design. В случае собеседований на SRE, это еще более интересный (как по мне) зверь — NALSD. Non-abstract large system design. Главное отличие между SWE и SRE именно в этих буковках “NA”.

В чем же отличие, и как подготовиться к нему? Давайте разберём на примере. В качестве примера возьмём что-то весьма материальное, что-то такое, что точно никто никогда не спросит на реальном собеседовании (в гугл) :)

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

Привет, Хабр!

На этой неделе мы ожидаем из типографии новую книгу по Spring 5:


Среди интересных возможностей Spring 5 отдельного упоминания заслуживает реактивное программирование, о реализации которого в этом фреймворке кратко рассказывает предлагаемая статья Мэтта Рэйбла (Matt Raible). В вышеупомянутой книге реактивные паттерны рассмотрены в главе 11.

Соавтором Мэтта выступил Джош Лонг, автор еще одной отличной книги про Java и Spring, "Java в облаке", вышедшей у нас прошлым летом.

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

Первый сервис в Nomad я запустил в сентябре 2016 года. На данный момент пользуюсь как программист и занимаюсь поддержкой как администратор двух Nomad кластеров — один "домашний" для своих личных проектов (6 микро-виртуалок в Hetzner Cloud и ArubaCloud в 5 разных датацентрах Европы) и второй рабочий (порядка 40 приватных виртуальных и физических серверов в двух датацентрах).

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

Ямальский кочевник делает Continous Delivery инстанса вашего ПО © National Geographic Россия