Чего лучше избегать при разработке архитектуры?

 

В последнее время я много работаю над распределенной кластерной веб-системой, и в ходе работы уяснил для себя несколько моментов, которыми с радостью поделюсь. Всё нижеследующее добыто кровью, потом и потерянной прибылью…

Не полагайтесь на стабильность

“Это же элементарно!” – скажете Вы. И я соглашусь, мне тоже это было известно с самого начала. Но в процессе разработки и внедрения судьба не раз ударяла меня об этот угол. Любой вменяемый разработчик обязательно включит в состав распределенного решения средства восстановления/повтора. Отсутствие компонентов, ответственных за стабильность, может иметь далеко идущие последствия.

 

К примеру, представим себе сервер на 100-мегабитном канале, выполняющий 50 одновременных задач. Вы настроили систему на выполнение 50 задач и расслабились. На следующий день сетевой провайдер срезал скорость вашего канала со 100 до 10 мегабит. И всё! Сервер начинает медленно помирать…

Или другой пример (структурная проблема, знакомая мне по сетевым библиотекам). Представьте, что у вас есть реестр сетевых служб, используемый компонентами кластера для получения адресов нужных служб. Всё прекрасно, кроме того, что все узлы кластера проверяют связь друг с другом и имеют возможность удалять записи о неработающих серверах. Но это реальный мир…

Например, у нас 4 сервера: A, B, C и D. Узел D пытается пинговать узел A и не может до него достучаться. Что в таком случае он сделает? Уничтожит запись об узле А в реестре узла. Но отсутствие пинга еще не означает, что сервер не работает! Оно просто означает, что D не может связаться с А. Другие узлы (В и С) могут по-прежнему работать с А без проблем. Но теперь, когда узел D удалил из реестра информацию об А, ни один из узлов не сможет работать с А. Главной ошибкой здесь является предположение о том, что связь A-D идентична по свойствам связям А-В и А-С.

Так что будьте начеку. Не возлагайте ложных надежд на стабильность и свойства. Намного лучше сделать систему гибкой.

Не полагайтесь на систему DNS

Это дальнейшее развитие предыдущей идеи. Система DNS уже довольно стара, и её слабые места общеизвестны. В большинстве случаев сервера DNS используют UDP, что порождает проблемы с надёжностью. Даже если никому не нужно атаковать ваш DNS-сервер, он может стать источником неприятностей из-за потерь в UDP-пакетах, и т.д.

Но главным риском является распределенная сущность DNS. В большинстве случаев её невозможно контролировать полностью. Есть и сервер TLD, и DNS-сервера датацентра, и сервер регистратора доменных имен, и ещё много элементов. В случае возникновения проблем у вас может уйти не один день только на то, чтобы связаться с ними всеми и выяснить, что происходит.