Кейс: сервис для медицинского обслуживания «Деломедика». Часть 1
Мы сотрудничали с компанией «Деломедика», предоставляющей медицинское обслуживание частным лицам и компаниям, предлагая выгодные цены, современное оборудование и специалистов высокого класса.
Наша команда работала над глобальным обновлением сайта, и мы готовы представить вам результаты нашей работы!
Новая структура данных
Проблемы структуры прошлой версии
Главной проблемой развития прошлой версии сайта была нелинейная структура хранения ключевой информации, которую было сложно поддерживать и расширять.
Города
Не существовало понятия «город» — он был тем же, что и медцентр. Т. е. добавить, например, второй медцентр в Москве, сохраняя логику системы было технически невозможно и могло решаться только с помощью логических исключений из общей структуры хранения данных (костыли в программном коде).
Решение – созданы линейные справочники городов и медцентров, позволяющие удобно привязывать медцентры к городу, осуществлять региональные настройки для каждого города, влияющие на поисковую оптимизацию по регионам.
Разрозненный контент
В прошлой версии сайта было написано множество логических исключений для отображения не типовых блоков данных, требующихся в различных ситуациях. Такой подход часто не давал понимания как правильно изменить данные на той или иной странице сайта, усложнял его обслуживание и провоцировал рассинхронизацию региональных данных.
Решение – при разработке нового сайта был реализован механизм хранения типовых данных с помощью контент-блоков, управляемый в административной панели. Каждый блок можно привязать к любому количеству страниц сайта, что обеспечивает универсальный способ создания контента.
Технологический стек
Общая схема работы инфраструктуры
Разделение логики и визуализации
Современный подход к разработке цифровых продуктов предполагает организацию гибкой инфраструктуры и возможность быстрого обмена данными между различными платформами. Вместо классического подхода, когда за бизнес-логику, систематизацию и хранение всех данных отвечает один сервер было выбрано архитектурное решение с разделением инфраструктуры на: API-сервер, сервер баз данных, сервер рендеринга и хранилище статического контента.
Rest API на основе 1С-Битрикс (backend)
Для реализации распределенной инфраструктуры на основе платформы 1С-Битрикс был разработан механизм Rest API, который позволяет обращаться к логическому серверу с помощью специального языка запросов и получать данные в документированном машиночитаемом формате.
Этот механизм можно в дальнейшем использовать для предоставления данных внешним системам — в том числе при разработке мобильных приложений или встраивания в личные кабинеты и другие информационные системы.
Сервер пререндеринга и браузерное приложение
Сервер, обеспечивающий максимально быстрый ответ для браузера (frontend server) построен на основе JavaScript фреймворка Nuxt. js, реализующего технологию SSR (Server Side Rendering). Она позволяет возвращать полноценную html-страницу в браузер или на запрос поисковой системы, вместе с браузерным JavaScript-приложением, которое отвечает за дальнейшее взаимодействие с Rest-сервером.
После первой загрузки — все операции выполняются внутри браузера пользователя, обеспечивая почти мгновенный отклик интерфейса и работу сайта без видимой перезагрузки страниц.
Базовым фреймворком для построения браузерного приложения был выбран Vue. js, применяемый во многих современных системах. На аналогичных технологиях реализован, например, маркетплейс OZON. ru.
Отдельное хранилище статического контента
В целях обеспечения безопасности, а также функционального разделения инфраструктуры, статические данные, такие как файлы для загрузки, изображения и прочее, были размещены в объектном хранилище, типа S3. Формат разработан в компании Amazon и получил широкое распространение в силу своей универсальности и безопасности.
Сервер такого формата не позволит запустить исполняемые файлы, а это значит, что если злоумышленник или вирусный сценарий попробует загрузить на сайт поддельное изображение для организации взлома — программа не будет выполнена.
Готовность к высокой нагрузке
Благодаря выбранному подходу, систему можно масштабировать за счет кластеризации. В рамках реализованной инфраструктуры каждую часть системы можно резервировать и кластеризовать, т. е. вместо попытки увеличивать мощности одного сервера и расширения единственного перегруженного канала связи — создавать множество менее мощных серверов (виртуальных контейнеров), равномерно балансируя нагрузку между ними.
Автоматизация публикации изменений (CI/CD)
Сайт выполнен согласно требованиям к безопасности и отказоустойчивости, даже в процессе внесения изменений в программный код.
Код проекта хранится в репозитории программного кода, куда разработчики загружают изменения. Администратор имеет возможность проводить слияния различных «веток», хранящих изменения, после чего инициализируется процесс автоматической публикации на тестовом и/или основном сервере проекта (в зависимости от выбора администратора).
Такая схема позволяет в случае выявления ошибок оперативно откатить версию проекта, а также обеспечивает бесперебойную работу системы даже в процессе выгрузки изменений программного кода.