Наши партнеры

UnixForum





Библиотека сайта rus-linux.net

Riak и Erlang/OTP

Глава 15 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: "Riak and Erlang/OTP", глава из книги "The Architecture of Open Source Applications"
Авторы: Francesco Cesarini, Andy Gross and Justin Sheehy
Перевод: Н.Ромоданов

Creative Commons: Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.

15.7. Заключение и усвоенные уроки

Большинство программистов считают, что чем меньше и проще код, его не только проще поддерживать, но в нем часто также меньше ошибок. Благодаря базовым примитивам языка Erlang, имеющимся в дистрибутиве, разработку Riak стало возможным начинать со считающимся фундаментальным слоя асинхронных сообщений и создавать свои собственные протоколы, не беспокоясь о том, что лежит в основе их реализации. Когда Riak перерос в зрелую систему, в некоторых частях его сетевой коммуникации отказались от использования встроенных средств языка Erlang (и перешли к прямому манипулированию сокетами TCP), а в других - продолжают использовать хорошо подходящие для этих целей встроенные примитивы языка. Начав с использования нативных сообщения языка Erlang, позволяющих передавать любые сообщения, команда разработчиков Riak смогла очень быстро построить всю систему. Эти примитивы достаточно понятны и ясны, так что позже их было просто заменить в нескольких местах, где они не лучшим образом вписались в систему.

Кроме того, благодаря особенностям механизма передачи сообщений Erlang и легковесности ядра виртуальной машины Erlang, пользователь может одинаково легко запустить 12 узлов на 1 машине или 12 узлов на 12 машинах. Это делает существенно упрощает разработку и тестирование в сравнении с более тяжеловесными механизмами передачи сообщений и кластеризации. Это особенно ценно из-за принципиально распределенного характера системы Riak. Исторически известно, что в большинстве распределенных систем очень трудно работать в "режиме разработки" на ноутбуке одного разработчика. В результате, разработчики часто заканчивают тестирование своего кода в среде, которая является лишь частью полной системой и ведет себя не так, как полная система. Поскольку кластер Riak со множеством узлов может абсолютно просто работать на одном ноутбуке без чрезмерного потребления ресурсов или сложных трюков с конфигурацией, в процессе разработки можно достаточно легко создавать код, который будет пригоден для развертывания в промышленных условиях.

Использование супервизоров Erlang/OTP делает Riak гораздо более устойчивым в условиях выхода из строя подкомпонентов. Riak позволяет делать даже больше; благодаря такому поведению, кластер Riak также может достаточно легко поддерживать функционирование даже тогда, когда во всех узлах произошел сбой и они исчезли из системы. Это порой может привести к удивительному уровню устойчивости. Одним из примеров этого был случай, когда крупное предприятие провело стресс-тестирование различных баз данных и умышленное их разрушение с целью выяснить их граничные возможности. Когда они добрались до Riak, у них возникли проблемы. Каждый раз, когда они находили способ (с помощью манипуляций на уровне операционной системы, плохих соединений IPC и т.д.), который должен был разрушить подсистему Riak, они могли наблюдать только очень короткий провал производительности, а затем система возвращалась к нормальному поведению. Это прямой результат вдумчивого подхода «пускай выходит из строя». Riak, когда это требовалось, перезапускал заново каждую из этих подсистем, а система в целом просто продолжала функционировать. Этот опыт показал, какой именно вид устойчивости Erlang/OTP вносит в создаваемые программы.

15.7.1. Благодарности

Эта глава основана на конспекте лекций 2009 года Франческо Чезарини (Francesco Cesarini) и Саймона Томпсона (Simon Thompson) Центрально-европейской школы функционального программирования, которая проводилась в Будапеште и Комарно. Основной вклад внес Саймон Томпсон (Simon Thompson) из Университета Кент в Кентербери, Великобритания. Отдельное спасибо всем рецензентам, которые высказывали свое мнение на различных этапах написания этой главы.


К началу статьи.