• История изменений
• Цель проекта/задачи
• Термины и сокращения
• Бизнес-архитектура решения
  • Функциональная модель процессов
• Информационная архитектура решения
  • Потоки данных
  • Бизнес-данные
• Архитектура приложения
  • Концептуальная модель и интеграция
  • Перечень компонентов
  • Выбор СУБД
  • Архитектура БД
  • Выбор языка программирования
  • Модель компонентов приложений
  • Модель развертывания приложений
  • Open Api
• Требования и решения по безопасности

Цель:

• Повышение качества взаимодействия компании (Ростелеком) с ее клиентами за счет расширения текущих функциональных возможностей CRM

Задачи:

• Разработать архитектуру, реализующую требования к решению
• Интегрировать переиспользуемые функциональные возможности уже реализованных компонент
• Реализовать отсутствующие функциональные возможности путем разработки новых, доработки или замещения уже существующих в наследованных компонентах (без доработки самих компонент) в создаваемом решении
• Спроектировать интеграцию решения с другими системами

Уровень 0

Уровень 1

ER Diagram

Показать

Диаграмма компонентов

Диаграмма классов

Для проектируемого решения предлагается использовать следующие СУБД:

• Postgres Pro Enterprise – для хранения и обработки транзакционных данных.
• Виртуальное хранилище Ростелеком – для хранения файлов.

Выбор виртуального хранилища Ростелеком обусловлен использованием уже существующей инфраструктуру заказчика и поддержкой распространенного протокола Amazon S3 API. СУБД Postgres Pro была выбрана в результате оценки критериев сравнения между наиболее распространенными реляционными СУБД (данный тип обеспечивает наиболее эффективную обработку транзакционных данных).

С учетом специфики заказчика, наиболее целесообразным является выбор СУБД Postgres, обладающей следующими преимуществами:

• отсутствие санкционных рисков использования;
• наличие вендоров осуществляющих поддержку и развитие на территории РФ;
• наличие open source версии для исключения vendor lock.

Далее среди отечественных решений на основе СУБД Postgres был выбран продукт, имеющий реализацию высокодоступного (high availability) кластера «из коробки»: СУБД Postgres Pro Enterprise. Основным преимуществом реализации кластера СУБД Postgres Pro Enterprise является:

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

В современных проектах применяется комбинация этих двух языков - RoadRunner, когда препроцессор PHP находится в обертке Go, таким образом процесс PHP является "не убиваемым". Но такие решения чаще распространяются на устоявшиеся проекты, которые требуют увеличения производительности. И в затраты на них учитывается работа программистов обоих стеков. Само решение "сырое" и что также рискованно к применению.

Язык Go отлично подходит для реализации небольших, стабильно работающих приложений, может быть скомпилирован на любую платформу. Писать на нем "идиоматически верно" при переходе с ООП языков трудно, что занимает время и желательно наличие грамотного (дорогого) наставника. Не рекомендуется для написания больших монолитных проектов. Не требует стороних сервисов для работы, что также облегчает разворачивание приложения в кластере k8s. Прекрасно работает с protobuf через gRpc, что облегчает взаимодействие между сервисами из-за вынужденного соблюдения интерфейсов. Что дает гарантию целостности данных и их правильного восприятия. Минимальная вероятность появления панических ошибок и надежность исполнения кода - основная причина выбора этого языка. Наличие в команде опытного специалиста - гарантия быстрого включения в проект любого специалиста при переходе с любого языка программирования, за кротчайшее время.

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

Использовались данные с сайта https://benchmarksgame-team.pages.debian.net/benchmarksgame/

Open API

• Система должна удовлетворять требованиям Постановления Правительства РФ от 01.11.2012 N 1119 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных".
• Gitlab Security Analysis не должен находить уязвимостей в компонентах системы в ходе сканирования.