Будущий проверяющий код клиент-сервер?

Question

У нас есть веб-клиент-серверный продукт. Ожидается, что клиент будет использовать свыше 1 млн пользователей (его будет использовать известная компания).

Наш сервер настроен в облаке. Один из главных вопросов при разработке - как сделать всю программу будущей. Скажи:

1. Облачный провайдер отключается, затем автоматически переходит к резервному копированию в другом облаке
2. Переход на другой сервер и т. Д.

Варианты, которые мы думали до сих пор:

1. DNS: запуск DNS-сервера имен в облаке самостоятельно.
2. Сервер каталогов - сервер каталогов также находится в облаке
3. Пусть наш сервер будет возвращать клиенту будущие перемещения и будущие URL-адреса и т. Д., Причем клиент специально предназначен для обработки этих сценариев

Так как это должно быть обычной проблемой, какое же решение лучше? Поскольку наша компания очень маленькая, мы ищем наименее технически и финансово дорогое решение (скажем, вариант 3 и т. Д.)?

Может ли кто-нибудь предоставить несколько указателей на то же самое?

K

Answer 1

Re. DNS: запросы могут кэшироваться, и изменения могут распространяться самостоятельно (от часов до дней).

Я бы пошел за списком приоритетных IP-адресов, которые можно обновить на клиенте. В случае сбоя одного IP-адреса клиент повторяет попытку со вторым, третьим и т. Д.

Answer 2

Я не уверен, что на 100% понял ваш вопрос, но если я это сделаю, это сводится к следующему: если мой сервер перемещается, как мои клиенты могут найти его?

Именно это и сделал DNS почти за последние три десятилетия.

Каждая возможная система, которую вы можете выбрать, должна быть загружена с начальными рабочими данными: адрес для сервера каталогов, адрес рабочего сервера для получения обновленного списка адресов и т. Д. Для этого нужны корневые DNS-серверы и ОС поставщики сделают для вас загрузочную часть.

Конечно, DNS-запросы могут кэшироваться, вот как это должно работать и как он масштабируется до размера Интернета. Вы управляете кэшированием (читайте о TTL) и обычно можете поддерживать его на нормальных значениях (не имеет смысла сокращать его до абсолютного минимального времени, необходимого для повторного развертывания сервера в другом месте).

Answer 3

Я бы выбрал опцию сервера каталогов. Он наиболее гибок и дает вам максимальный контроль над тем, что происходит в данной ситуации.

Чтобы избежать превращения самого каталога в единую точку отказа, у меня было бы три или четыре из них, работающих в разных местах с разными провайдерами. Пусть клиентское приложение случайным образом выберет один из URL-адресов директории при запуске и проработает их все, пока не найдет тот, который работает.

Чтобы сделать его действительно перспективным для будущего, вам, вероятно, понадобится простой протокол для динамического обновления списка серверов каталогов, но будьте осторожны, если он плохо реализован, вы оставите своих клиентов открытыми для всевозможных атак со спуфингом.