Чтобы ответить на вопрос OP, вы могли бы сказать, что сегодня эквивалентный документ посвящен не оптимизации загрузки одного сервера, а оптимизации всего вашего онлайн-сервиса под нагрузку.С этой точки зрения, количество комбинаций настолько велико, что вы ищете не документ, а живой веб-сайт, который собирает такие архитектуры и структуры.Такой веб-сайт существует, и он называется www.highscalability.com
Примечание 1:
Я бы поспорил с верой в то, что выбрасывать больше оборудования - это долготермин решение:
Возможно, стоимость инженера, который "получает" производительность, высока по сравнению со стоимостью одного сервера.Что происходит, когда вы уменьшаете масштаб?Допустим, у вас есть 100 серверов.10-процентное увеличение производительности сервера может сэкономить вам 10 серверов в месяц.
Даже если у вас всего две машины, вам все равно придется обрабатывать скачки производительности.Разница между услугой, которая постепенно изнашивается под нагрузкой, и услугой, которая выходит из строя, состоит в том, что кто-то потратил время на оптимизацию для сценария загрузки.
Примечание 2:
Темаэтого поста немного вводит в заблуждение.Документ CK10 не пытается решить проблему 10 тыс. Клиентов в секунду.(Количество клиентов в секунду не имеет значения, если вы не определяете рабочую нагрузку наряду с устойчивой пропускной способностью при ограниченной задержке. Я думаю, что Дэн Кегель знал об этом, когда писал этот документ.).Взгляните на это как на сборник подходов к созданию параллельных серверов и микропроцессоров для них.Возможно, что изменилось с того времени до настоящего момента, так это то, что в какой-то момент вы могли предположить, что сервис предназначен для веб-сайта, который обслуживает статические страницы.Сегодня эта служба может быть хранилищем данных NoSQL, кешем, прокси-сервером или одной из сотен частей программного обеспечения сетевой инфраструктуры.