Производительность SOA в webapp

Question

Я борюсь с решением между традиционным бэкэнд (скажем, экземпляром Django, управляющим всем) и сервис-ориентированной архитектурой для веб-приложения, похожего на LinkedIn. То, что я имею в виду с SOA, имеет полностью независимый интерфейс доступа к данным - скажем, Ruby + Sinatra - запрашивает базу данных, независимое приложение чата - Twisted - которое используется через его API, веб-сервер Django, который использует эти API для обслуживания контент и т. д.

Я вижу преимущества наличия всего в проекте модульного и доступного только через API: масштабируемость, тестирование и т. д. Однако, это не подорвало бы производительность сайта? Я предполагаю, что все модули будут связываться через HTTP-запросы, поэтому не будет ли эта архитектура добавить много латентности в основном все на сайте? Есть ли более эффективная альтернатива, чем HTTP?

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

Edit: Мы небольшая команда из двух разработчиков и дизайнер, но у нас нет сроков, чтобы мы могли обработать немного дополнительной работы, если она приносит более техническую ценность

Answer 1

Короткий ответ, да, SOA определенно торгует инкапсулированием и повторным использованием для латентности. Длинный ответ, это зависит (как это всегда бывает) от того, как вы это делаете.

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

Есть альтернативы HTTP, но если вы собираетесь использовать что-то настроенное, вам нужно спросить себя, почему вы вообще используете службы? Почему бы вам просто не использовать библиотеки и полностью избежать сетевого уровня?

Вы, безусловно, добавляете затраты и сложности в свой проект, начиная с API. Это должно уравновешиваться гибкостью, предоставляемой API. Это может быть ситуация, когда вам будет выгодно внутреннее структурирование API-интерфейсов на вашей базе кода, но просто вызывать их как модули. Или создавать библиотеки вместо автономных API.

Многое зависит от того, насколько велик ваш проект. Вы команда из 1-3 разработчиков, которые выходят из своего MVP? Или вы - предприятие с 20-100 разработчиками, которые все должны выяснить, как разделить проект, не наступая друг на друга?