Глава 2. Базовые категории и технологии
Термин Система далее будет абстрактно указывать на развернутую платформу «Era», либо продукт на ее базе, не делая в этом различий.
Стек платформы
Под стеком понимается определенный набор инструментов и принципов, с помощью которых можно удобно создавать продукты. Стек платформы включает в себя саму платформу (программный продукт), некоторые готовые приложения по управлению ей, а также принципы создания и кастомизации продуктов на ее базе и автоматизированный процесс продуктовой сборки и тестирования. Платформа закладывает в стеке основные архитектурные принципы, которые
-
обеспечивают соблюдение нефункциональных требований и атрибутов качества в представленном порядке их важности,
-
закрывают ряд функциональных требований коммуникационной направленности,
-
определяют подходы к реализации других функциональных требований,
-
формируют возможности для интеграции и включения в другие продукты, в том числе путем декорирования.
Сама платформа в чистом виде не является готовым для поставки продуктом – нет должной продуктовой пользовательской документации, нет названий, логотипов, организованных процессов поддержки. Тем не менее дистрибутив платформы может быть собран, и точно по этим же принципам собираются продукты на ее основе. Более того, процесс сборки есть только у платформы, продукты его напрямую наследуют и при необходимости кастомизируют.
Несколько базовых категорий
Архитектура платформы определяет архитектуру всего стека. Базовые категории вводятся в результате анализа нескольких входных требований, упомянутых в начале документа.
-
Система должна быть масштабируемой. Значит она многосерверная. Понятие сервера.
-
Система должна быть распределенной, обеспечивая полноценное функционирование отдельных частей при сетевой недоступности. Выделенная группа серверов на каждой площадке. Понятие сайта, процесс ETL.
-
Система должна поддерживать разделение на несколько независимых компаний с независимым управлением данными. Понятие домена и сущности в домене.
-
Ключевыми атрибутами качества являются доступность и модифицируемость. Ориентация на мини-приложения – с четко очерченным назначением и функционалом – ролью. Понятие приложения и роли .
-
На каждом сервере работает одна или несколько микросервисов. Отсутствие паразитной взаимной зависимости от ресурсов было бы полезным в достижении надежности. Понятие ноды.
Таким образом ключевым для понимания является три слоя рассмотрения системы:
-
Слой инфраструктуры. Сайты, серверы, ноды.
-
Слой данных. Домены, сущности.
-
Слой логики. Роли (микросервисы), приложения.
-
Продуктовый слой. Отраслевые пакеты: модель данных, приложения, микросервисы.
| Понятие | Слой | Определение |
|---|---|---|
|
|
Группа серверов высокой доступности друг для друга, предоставляющая полный функционал системы в рамках кворума (50% + 1). За счет кворума обеспечивается целостность данных при потере связи между серверами сайта, поскольку функциональность поддерживается лишь в одной из групп, и только при условии большинства. Случай четного количества серверов решается с привлечением арбитра - внешнего сервера. Подробнее в xref:achitecture: Каждый сайт является независимым и может производить обмен информацией с другими сайтами. В том числе, возможно подключаться к любым сайтам, авторизовывать, регистрировать и работать с данными любых доменов. На каждом сайте должен обслуживаться хотя бы один домен, использование сайта без домена бессмысленно и невозможно. Определяется текстовым именем, которое начинается с латинской буквы в нижнем регистре, и может состоять из латинских букв и цифр. |
|
|
Площадка, позволяющая запускать программные приложения. Как правило одна физическая или виртуальная машина, имеющая уникальный IP-адрес. Каждый сервер должен принадлежать только одному сайту, использование сервера без прикрепления к сайту невозможно. Определяется текстовым именем, которое начинается с латинской буквы в нижнем регистре, и может состоять из латинских букв и цифр. |
|
|
Процесс операционной системы. В нем работает экземпляр среды исполнения Erlang (англ. Erlang runtime system), которому дано уникальное имя. На одном физическом или виртуальном сервере (адресе) могут быть активны несколько нод. Распределение нод по серверам происходит автоматически на основании настроенной конфигурации. |
|
|
Сущность, определяющая границы группы объектов системы, предоставляющих доступ к функционалу системы. Логика работы системы использует домены и принадлежащие им объекты при реализации функционала и определении доступа для отдельных пользователей. Все данные внутри домена по умолчанию замкнуты. Относится к слою данных. Каждый домен обслуживается на конкретном сайте, использует собственные хранилища данных. |
|
|
Любой объект в домене, созданный администратором и используемый системой в каких-либо протекающих процессах. |
|
|
Условно независимый компонент программной части платформы, имеющий закрепленную ответственность и определенный интерфейс. Роли платформы реализуются в виде приложений уровня или их совокупностей. При сборке версии производится сборка приложений более высокого уровня, где платформа сама выступает в качестве приложения. |
|
|
Микросервис, реализующий некоторый обособленный функционал системы. Составная часть логики платформы. Экземпляр запускается в виде приложения в одной из нод на одном из серверов и имеет уникальное имя в рамках всей системы. Имя начинается с латинской буквы в нижнем регистре и может состоять из латинских букв и цифр. |
|
|
Структура, объединяющая слои инфраструктуры, логики и данных между собой. Какой сервер к какому сайту относится, какие адреса у серверов, какие микросервисы на каких серверах выполняются, какие доменные зоны на каких сайтах обслуживаются и прочие данные. Конфигурация определяется файлом конфигурации, и едина для всех серверов системы. Каждая нода на каждом сервере черпает в конфигурации информацию о том, какие серверы входят в инфраструктуру, обнаруживает себя, определяет какие микросервисы следует активировать, а также на каких серверах располагаются другие микросервисы. |
|
|
Подсистема платформы, позволяющая создавать отраслевые пакеты приложений, и исполнять их. Пакет загружается в конкретный домен, создает там модель данных, микросервисы, пользовательские роли и приложения. В работе с данными использует модель подписки на изменения. Оперирует следующими категориями: перечисления, классы и коллекции, Rest API, элементы управления (Editors), визуальные инструменты (Controls), роли пользователей, приложения пользователей, действия (Actions), микросервисы, обработчики, сценарии, пакеты. |
На всех серверах, где программа развернута, структура программных каталогов выглядит одинаково. Запуск программы на всех серверах также производится одинаково.
Используемые технологии
Erlang OTP
Для обеспечения атрибутов качества при написании слоя бизнес-логики платформы требуется инструмент, позволяющий обеспечить высокую скорость глубоких изменений и отладки при сохранении полного управления исходным кодом и понимания всех алгоритмов разработчиками. Любое принимаемое к использованию стороннее готовое решение (приложение) должно быть доступно как open-source.
В качестве такого инструмента для разработки коммуникационной платформы «Era» выбран Erlang OTP (фреймворк, содержащий набор библиотек и шаблонов проектирования для построения масштабируемых приложений на языке программирования Erlang). Подтвержденная десятилетиями бесперебойной работы в телекоммуникационных решениях надежность виртуальной машины Erlang избавляет от рисков, связанных с незрелостью инструмента. Возможности динамической отладки и горячей замены кода на этапе исполнения известны с начала 1990-х годов и крайне полезны при реализации сервисов с большими требованиями к бесперебойности и доступности. Событийная архитектура с экстремальной легковесностью процессов позволяет избавить разрабатываемую событийно-ориентированную платформу от собственного глубокого слоя решений, обеспечивающих и облегчающих проведение асинхронных операций – она становится драйвером архитектуры платформы. Erlang применяется в таких известных решениях как сервер Яндекс.Диск, игровой мессенджер-коммуникатор Discord, брокер сообщений RabbitMQ и других. Он не является массовым инструментом при разработке ПО, и с этим связана трудность поиска готовых разработчиков. Однако в ходе технологических исследований установлено, что срок ввода нового разработчика составляет от 1 до 4 недель, что практически снимает проблему.
С++
Медийный процессор требует высочайшей производительности, поскольку основное время всех процессоров при работе коммуникационной платформы занято именно обработкой трафика – аудио и видео, особенно это значимо при использовании транскодинга (перепаковки медиа-сервером трафика из одного кодека в другой). Выделение медийного процессора в отдельное рассмотрение обусловлено совершенно иным распределением приоритетов в нефункциональных требованиях. Его разработка ведется на C++. Так, достигаемая производительность – 150-200 одновременных голосовых разговоров на одно процессорное ядро (конкретное значение зависит от используемых кодеков), не может быть обеспечена ни одним другим доступным инструментом.
PostgreSQL
Для хранения данных конфигурации используется реляционная БД PostgreSQL. Ее использование также временно расширено до баз данных хранения истории событий и предварительно агрегированных журналов. Возможно использование в качестве проектной БД через регистрацию строки подключения в домене.
Apache.Kafka
Распределенная отказоустойчивая стриминговая платформа, брокер сообщений. Используется для приема потоков событий из коммуникационной платформы с целью дальнейшего перенаправления в системы хранения и построения отчетов.
Yandex.ClickHouse
Представлен сообществу в 2016 году как высокопроизводительная колоночная БД с возможностью построения многосерверных отказоустойчивых кластеров для хранения BigData и аналитической работы с данными. Яндекс.Метрика работает на базе ClickHouse, развернутом более чем на 300 серверах, и хранящем более 20 ПБ информации. Компактное хранение данных, высокая скорость построения аналитических запросов, независимость от размера хранилища позволяют использовать ClickHouse в качестве альтернативного инструмента для хранения истории событий коммуникационной платформы «Era» с возможностью построения аналитических отчетов напрямую без предварительной агрегации.
JS/TS + React
Утверждена концепция написания независимых клиентских веб-приложений под каждую пользовательскую роль. Большое внимание уделяется скорости разработки, приоритет отдается небольшим приложениям с понятным и полезным "здесь и сейчас" функционалом. Динамичная подстройка решений требует большой гибкости, соответственно построение громоздких приложений не отражает этой потребности. Тем не менее остается возможность стыковать платформу посредством API с произвольными приложениями. Принцип разделения интерфейсов (см.SOLID) предопределил такой подход при построении API и использующих его веб-приложений.
В платформу могут через API загружаться серверные модули/приложения, и исполняться системой и поддерживаться ей в работоспособном состоянии. Собственные "back-end" приложения этого класса также разрабатываются на JS/TS + React. Они выступают в качестве продуктовых микросервисов, с привязкой к специфическим предметным областям. Исполняются в nodejs под супервизией платформы.
TS используется в билдере, и пакетах построенных с его помощью. Микросервисы для отраслевых пакетов создаются на TS, компилируются билдером, при активации пакета загружаются на сервер и исполняются nodejs под супервизией платформы.
Docker
Оперативная унифицированная установка системы на произвольных серверах обеспечивается благодаря Docker. Обновления и дистрибутивы поставляются в Docker-контейнере. Оркестровщики для Docker не используются, поскольку платформа самостоятельно управляет межсерверными коммуникациями, в том числе при обновлении.
-
Следующая глава: Кейсы для глубокого погружения в архитектуру
-
Предыдущая глава: Входные данные