А теперь подробнее:
В предыдущих частях мы уже рассказали о разработке сайта, личного кабинета и мобильной версии для компании «Авангард». Для личного кабинета по просьбе заказчика мы организовали расширенный обмен данными на основе XML-файлов. Но это решение было не самым удобным. И вот настал момент, когда клиент решился перейти к прямому взаимодействию сайта с 1С.
У обмена данными в файловом варианте есть серьезный недостаток — данные обновляются через определенные промежутки времени, а не моментально. Неизбежно возникают ситуации, когда информация на сайте неактуальна. Например, когда покупатель видит, что доступно 200 единиц товара, но на самом деле всё уже раскуплено.
Легко представить, к каким последствиям приводили такие задержки. Двое клиентов с незначительной разницей во времени резервировали один и тот же товар, а остатков не хватало для выполнения обоих заказов. Менеджеру приходилось звонить одному из клиентов, договариваться о замене товара или уговаривать перенести сроки поставки. Согласитесь, это ситуация неприятна для всех. Тем более если она повторяется часто.
Чтобы решить эту проблему, мы предложили организовать прямое взаимодействие сайта с 1С на базе веб-сервисов. В этом случае каждый клиент всегда будет получать только актуальные данные и не сможет заказать товар, если кто-то забрал остатки хоть секундой раньше.
Сложность в том, что такое решение многократно увеличивает количество обращений к базе 1С. Если раньше с базой работали только менеджеры, то теперь к ним присоединятся все клиенты, и каждый запрос от покупателя будет увеличивать нагрузку. Чтобы система не рухнула в первый же день, нужно было модернизировать всю структуру, а это долго и очень дорого — именно поэтому заказчик и отказался от такого варианта на этапе разработки личного кабинета.
Еще один важный момент — структура должна быть полностью отказоустойчивой. Если разместить всё на одном сервере, система окажется под угрозой, ведь любой сбой может закрыть доступ ко всем данным сразу. Нужно было распределить структуру по разным физическим серверам. В этом случае система будет работать, даже если один из серверов выйдет из строя.
Решение задачи было комплексным:
● Мы протестировали разные системы управления базами данных, включая Microsoft SQL, PostgreSQL и Oracle RAC. Остановились на последнем варианте. В том числе потому, что тестирование показало: это единственная система, которая не замедляется при расширении структуры. А значит, в будущем клиент сможет добавить несколько серверов и значительно увеличить объем данных без замены программного обеспечения. Файловая система Oracle ASM помогла избавиться от классического узкого места баз данных — чем больше запросов к диску, тем дольше они обрабатываются. И поскольку большая часть запросов пользователей проекта идет на чтение информации, то количество дублирующих дисков даже увеличивало скорость работы всей системы. В итоге даже в самые загруженные часы всё работает быстро.
● Отказоустойчивость системы обеспечивается дублированием всех узлов. Для виртуализации кластера 1С и сайтов Битрикс заказчика мы применили связку Proxmox и Ceph — она обеспечивает слаженную работу дублирующих систем. Теперь если один из серверов кластера или коммутатор из стека вдруг выйдут из строя, пользователи даже не заметят этого. А системный администратор получит сообщение о неисправном диске или отказавшем сервере.
● Мы не могли полагаться на каналы интернет-связи. Чтобы сайт и 1С работали с большим количеством информации без задержек, мы разместили все физические сервера в одном дата-центре, связав их высокоскоростной сетью Infiniband — у нее огромная пропускная способность, поэтому все данные обновляются мгновенно даже при очень высоком числе запросов от пользователей.
На выходе мы получили такую схему:
Пользователи работают с сайтом на Bitrix, а сотрудники компании — напрямую с 1С. В свою очередь, 1С обращается к базам данных.
Мы тщательно протестировали готовую инфраструктуру, чтобы исключить возможные проблемы. Мониторинг нагрузки Zabbix сообщал администратору обо всех сбоях и о ситуациях, когда уровень нагрузки превышал 70%. В итоге после всех тестирований мы поняли, что систему ограничивает лишь объем оперативной памяти — а это легко исправить добавлением мощностей.
После полугода работы сервиса в режиме реальных нагрузок мы можем сказать точно: проблем не возникает и мощностей вполне хватает. Но, конечно, мы желаем клиенту расширить торговую сеть настолько, чтобы объем оперативной памяти все же пришлось увеличить!
