Какова стандартная практика для создания веб-страницы с услугами

Question

Я много слышал о преимуществах SOA, сервисов и т. Д. Но я не понимаю, как это можно сделать с хорошей производительностью.

У меня есть веб-страница с функциями социальных сетей и рекламными объявлениями. Большая часть моего кода запутана, но я думаю, что рекламные объявления и функции «рекомендуемых друзей» довольно независимы, идеально подходят для подхода, подобного SOA.

Я могу создать API уровня HTTP REST для этих двух служб и затем вызывать каждый запрос страницы моего основного сайта.

Я не хочу, чтобы пользователи слишком долго ждали загрузки страницы, если в моем запросе я получаю кучу данных (например, рекомендуемый идентификатор пользователя), которые мне нужно обработать или найти в связанных данных и т. Д. Я чувствую, что что-то делаю медленнее без реальной выгоды. Относительно медленный HTTP-вызов, чтобы получить что-то, что я только что обработал бы локально. Я только что переместил свою обработку на другую сторону медленного HTTP-запроса.

Единственная другая опция, которую я вижу, это toput iframes в моих html-шаблонах, где их src указывает на эти внешние сервисы. Эти сервисы будут возвращать напрямую HTML. При этом загрузка идет параллельно.

Говорят, что типичная страница amazon создана из 150 сервисов, я не вижу там 150 фреймов, как они это делают и получают низкие задержки?

Answer 1

Кажется, что в вопросе есть некоторое смешение терминов. Во-первых, SOA - это не просто создание сервисов (в данном случае веб-сервисов) для предоставления данных. Это довольно сложная архитектурная концепция (в соответствии с DDD, MVC и т. Д.), Которая включает в себя превращение вашего приложения в серию сервис-ориентированных уровней, на которых выполняются и обслуживаются запросы. Таким образом, вместо того, чтобы иметь большие графы объектов, поддерживающие набор бизнес-процессов, вы получаете набор относительно элементарных команд, которые приводят к довольно прямолинейному взаимодействию с вашей общей моделью. Одним из больших преимуществ этой архитектуры является то, что она достаточно хорошо масштабируется. Вместо того, чтобы постоянно пересматривать свою модель и вводить новые команды / рабочие процессы, вы можете создавать новые наборы сервисов.

Все, что было сказано, сервисные звонки довольно дешево. Подумайте о стоимости звонка в сервис (1к? 2к? Меньше?) По сравнению с полным постбэком или запросом веб-страницы (70к? 100 + к?). Если вам требуется полная публикация и перенаправление для каждой команды на странице, вы рассчитываете на довольно высокую стоимость с точки зрения пропускной способности и производительности , если ожидаете много трафика. Системы, созданные такими компаниями, как поскольку Yahoo и Google извлекают огромную выгоду, разбивая задачи на ряд команд, которые выполняются асинхронно после , страница загружается для сокращения ожидаемого времени ожидания и общего сетевого трафика.

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

Это правильный путь? Это зависит от вас. Если то, что у вас работает, придерживайтесь этого. Если стоит потратить время и силы на внедрение более сложного решения, потому что существует активная и ощутимая деградация производительности, вызванная вашей текущей архитектурой, то, возможно, вам следует подумать об изменении.