Как реализовать Интернет-магазин с архитектурой Shared Nothing
Некоторые люди утверждают, что возможно и даже необходимо реализовать каждое веб-приложение с архитектурой Shared Nothing. Как реализовать этот архитектурный стиль в интернет-магазине с корзиной для покупок?
Обычно интернет-магазин может быть реализован с использованием сессий. В этом случае мне пришлось бы реализовать это по-другому, чтобы на сервере не хранилась информация о корзине. Но тогда необходимо будет включить содержимое корзины в скрытые поля, чтобы они передавались на сервер при каждом отдельном запросе. Это решение для интернет-магазина, использующего архитектуру Shared Nothing?
У вас есть какие-либо идеи о том, как создать архитектуру для веб-приложений без совместного использования ресурсов?
4 ответа
Хотя я никогда не пытался создать систему на основе Shared Nothing (SN), я бы посоветовал всем, кто говорит, что необходимо разрабатывать WebApps с использованием "чистого" SN:
- Обладая таким огромным бюджетом, они могут использовать миллион кластеров для каждого уровня.
- Ученые, которые никогда ничего не реализуют.
Если у вас есть кластер веб-серверов, и вы балансируете нагрузку таким образом, что вы не можете гарантировать, что один и тот же веб-сервер будет обрабатывать каждый вызов для данного сеанса - тогда да, применяются принципы SN: Вы не можете позволить себе ввести сходство с сервером.
Но растягивать это для "каждого" веб-приложения просто абсурдно.
SN, как и все другие архитектуры, похожи на инструменты - они являются решением проблем; проблема определяет решение, а не наоборот.
Что касается моего опыта работы с интернет-магазинами, архитектура без разделения ресурсов лучше, чем сессионная. Я очень часто раздражался из-за того, что моя карточка покупок исчезла из-за истечения сеанса! AJAX или нет, веб-приложение должно по крайней мере хранить выбор пользователя в файлах cookie или, если возможно, в хранилище HTML5 и других замечательных механизмах.
Тем не менее, приложения, основанные на HTTP-сеансах, также имеют свои плюсы, особенно при кэшировании на стороне сервера ресурсов для пользователей, что является дорогостоящим приобретением - типично для систем с большой нагрузкой и транзакций с большой бизнес-логикой. Во многих случаях смешанные решения будут лучшим выбором.
Так что мой ответ - это зависит. Вы должны написать требования и выбрать лучший, не обращая внимания на название шаблона или архитектуры, которую вы применяете:)
Вы можете использовать распределенный кеш (например, memcached) для хранения данных сеанса на стороне сервера.
Услуги, предоставляемые ведущими поставщиками облачных услуг, могут дать вам представление о том, как достичь SN в древовидном приложении. Использование балансировщиков нагрузки с различными политиками поможет вам переместить общие ресурсы на их собственные серверы, что сделает ваши серверы приложений доступными для сети. Но СУБД всегда является узким местом для SN.
Чтобы разгрузить загрузку хранилища сеанса из базы данных, кеш в памяти приходит на помощь, так как данные находятся в ОЗУ, а отказоустойчивость, управляемая Redis(например,), доступ к данным сеанса становится быстрее. К хранилищу файлов для серверов приложений и баз данных обращается NAS, и серверы могут быть подключены к NAS. Поисковая деятельность также является бременем для РСУБД. ElasticSearch может разгрузить поисковую нагрузку из вашей БД. Еще одно улучшение, которое можно сделать, - это использовать кеш в памяти перед вашей базой данных для запросов. Если запись не изменилась с момента последней выборки, вы можете просто вытащить ее из кеша, а не из БД.
В большинстве случаев запросы чтения - это больше, чем обновления / вставки. В таком случае, если одна БД не может справиться с нагрузкой чтения, вы можете создать несколько реплик чтения своей БД.
Если загрузка достигает стадии, когда даже использование реплик чтения не работает, тогда последний вариант - сегментировать вашу базу данных, чтобы ваш бизнес шел хорошо, и у вас были ресурсы для решения этой проблемы, когда придет время для сегментирования.