Часть 1. Введение

Часть 1. Введение
Часть 2. Общая структура
Часть 3. Первичные цепочки
Часть 4. Администратор данных
Часть 5. Администратор процессов
Часть 6. Структура приложения
Часть 7. Публикация в GCP

Модули предприятия

SYNRC Предприятие является комплекском библиотек (N2O.DEV) и подсистем приложенинй (ERP.UNO), которые использует общую шину и общую распределенную базу данных.

N2O.DEV ERP.UNO O7.NETWORK ROOTS ------- --------- ---------- ----------- active acc bud n2o.dev bert bank chat n2o.space bpe chat plm synrc.com form crm sample synrc.space fs db bench o7.network kvs ent o1.network mach erp mad fin n2o fix nitro ldap pie mq rest pay sh pm review rocksdb sample scm sys tic tms wms xio

LDAP — Сервер аутентификации, хранение ключей и директория предприятия.

ERP — Этот модуль хранит основную иерархическую структуру предприятия, ее схему, записи о персонале, инвентаре, компаниях предприятия, их офисах.

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

ACC — Система управления персоналом: зарплатные ведомости, календарь предприятия, отпуска, декреты, другие календари.

SCM — Система управления цепочкой поставок: главный БП системы — экспидиционный процесс доставки товаров цепочке получателей с помощью транспортных компаний.

CRM — Система управления клиентами: является расширение более абстрактного приложения CHAT.

PLM — Система управления жизненным циклом проектов и продуктов. Содержит также CashFlow и P&L отчёты.

PM — Система управления проектами предприятия с детализацией времени и протоколов приема-передачи (принятые коммиты в гитхабе).

WMS — Система управления складом.

TMS — Система управления транспортом предприятия.

Модуль PLM

В этому документе описана система управления жизненным циклом продуктов и проектов — Product Lifecycle Managenent (PLM). На базе PLM модуля мы разработали систему управления аутсорсинговым предприятием Quanterall с возможностью инвестирования и учётом опционов для программистов.

Цели проекта:

— Повышение прозрачности ведения бизнеса;
— Выдача опционов с прибыли;
— Автоматизация предприятия.

Задачи проекта:

— Создание панели управления директора, работников и инвесторов;
— Попроектная отчетность (СashFlow, P&L);
— Управление опционами программистов;
— Инвестирование в проекты другими инвесторами (со страхованием).

Бизнес процесы:

— Бизнесс-процесс счет участника проекта (FIN);
— Главный бизнес-процес модуля — долгоживущий проект-продукт (PLM);
— Создание проекта с привлечением инвестиций под залог прибыли от других проектов (Pre-PLM);
— Ежемесячный процесс распределения прибыли (PLM-Calc): после вычитания свёртки выплаченых зарплат из свёртки оплаченых счетов клиентам по CashFlow мы формируем список статей: 1) страховой фонд (который откусывается если мы используем этот проект как залог для кредита на другой проект; 2) опционы программиистов которые выдаются автоматически людям которые работают на этом проекте, но любые другие могут тоже учавствовать; 3) наш заработок (свободный пул или резервация); 4) R&D отчисления (обязательные).

Руководство разработчика PLM

Руководство разработчика PLM включает пошаговое описание процесса создания подсистемы PLM и использованием библиотек SYNRC: 1) Административная часть KVS, BPE, FORM; 2) Модули конфигурации PLM: PLM, FIN, LDAP.

Система PLM зависит также от других модулей предпрития: FIN — финансовый модуль управления персональными счетами и счетами предприятия; ACC — модуль управления персоналом и контрагентами; ERP — модуль инкапсуляции организационной структуры предприятия; LDAP — система управление идентификаторами и ключами. Кроме модулей предприятия здесь также рассматриваются библиотеки, зависимости модуля PLM: BPE — система управления бизнес процессами предприятия; KVS — система хранения данных; FORM — система генерации форм. PLM зависит и от других библиотек, но они в этом документе не рассматриваются: N2O — система управления соединениями и протоколами; NITRO — система генерация HTML5.

Управление ресурсами

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

SOA архитектура в качестве модели управления вычислительными ресурсами предлагает асинхронный протокол удаленного вызова на шинах. С N2O можно использовать MQTT и другие шины посредством следующих протоколов: TCP, WebSocket. Еще эти асинхронные протоколы часто называются протоколами реального времени, так как функции посылки сообщений всегда мгновенно возвращают результат. Что касается протоколов для публикации и доступа к данным то тут может оказаться уместным использование синхронного HTTP протокола.

Вычислительные ресурсы

Для SOA архитектуры традиционно используются асинхронные протоколы доступа к вычислительным ресурсам. Обычно это сервереные воркеры подключённые к шине и обслуживающее API определённого приложения. Каждое приложение имеет свой консистентное хеш-кольцо воркеров. В сети работает одноврменно множество колец-приложений.

config :n2o, tcp_services: ['ldap'], ws_services: ['chat'], mqtt_services: ['erp', 'bpe']

С помощью config.exs файла можно сконфигурировать необходимую конфигурацию серии консистентных колец каждое из которых работает на своем транспортном протоколе. В данном примере показана карта Erlang серверов обслуживающих очередя приложений в шине:

> PLM.vnodes [ {{:tcp, '/ldap/tcp/4'}, [:n2o_tcp]}, {{:tcp, '/ldap/tcp/3'}, [:n2o_tcp]}, {{:tcp, '/ldap/tcp/2'}, [:n2o_tcp]}, {{:tcp, '/ldap/tcp/1'}, [:n2o_tcp]}, {{:ws, '/chat/ws/4'}, [:n2o_ws]}, {{:ws, '/chat/ws/3'}, [:n2o_ws]}, {{:ws, '/chat/ws/2'}, [:n2o_ws]}, {{:ws, '/chat/ws/1'}, [:n2o_ws]}, {{:mqtt, '/erp/mqtt/4'}, [:n2o_mqtt]}, {{:mqtt, '/erp/mqtt/3'}, [:n2o_mqtt]}, {{:mqtt, '/erp/mqtt/2'}, [:n2o_mqtt]}, {{:mqtt, '/erp/mqtt/1'}, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/4'}, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/3'}, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/2'}, [:n2o_mqtt]}, {{:mqtt, '/bpe/mqtt/1'}, [:n2o_mqtt]}, {{:caching, 'timer'}, [:n2o]} ]

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

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

Накопительные ресурсы

Распределённые хеш-кольца используются не только для распределения вычислителений, но и для хранения данных. Некоторые базы данных, например RocksDB и Cassandra используют глобальное пространство ключей для данных в отличие от таблично-ориентированных баз. Именно для таких баз и создана библиотека KVS, где в качестве синхронного транзакционного интерфейса — API цепочек c гарантией консистентности. В данном примере показан пример структуры цепочек эксземпляра системы PLM:

> :kvs.all :writer [ {:writer, '/bpe/proc', 2}, {:writer, '/erp/group', 1}, {:writer, '/erp/partners', 7}, {:writer, '/acc/synrc/Kyiv', 3}, {:writer, '/chat/5HT', 1}, {:writer, '/bpe/hist/1562187187807717000', 8}, {:writer, '/bpe/hist/1562192587632329000', 1} ]

В нашей модели синхронные протоколы используются для управления накопительными ресурсами предприятия и транзакционного процессинга.

Типовые спецификации

Протоколы определяются типовыми спецификациями и генерируются для следующих языков: Java, Swift, JavaScript, Google Protobuf V3, ASN.1. Также мы генерируем валидаторы данных по этим типовым аннотациям и встраиваем эти валидаторы в тракт наших распределенных протоколов, поэтому мы никогда не позволим клиентам испортить сторадж. Для веб приложений у нас развитая система валидации как для JavaScript так и на стороне сервера. Бизнес логика полностью изолирована в нашей системе управления бизнес процессами, где каждый бизнес процесс является процессом виртуальной машины. Все цепочки модифицируются атомарным образом, поддерживают flake адресацию и не требуют дополнительной изоляции в своём принимитивном использовании. Поэтому вы можете трактовать базу как распределенный кеш и использвать её из фронт приложений для примитивных случаев.