Рубрика «distributed systems»

WG Contract API: zoo of services - 1

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

Если хотите познакомиться поближе с тем как команда Wargaming Platform справляется со сложностью системы из более чем сотни взаимодействующих друг с другом web-сервисов, то добро пожаловать под кат.
Читать полностью »

В прошлой статье мы рассматривали ограничения и препятствия, которые возникают, когда нужно горизонтально масштабировать данные и иметь гарантию ACID-свойств транзакций. В этой статье рассказываем о технологии FoundationDB и разбираемся, как она помогает преодолеть эти ограничения при разработке mission-critical приложений.

FoundationDB — это распределенная NoSQL база данных с ACID-транзакциями уровня Serializable, хранящая отсортированные пары ключ-значение (ordered key-value store). Ключами и значениями могут быть произвольные последовательности байт. У неё нет единой точки падения — все машины кластера равноправны. Она сама распределяет данные по серверам кластера и  масштабируется на лету: когда в кластер нужно добавить ресурсов, ты просто добавляешь адрес новой машины на конфигурационных серверах и база сама подхватывает ее. Читать полностью »

Результат пошуку зображень за запитом "голубиная почта"

Небольшой вопрос/ответ:

Для кого это? Людям, которые мало или вообще не сталкивались с распределенными системами, и которым интересно увидеть как они могут строится, какие существуют паттерны и решения.

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

Постановка задачи

Как сделать чат? Это должно быть тривиальной задачей, наверное каждый второй бекендер пилил свой собственный, так же как игровые разработчики делают свои тетрисы/змейки и т. п. Я взялся за такой, но чтоб было интереснее он должен быть готов к захвату мира, чтоб мог выдерживать сотниллиарды активных пользователей и вообще был неимоверно крут. Из этого исходит ясная потребность в распределенной архитектуре, потому что вместить все воображаемое количество клиентов на одной машине — пока нереально с нынешними мощностями. Заместо того чтоб просто сидеть и ждать на появление квантовых компьютеров я решительно взялся за изучение темы распределенных систем.

Стоит отметить что быстрый отклик очень важен, пресловутый realtime, ведь это же чат! а не доставка почты голубями.

%рандомная шутка про почту россии%

Использовать будем Node.JS, он идеален для прототипирования. Для сокетов возьмем Socket.IO. Писать на TypeScript.

И так, что вообще мы хотим:

  1. Чтоб пользователи могли слать друг-другу сообщения
  2. Знать кто онлайн/оффлайн

Как мы это хотим:

Читать полностью »

Проверки работоспособности и постепенная деградация распределенных систем - 1

Как всегда, спасибо Фреду Хеберту и Саргуну Дхиллону за то, что прочли черновик этой статьи и предложили нескольких бесценных советов.

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

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

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

Читать полностью »

Привет всем!

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

Присматриваемся к инструментам для мониторинга распределенных приложений - 1

Когда приложение было монолитным и вдруг, раз, стало распределённым, в формулу вычисления доступности добавляется ещё одна неизвестная — сетевая. Из-за проблем с вызовами между компонентами, приложения часто валятся и начинают дрыгать ножками. А выяснение причин нестабильной работы распределённого приложения — та ещё задачка. Дополнительную неразбериху в структуру приложения вносит условный kubernetes, который по своему внутреннему усмотрению может произвольно распределять условные поды по условным нодам. Пишу «условный», потому что на месте kubernetes может быть и Swarm и Openshift и прочие и прочие.

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

15 сентября в офисе Авито состоится встреча, посвященная масштабированию приложений на PostgreSQL. Поговорим об алгоритмах и нюансах реализации транзакционности в языках программирования, построении бизнес-транзакций в сервисах с паттерном database per service, как устроена OZO — асинхронная типобезопасная header-only библиотека-клиент PostgreSQL для C++17, и уровнях изоляции транзакций PostgreSQL. С докладами выступят Стас Кельвич (Postgres Professional), Сергей Хандриков (Яндекс), Константин Евтеев (Авито) и Михаил Тюрин. Регистрируйтесь на встречу и приглашайте коллег. Под катом — тезисы выступлений докладчиков, ссылка на регистрацию и информация по трансляции митапа.

image

Читать полностью »

Привет! Меня зовут Константин Евтеев, я работаю в Авито руководителем юнита DBA. Наша команда развивает системы хранения данных Авито, помогает в выборе или выдаче баз данных и сопутствующей инфраструктуры, поддерживает Service Level Objective для серверов баз данных, а еще мы отвечаем за эффективность использования ресурсов и мониторинг, консультируем по проектированию, а возможно и разрабатываем микросервисы, сильно завязанные на системы хранения, или сервисы для развития платформы в контексте хранилищ.

Я хочу рассказать, как мы решили один из вызовов микросервисной архитектуры — проведение бизнес-транзакций в инфраструктуре сервисов, построенных с помощью паттерна Database per service. С докладом на эту тему я выступал на конференции Highload++ Siberia 2018.

imageЧитать полностью »

12 марта 2018 г., спустя 4 месяца после прошлой версии, вышел Apache Ignite 2.4. Этот релиз примечателен целым рядом нововведений: поддержка Java 9, множественные оптимизации и улучшения SQL, поддержка платформой нейронных сетей, новый подход к построению топологии при работе с диском и многое другое.

Apache Ignite Database and Caching Platform — это платформа для распределенного хранения данных (оптимизированная под активное использование RAM), а также для распределенных вычислений в близком к реальному времени.

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

Примеры использования: быстрый распределенный кеш; слой, агрегирующий данные из разрозненных сервисов (например, для Customer 360 View); основное горизонтально масштабируемое хранилище (NoSQL или SQL) оперативных данных; платформа для вычислений и т.д.

Далее рассмотрим основные новшества Ignite 2.4.
Читать полностью »

В прошлой статье мы с вами подробно разобрали работу платежных каналов, а также несколько различных методов по обеспечению безопасности платежей, проходящих через них, однако этого все еще недостаточно для построения рабочей сети каналов: даже если мы уверены в том, что внутри каждого канала все играют честно, мы не можем гарантировать доставку средств по цепочке через ряд каналов. И здесь нам на помощь приходят смарт-контракты, называемые HTLC (hash-time-lock-contracts). В этой статье мы разберем принцип их работы, и, наконец, на примере продемонстрируем как проходит платеж в сети Lightning network.

Lightning network

Читать полностью »