Каковы некоторые хорошие ресурсы для разработки архитектуры веб-сервисов, которая может масштабироваться хорошо?

Question

У меня есть веб-приложение, в котором в настоящее время насчитывается около 500 000 пользователей, в среднем около 500 просмотров страниц в час, и мы ожидаем, что в следующем году ожидается увеличение до 20 000 000 пользователей.

Наша текущая система не может справиться с этой шкалой, и поэтому нам нужно перейти к одной, которая может.

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

Но я был предупрежден о том, что можно легко разработать архитектуру служб, которая не масштабируется хорошо, и поскольку у меня мало опыта проектирования такой системы, переходы по некоторым рекомендуемым ресурсам, вероятно, лучше, чем просто «принятие ударь на него ».

Итак, какие ресурсы рекомендуется для архитектуры системы масштабирования? Платформа .Net, но я бы предположил, что такая же информация относится к любой сервис-ориентированной архитектуре, независимо от платформы.

Answer 1

Я бы сначала ответил на комментарий Геннадия Шумахера - «В настоящее время вы рассматриваете, как вы не масштабируемы?». Как только вы это знаете, вы можете подойти к нему конкретно, а затем все приложение, как вам нужно.

Одно интересное исследование - Twitter. Это началось с небольшого количества запросов, но быстро превратилось в сильно используемую платформу с мировым трафиком. This может оказаться полезным. Также интересным может быть этот blog on scalability.

Answer 2

Теоретически он масштабируется, но вам нужно быть осторожным с задержкой. Скажем, вы используете внешний модуль, теперь у вас есть две службы, которые служат вместо одного, но в то время, когда требуется отправить, обработать, ответить на один запрос на внешнюю службу, вы могли бы обработать 100 внутренних запросов, поэтому, если у вас нет 100 серверов, вы фактически получаете более низкую пропускную способность, но в любом случае вы платите гораздо больше за обслуживание и пространство со 100 серверами против 1. Обычно баланс должен быть измерен между задержкой и обработкой, как правило, если вам нужно отправить много данных, вам может быть лучше не отделять этот шаг от службы. К счастью, у вас есть работающая система, против которой вы измеряете кабину, большинству людей приходится оценивать это только по спецификациям.

Так что рассмотрите ваши модели потока данных и пользуйтесь местностью, это искусство сократить ваше приложение на услуги вдоль зерна, а не против него.

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

Answer 3

Я бы рекомендовал Ebay architectural principles presentation, а также хороший writeup на презентации. Фактически Ebay принял типичный подход, ориентированный на обслуживание. Услуги извлекаются функциями, поэтому каждая служба может масштабироваться независимо. Я думаю, что есть некоторые хорошие моменты, о которых вы можете узнать.