Switch lang: Русский \ English

Начальная точка - с чего всё начиналось

Я работал в области ИТ уже лет пять и мысли копились... Мне казлось: "программисты вроде работают в top областях, а все еще как в каменном веке...". Например мы постоянно разбираем json, я как-то поймал себя на мысли, что опять это делаю, но уже на другом языке... Опять... как же это начало надоедать, эта спираль...

Кусочки копились и сложились в мозаику в середине 2013 года. Весной 2013 я уволился из ТЕНЗОРА с [хорошей должности, многое тогда крутилось в моей голове.

Система Акапелла тогда не имела названия и её не существовало в сегодняшнем виде.

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

Эволюция (этапы) идеи платформы

Первый этап - интеграционный язык, как это банально

Сначала хотелось сделать интеграционный язык - не декларативное описание связей, а именно язык программирования. Чтобы интегрировать разные языки..., нет плохо сказал. Я искал решение. Интегрировать разные части системы - некий фреймворк, соединенный middleware. Это было что-то типа IDL для описания данных и транслятора для его обработки (типа специального препроцессора).

Пыри этом хотел решить проблему множества неявных связей на серверной стороне систем. - формализовать знания о взаимосвязях в крупных системах.

второй этап. - забота о разработчиках

Задумывался, о том как лучше разрабатывать, о "алиасах" для разработчиков и условиях командной работы в облаке. Думал о коллективной отладке, о нахождении "дебажных" кусков кода на машине разработчика, чтобы разработчику было комфортно работать и отлаживать код на своей машине, работая при этом в целиковой системе, а не разворачивать локально целое облако (или сервис) целиком для целей разработки.

Так появилась идея конфигураций для системы вместо самого кода на уровне отдельных функций. и захотелось подменять полностью контекст исполнения одного и того же кода (production, test, devel)

третий этап. - почти "idl"

Cчиталась почти полноценной идея о том, что описание объектов происходит на неком языке (типа IDL), а методы пишутся на другом. Система распределяет работу по тем местам, где находятся методы, при этом информация о классах и типах используется системой для аутентификации, авторизации и билинга. система по отношению к написанному коду является фреймворком, эта идея в дальнейшем с изменениями будет предложена как основная.

На самом же деле мне хотелось не просто работать с объектом на разных языках а делать это в единой среде - единой VM. Это скорее вопрос VM, а не вопрос доступа к методам и данным.

четвертый этап. - Заменяем код на "конфигурации". Решил параллелить выполнение.

Идея о замене кода (списка действий и операций над данными) конфигурациями и зависимостями между элементами программы оказалась способна хорошо параллелиться.

Я начал думать о том, а как распараллеливать код программы, а именно:

Как записать распараллеленный код ? В каком виде удобнее всего описывать такие программы ?

Для этого нужны механизмы получения модели выполнения кода с высокой степенью конкурентности. В мире используются для этого:

  • потоки, + объекты синхронизации
  • потоки и процессы + каналы
  • деферреды
  • продолжения
  • yield основы построения групповых продолжений
  • есть процесс-ориентированные подходы (CSP),
  • MQ решения
  • существуют событийные модели

Для работы с событийными моделями есть разные алгоритмы на уровне ОС тоже. Таким же образом строится работа на уровне ОС с вводом выводом... Задача обретала черты ОС и архитектуры систем обработки данных.

Было придумано некое распределенное событийное ядро, но все упиралось в:

  • модель работы с данными
  • в техники получения доступа (локального и удаленного)
  • сказывались врожденные недостатки событийной модели и dataflow, такие как непродуктивная работа с памятью
  • недостатки стековой модели для множества потоков
  • отсутствие кактус стека в типовых языках программирования...

Я бодро работал с клубком проблем которые никто не решал единовременно очень-очень долгие годы...

пятый этап - шаг в сторону, работа с данными. БД сделал, но оставил это.

Занялся работой по проектированию систем хранения данных. Систем индексирования данных. Рассмотрел все типы хранилищ под “микроскопом”. Придумывал такую систему управления данными, чтобы она была максимально эффективна. Занимался красно-черными деревьями, бинарными кучами, B-Tree, особое внимание уделил R-Tree и M-Tree деревьям и даже чтобы лучше понимать написал их реализацию, это у меня был многомерный индекс, который позволял индексировать элементы объекта сразу по всем полям искать сразу по всем полям. (опишу полученные знания позже в блоге)

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

Были сделаны выводы и внимание обращено на распределение данных партиционирование и прочее.

Практически сам я пришел к СAP теореме. И потом узнал о ней и прочитал доказательство сделанное MIT. Думал над этой темой и думал, как сделать так, чтобы для наших клиентов этой проблемы избежать. Кое что, как водится, придумал, но вопросы оставались.

шестой этап - делаем свою cloud vm

У меня уже было понимание, как получать взаимозависимости между кусками кода.

Было полное понимание, как работают внутри различные БД и как работают распределенные бд и как лучше всего их использовать для работы с данными в требуемой системе (типовые элементы, рабочие звенья, функциональные части).

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

Я долго думал над этим. - примерно 4 месяца эскизов. А решение было на поверхности и я его отчасти уже видел в других придумках из смежных областей.

Я придумал некую стыковку одной (старой) идеи, примененной на переупоряочивающем этапе конвейера суперскалярной части современных ядер процессоров и развитого транзакционного механизма системы управления базами данных, чтобы реализовать это в виде ядра VM.

Пришло понимание вот чего: как

Можно модифицировать транзакционный механизм БД (надстроив его определенным образом) и как вместе с этим построить процесс исполнения кода в системе, чтобы эти два механизма в симбиозе решали задачу автоматического распараллеливания даже того кода, который на предмет этой задачи специально не анализировался.

Это позволяло завершить недостающее звено в системе.

Части работы:

  • первая: проанализировать код и построить граф управления с максимальной степенью конкурентности.
  • вторая: построить этот граф на этапе одновременного исполнения всех частей, вычислив зависимости по данным между блоками кода на ходу (в рантайме).

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

Свойство самоорганизации - адаптации к ситуации начинает проявляться не только в построении схемы распределения ресурсов для хранения (БД принципы), не только в построении системы управления вычислительными ресурсами (принцип суперскалярности), а еще и в построении и адаптации к новым наборам данных графа запуска плана выполнения для максимальной степени параллелизма с целью уменьшения числа перезапусков при транзакционных конфликтах (оптимизация их числа - сведение числа конфликтов к нулю).

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

послесловие : дополнение к шестому этапу

Все хорошо в этой концепции, но она сильно отличается от того что сейчас имеется : SOA.

Как стыковать мою систему с множеством готовых сервисов и всякого другого кода у которого есть побочные эффекты?

Понимание пришло когда я пытался сделать это для Acapella-GUI подсистемы, подключая ее через REST.

Каждый REST сервис предоставляет плоский сетевой API к некой модели данных. Это именно модель данных, а не что -то другое и это очень хорошо.

Часть REST вызовов только читают данные а часть может модифицировать некоторые значения внутри модели данных и нам не известно какую (концептуально это сплошной сайд-эффект).

Определить факт того, что метод только читает или может еще и записывает часто очень просто (а часто не просто).

Очень хорошо, что элементы данных моделей REST отображаются на URL ресурсы.

Основная проблема стыковки в том, что у нас есть транзакционная система и все обращения должны происходить в подтранзакциях специальным образом настроенных. Но у большинства сервисов общение происходит без транзакций вообще. Если подтранзакцию нужно будет откатить, то нужно откатить будет и те изменения, которые уже будут переданы в модель сервиса, а это не есть чистое решение.

Мысль вот в чем.

Когда мы строим взаимодействие внешнего сервиса и нашей системы мы делаем это через промежуточный очень быстрый и простой сервис (IO на самом деле). Данный сервис выполняет кэширование записываемой в сервис информации и выдает ее при чтении. Он совершает запись только в случае успешного камита остальных частей транзакции и в случае успеха - подтверждает успех своей транзакционной части. Такой сервис может уметь откатывать изменения в случае ошибки записи всех нужных изменений.

Что в этом всем хорошего ?

Мы вводим в обычные REST API абстракцию транзакции, через такой способ - это увеличивает надежность системы в целом, не смотря на то, что мы в систему добавляем новые звенья и точки потенциального отказа.

Комментарии

Comments powered by Disqus
Перейти к главному содержимому