Страницы

Сторителлинг

Рассказывал одному из переговорщиков суть моего проекта. Ну вот просто так, по шагам.

  1. И придумали люди веб-страницы и стали они множиться под солнцем. И каждый желал себе не волов, но страниц красивых с анимацией и вертикальными параллаксами. И приумножились они и стало их как песка морского... :)
  2. Чтобы в них не потеряться люди придумали поисковые системы. Теперь все зависит от положения в поисковом запросе.
  3. И придумали люди мобильные платформы. И вот тут-то все недостатки веб-решений всплыли и стали выпуклыми. Да насколько, что люди предпочитают пользоваться специально написанными для телефонов и планшетов программами. 
  4. И вот опять все стало повторяться. (Ибо нет ничего нового под солнцем.) Каждый магазинчик и каждая лавчонка, не говоря уже о крупных предприятиях, захотели и себе написать приложения. И будет их скоро как песка морского.
  5. Но мы же не можем в свои телефоны поставить миллионы приложений!
Опять встал вопрос о передаче удаленно исполняемых приложений на сторону клиента. Об этом думают все и всяк на свой лад. 
Google вот внедряет концепцию Instant Application. Но, как он сам говорит, это (фактически) стримминг приложений, терминальное решение. Оно требует серьезного и стабильного канала связи. Но дело даже не в этом. Дело в том, что хостить графические приложения на стороне сервера для терминальной трансляции клиенту - очень дорогое и совершенно непродуктивное занятие. 
А вот мы, в рамках проекта Kalpa, придумали срединное решение. Оно позволит:
  • Передавать интерфейс удаленного приложения максимально компактно, 
  • Графика создается на стороне клиента
  • Сервер может обрабатывать на порядки больше сессий нежели в терминальном режиме. 
  • А программу писать как простую десктопную
  • И безопасно конечно. Потому что у клиента ничего не остается. Можно с любовницей переписываться. Жена не узнает.
И создать можно очень интересное глобальное решение. Интернет приложений. 
Боты - жалкие шутки. Реальные удобные интерфейсы непосредственно в коммуникаторе или карте - выбор нового времени.

Вот такая история. 



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

Интересно отметить, что разработчики используют нативные средства создания мобильных приложений. Для платформы Android использует Java, для ios -- Objective-C, для MsPhone -- C#. А для десктопов пишут вообще бог знает на чем.

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

Наш подход несколько иной. Используя С++ мы получили возможность разрабатывать системы для всех платформ в единой кодовой базе. Нет необходимости привлекать разработчиков для разных платформ. Компетенции можно поддерживать на высоком уровне, а из взаимозаменяемость позволяет разработчикам без дополнительного обучения заниматься разными платформами.

Мы определенно считаем такой подход значительно более экономичным.

К вопросу об организации оркестратора кластера в деле бесшовного ввода новых версий Kalpa-системы.

Страшное дело - организация взаимодействия в большой системе взаимодействующих узлов.
Первое и основное дело, с каким придется столкнуться - реализация плавного, бесшовного обновления всей системы на новые версии. Причем делать это надо не дергая пользователей. Пусть они спокойно доработают свою сессию на старой версии. Для обеспечения такой плавности необходима одновременная работа как всего серверного хозяйства в старой версии, так и плавный ввод в работу версии новой.
Итак. В системе существует служба "SystemControl". Она отвечает:

  • За контроль топологии системы. Знает какие узлы существуют в системе и какие службы эти узлы обслуживают.
  • Мониторит отказ отдельных узлов и перебалансировку топологии системы.
  • Осуществляет плавное обновление системы. 
Каждая служба (кроме слоя сервера приложений) имеет свой набор сетевых портов ожидания. Каждая версия использует только один из трех портов. SystemControl всегда знает расписание портов текущей и прошлой версии. Таким образом можно одновременно держать несколько версионных слоев служб на всем пространстве узлов.
Схематиченый сценарий ввода в работу новой версии все системы таков. 

  • Соединение специальной утилитой с SystemControl и инициация протокола запуска новой версии системы.
  • Загрузка через SystemControl исполняемых файлов и библиотек всех служб системы.
  • Активация новой версии SystemControl на новом порте ожидания.
  • Новая версия SystemControl (из общей со старой версией базы) получает список всех рабочих узлов системы и через старую версию NodeControl, работающую на каждом узле, передает файлы и библиотеки новой версии на каждый узел. 
  • На каждом рабочем узле активируется новая версия NodeControl на новом порте ожидания.
  • После того как получено подтверждение о запуске новой версии NodeControl начинается процесс активации внутренних служб согласно текущей топологии системы. Стартуют все службы кроме серверов приложения.
  • После подтверждения старта внутренних служб новая версия SystemControl начинает процесс активации слоя новых версий серверов приложений. Для этого ->
    • SystemControl соединяется со старой версией NodeControl (на узле AS) и отключает старый сервер приложений.
    • SystemControl соединяется с новой версией NodeControl (на узле AS) и активирует новую версию сервера приложений.
    • В службе ASControl все активные AS-серверы удаляются и "взводится" первый рабочий сервер приложения. 
    • Каждый последующий запущенный сервер регистрируется в ASControl, что происходит практически мгновенно.
  • SystemControl перехватывает управление соединяясь со старой версией NodeControl на всем пространстве запущенных узлов и получает доступ к статистической информации о системе. 
  • Когда на всех узлах AS (ApplicationServer) прекращается обслуживание последней доживающей пользовательской сессии, можно с уверенностью сказать, что все пользователи, использующие старый слой сервера, завершили свою работу. 
  • После завершения работы последнего пользователя старой версии все уровни внутренних служб гасятся через NodeControl каждого узла.
  • После гасятся сами NodeControl, ASControl и SystemControl старой версии.
  • Система полностью и плавно переходит на новую версию.
Простой системы (в части обработки поступающих запросов на установку новой сессии) минимален (несколько миллисекунд).

Такая архитектура позволяет держать несколько версионных слоев системы одновременно. Считаю, что 3 одновременно работающих версии более чем достаточно даже для весьма масштабного кластера.

Новости госмессенджеров.


«Развитие IT-технологий является приоритетом работы правительства Республики Крым. Наш президент в своём послании Федеральному собранию назвал развитие цифровой экономики вопросом национальной безопасности и технологической независимости России. Глава государства обратил особое внимание на риски, связанные с цифровыми технологиями, и необходимость защиты от киберугроз», — отметил Сергей Аксёнов.
Андрей Назаров уточнил, что свои разработки программисты могут представить на третьем ялтинском форуме в апреле следующего года. Отметим, что Назаров также занимает пост председателя правления Ялтинского международного экономического форума.
Госконтрактом с крымским правительством уже заинтересовались разработчики российского мессенджера Dialog, которые участвуют в конкурсе Института развития интернета на создание государственного мессенджера для федеральных чиновников.

«Мы готовы принять участие и в разработке закрытого безопасного мессенджера для крымских чиновников, в свете чего планируем проведение масштабной презентации корпоративного мессенджера Dialog в дни прохождения ялтинского форума в апреле 2017 года», — заявил Андрей Кузнецов, директор по информационным технологиям мессенджера Dialog.



https://russian.rt.com/russia/article/341179-chinovniki-krym-messendzher
Related Posts Plugin for WordPress, Blogger...