Позвольте мне предоставить вам некоторые детали и предысторию, чтобы понять причины и всю проблему здесь. Конечно, любые предложения / отзывы о приведенной ниже структуре очень ценится.
Кроме того, я не являюсь аффилированным лицом ни с одной из компаний, которые могут видеть ниже или представлять себе в отношении предоставляемых услуг.
Я занимаюсь проектом по «разработке» хорошего плана для компании.
У них есть более 500 веб-сайтов, которые используют одну и ту же базу данных (за ней MySQL), и нацелены на нее глобально. На всех сайтах есть изображения, которые должны быть общими друг для друга. Другими словами, все веб-сайты используют одни и те же изображения (или, по крайней мере, хотят)
Например.
website1.com/image.jpg,
website2.com/image.jpgwebsite1.com/image-de.jpg
website2.com/image-de.jpg
Как вы понимаете, изображения нацелены на GEOtarget, но названия на всех этих веб-сайтах остаются одинаковыми для более быстрого управления.
Однако они плохо «спроектировали» его, и задержка между серверами и управлением образами через некоторое время стала полной катастрофой.
Итак, в двух словах,
3 континента с одним сервером и одним выделенным сервером MySQL на каждый континент. Один сервер разработчика с MySQL в офисе. Кроме того, балансировщик нагрузки Cloudflare для правильного распределения трафика по регионам и «работоспособности сервера».
Global load balancer
|
| | |
V V V
Region1 Region2 Region3 "Office"
| | | Sends ONLY
V V V
WebServer1 <-rsync-> WebServer2 <-rsync-> WebServer3 <- DevServer
| | |
V V V
DBMS-MySQL <-rsync-> DBMS-MySQL<-rsync-> DBMS-MySQL <- DBMS
Имейте в виду, что в зависимости от объема трафика, возможно, стоит разместить второй сервер в одном регионе. Итак, «локальная» структура будет
Global load balancer
|
V
Region1 -> Local load balancer
|
Server:local-1 <- -> Server:local-2
| |
-> MySQL server <-
Резервные копии на каждом континенте на сервере и в отдельном экземпляре S3, и в худшем случае дев-сервер является последней резервной копией.
Теперь представьте, что папка с изображениями - это большая «корзина с изображениями». Итак, как можно обычно прикреплять "корзину изображений" к КАЖДОМУ веб-сайту?
Все серверы будут использовать (я думаю, это поможет легко) rsync
каждые 15–30 минут на случай повторной синхронизации для основных файлов, таких как «файлы HTML / CSS и т. д.»
У меня здесь большие накладные расходы?
Есть ли другое решение, позволяющее «постоянно обновлять серверы»?
Конечно, один из них будет основным, и, как я полагаю, основным сервером-первым-основным будет сервер разработчика, на котором будут размещены основные элементы, такие как панели администрирования и т. Д. Таким образом, после "push" dev-сервер будет "нажимать" или "rsync" все для всех трех Regions-серверов.
Как вы понимаете, это будет огромной проблемой, если я "rsync" папку / image /. Мы должны поговорить о 500+ / image / папках aprx. (прямо сейчас) по 20 ГБ. Так что нам нужно 500 * 20 ГБ = 10.000 ГБ дополнительно для изображений .. Это не тот случай, как вы понимаете.
1) Одним из «грязных» решений может быть размещение на одном сервере всех изображений и каждого веб-сайта с использованием HTTP-запроса для получения правильных изображений. милая плохое решение потому что вы можете выполнить DDos свое собственное приложение в часы с большим объемом трафика.
2) На мой взгляд и с моей точки зрения, папка / image / должна находиться в отдельном экземпляре или «что бы то ни было», чтобы ее можно было быстро использовать на каждом сервере, другими словами, на каждом отдельном веб-сайте. Есть ли какая-нибудь служба, которая может привязать 3 хотя бы веб-сервера в разных регионах? Ничего похожего пока не нашел.
По крайней мере, как вы думаете, есть ли какое-либо решение для проблемы "обмена изображениями"?
Был вопрос с чем-то похожим: Надежный обмен файлами но как я вижу и понимаю, его случай другой.
1) Запрос (например) /image/foo.png должен всегда возвращать один и тот же файл, независимо от того, к какому сайту осуществляется доступ, и независимо от того, в каком регионе.
2) Каковы географические привязки регионов: 3 разных континента. Итак, три разных «частных сети», если мы говорим о Digital Ocean, или три разных VPC, если мы говорим об AWS и т. Д.
3) Сколько там трафика: Трафик не имеет отношения к решению. Подумайте о большом увеличении объема трафика и запросов. Нет смысла иметь решение для низкого трафика и когда трафик удваивается + «проектировать его» или пытаться обновить CPU / RAM / STORARE-GB. Вот почему я предлагаю «локальный» балансировщик нагрузки для региона с «репликой» машины для распределения и обхода большого объема трафика.