Это третья часть серии «Масштабирование Wix до 100 миллионов пользователей».
Введение И второй пост .
Wix начинал с одного сервера, который обеспечивал все функции: регистрацию пользователей, редактирование веб-сайтов, обслуживание опубликованных веб-сайтов и загрузку изображений.
В то время этот единственный сервер был правильным решением, поскольку он позволял нам быстро расти и использовать гибкие методы разработки.
Однако к 2008 году начали возникать повторяющиеся проблемы с развертыванием, приводящие к незапланированным простоям как при создании новых сайтов, так и при обслуживании существующих.
Развертывание новой версии нашей системы в некоторых случаях требовало изменения схемы MySQL. Поскольку Hibernate не прощает расхождений между ожидаемой схемой и фактической схемой базы данных, мы использовали общепринятую практику развертывания программного обеспечения: запланированное двухчасовое отключение в период наименьшего трафика (полночь по выходным в США).
Во время этого запланированного отключения нам пришлось остановить службу, выключить сервер, внести изменения в схему MySQL, развернуть новую версию и перезапустить сервер.
Эта запланированная двухчасовая остановка часто превращалась в нечто более сложное из-за проблем, которые могли возникнуть во время развертывания.
В некоторых случаях внесение изменений в схему MySQL занимало заметно больше времени, чем планировалось (изменение больших таблиц, перестроение индексов, снятие ограничений на миграцию данных и т. д.).
Иногда после изменения схемы и попытки перезапустить сервер он не запускался из-за какой-либо непреднамеренной проблемы с развертыванием, конфигурацией или схемой, которая мешала его работе.
А в некоторых случаях новая версия нашего программного обеспечения была сломана, поэтому для восстановления сервиса нам приходилось снова менять схему MySQL (чтобы она соответствовала предыдущей версии) и повторно развертывать предыдущую версию системы.
Но самое страшное было, если через несколько дней после «успешного» развертывания мы обнаружили в новой версии критическую, хоть и редкую, ошибку, которая привела к порче пользовательских сайтов.
В этом случае лучше всего было откатиться на предыдущую версию (по крайней мере, до устранения ошибки), а это требовало повторного изменения схемы, что означало внеплановую остановку сервиса.
Важно отметить, что, поскольку мы использовали одно серверное приложение для обслуживания всех систем Wix, отключение затронуло всю службу, включая опубликованные сайты.
По мере роста нашей пользовательской базы все больше и больше сайтов подвергались плановым и внеплановым отключениям.
И тут нас осенило
Wix выполняет две разные функции: поддержку существующих сайтов и создание новых сайтов.Прекращение создания сайтов напрямую влияет на наши ежедневные продажи, но остановка действующих сайтов напрямую влияет на наших существующих и платящих пользователей.
Нам нужно было определить и создать разные уровни обслуживания для каждой функции.
Кроме того, после дальнейшего анализа мы обнаружили, что большая часть наших нововведений была связана с разработкой новых сайтов, и лишь небольшое количество изменений затронуло существующие сайты.
Это означало, что мы выпускали частые выпуски программного обеспечения, которые ставили под угрозу функционирование как сайтов, которые мы создавали, так и тех, которые уже работали, даже если изменения затрагивали только те сайты, которые мы создавали.
Понимая это, мы разделили нашу систему на два сегмента: редакционный сегмент, отвечающий за создание новых сайтов, и публичный сегмент, отвечающий за поддержку сайтов.
Данное решение позволило нам обеспечить разные уровни обслуживания, соответствующие каждой из бизнес-функций.
Технологический стек, выбранный для построения публичного сегмента, был намеренно простым.
Мы больше не использовали Hibernate, отказались от любых форм кеша и начали использовать Spring MVC 3.0. Важным принципом проектирования было сделать сегменты отделенными друг от друга с точки зрения программного обеспечения, циклов выпуска и хранения данных, а также сделать стек программного обеспечения простым для понимания и оптимизированным для обслуживания сайтов.
Явным признаком этого разрыва стал процесс публикации (потомки которого все еще присутствуют в ядре Wix), который копировал данные из базы данных редакционного сегмента в базу данных общедоступного сегмента.
Этот процесс преобразовал структуры данных из представления, которое было эффективно для редактирования, в представление, которое лучше всего подходило для опубликованного сайта.
В результате развертывания публичного сегмента стали редкими и с низким уровнем риска.
Он все еще работает на Wix, спустя шесть лет после его первого развертывания (хотя с тех пор кое-что изменилось).
Что мы узнали
Мы уже знали, что цикл выпуска был рискованным, но теперь мы поняли, что две наши основные бизнес-функции — создание и поддержка сайтов — подвергались различным рискам.Мы поняли, что нам необходимо обеспечить разные уровни обслуживания для этих функций и что мы должны строить нашу систему вокруг них.
Что это за разные уровни обслуживания? Мы рассмотрели следующие аспекты: доступность, производительность, рискованность изменений и время восстановления после сбоя.
Публичный сегмент, который затрагивает всех пользователей и все сайты Wix, должен иметь самый высокий уровень обслуживания в этих аспектах.
Но в редакционном сегменте сбой затрагивает только пользователей, непосредственно участвующих в создании сайта, поэтому последствия для бизнеса менее значительны.
Поэтому мы несколько пожертвовали высоким уровнем сервиса ради большей гибкости, что позволило сократить усилия, необходимые для разработки.
Главный архитектор программного обеспечения конструктор сайтов Викс, Йоав Авраами Оригинальная статья: Блог инженеров Wix Теги: #wix.com #сервер #MySQL #базы данных #MySQL
-
Мобильные Веб-Приложения Для Бизнеса
19 Oct, 24 -
Нумерация Двоичного Дерева
19 Oct, 24 -
Где Находятся Закладки В Google Bookmarks?
19 Oct, 24
