SOA. Насколько детализированными должны быть сервисы для поддержания производительности?

Я берусь за проект по замене древней устаревшей системы с нуля. Прежде чем я пришел, компания наняла консультанта, который составил базовый набросок системы и активно продвигал SOA. Это привело к длинному списку «служб сущностей» с намерением составить из них более сложные комбинации услуг. Например, пользователь, которому нужна информация о комитете, обратится к службе «Комитет», которая затем вызовет службу «Лица», чтобы получить своих членов, и службу «Собрания», чтобы получить свои собрания, и так далее.

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

Для получения дополнительной информации: организация, запрашивающая это программное обеспечение, в настоящее время не имеет стабильной версии сторонних программных пакетов, с которыми необходимо интегрироваться. Это программное обеспечение заменит все наборы. Также в настоящее время нет внешних потребителей, которым требуется доступ к данным за пределами предоставленного интерфейса веб-сайта — все вызовы службы будут осуществляться из других частей нашей системы. Выбор SOA в этом случае кажется полностью основанным на понятии «подготовка».

Итак, мой вопрос: какой уровень детализации приемлем для стабильной службы без ущерба для производительности? Не слишком ли я скептически отношусь к ударам по производительности, которые мы получим при реализации всех наших сущностей в виде сервисов? Должны ли функциональные возможности быть доступны в виде веб-сервисов только тогда, когда они необходимы, с упором на «подготовку» вместо того, чтобы уделять внимание разработке бизнес-уровня с вероятностью того, что сервисы позже будут добавлены поверх него?


architecture web-services granularity soa
person roberttdev    schedule 01.04.2011    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Во-первых, найти «золотую середину» в количестве услуг, безусловно, сложно. Слишком много сервисов — и ваши затраты на интеграцию пострадают, слишком мало — и пострадают ваши затраты на внедрение. Вы должны найти хороший баланс.

Мой вам совет: следуйте методологии Джуваля Лоуи в том, что вы должны разбить свои услуги по областям волатильности или областям изменений. Это даст вам уровень детализации. Вы также должны прочитать его книгу WCF, если можете .

Что касается производительности, WCF по своей сути будет поддерживать многие тысячи вызовов в секунду в зависимости от ваших вариантов использования и оборудования. Службы вызова службы не проблема. Платформа поддержит его, если вы внесете свой вклад. Например, используйте правильную привязку для правильного сценария (именованные каналы для вызова служб на одном компьютере и TCP для вызова служб на разных компьютерах, где это возможно). Вы также должны реализовать вертикальный срез приложения и провести тестирование производительности, прежде чем создавать остальную часть приложения. Это проверит вашу архитектуру.

person BrandonZeider    schedule 01.04.2011
comment
Не могли бы вы указать мне, где в ссылке на методологию Юваля Лоуи я могу перейти, чтобы получить представление о фактической методологии? - person roberttdev; 01.04.2011
comment
К сожалению, в Интернете нет ни одного места, где можно было бы изучить его методологию. Для этого вам нужно пройти его мастер-класс архитектора. Что вы можете сделать, так это послушать эпизод .NET Rocks с его участием, прочитать его книгу о WCF и ознакомиться с его рекомендациями по WCF. Все эти ссылки можно найти на главной странице idesign.net в разделе "Ресурсы". - person BrandonZeider; 01.04.2011
comment
Не могли бы вы ответить на stackoverflow.com/questions/9538710/? - person LCJ; 02.03.2012

arrow_upward
3
arrow_downward

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

person Tayyab    schedule 01.04.2011
comment
Как насчет приведенного выше примера, где Person является теоретической службой? Он выполняет независимую бизнес-функцию по возврату всех данных, относящихся к человеку (имя, дата рождения, адреса и т. д.), но также является частью других бизнес-функций (возврат информации о комитете, возврат информации о доноре / пожертвовании, возврат кандидатов на работу и т. д.). ) - person roberttdev; 01.04.2011
comment
@ Тайяб - я не согласен. Если вы спроектируете свою систему таким образом, вы получите много дублированного кода или сильно связанное приложение. Хотя это, безусловно, работает, это больше ООП, чем SOA. В SOA потребители службы знают только о контракте службы, а не о базовой реализации. Например, если сервису необходимо создать экземпляр класса из DLL для выполнения своей работы, то он явно знает о реализации, а не только о контракте, и вы застряли, отправляя эту DLL каждой службе, которая в ней нуждается, когда бы она ни была. его реализация изменяется (сцепление). - person BrandonZeider; 01.04.2011
comment
На мой взгляд, у вас есть бизнес-объекты (человек, встречи и т. д.), и получение списка лиц не должно быть услугой. Вы называете это сервисом, когда он выполняет полный независимый бизнес-процесс. У вас могут быть повторно используемые объекты, такие как (человек, встречи и т. д.), и вы можете использовать эти объекты в нескольких службах, но взаимозависимость между службами не имеет смысла. Когда вы думаете об услугах, не думайте с точки зрения разработчика. Постарайтесь думать с точки зрения бизнес-аналитика, когда вы определяете, какой должна быть услуга. - person Tayyab; 01.04.2011
comment
@BrandonZeider: Ну, это отдельная дискуссия о внутренней реализации сервиса. А также иногда справедливо иметь явное знание какой-либо DLL для разработчика, который кодирует службу. Контракт службы предназначен для потребителя службы, и потребитель должен иметь возможность вызывать одну службу для задачи или процесса. Если потребителю приходится вызывать несколько служб для выполнения одной независимой задачи, вы просите потребителя иметь явные знания о вашем решении. - person Tayyab; 01.04.2011
comment
@Tayyab - помните, что службы также могут быть потребителями или клиентами других служб, и очень часто бывает, что служба высокого уровня требует вызова нескольких служб для выполнения своей задачи. Примером может служить служба регистрации. Метод Register() может вызывать UserService.Save(пользователь-пользователь), EmailService.SendNewUserNotification(пользователь-пользователь) и т. д. Затем UserService может вызывать еще больше служб для сохранения записи пользователя (User.Address, User.Contact и т. д.). Таким образом, хотя НАЧАЛЬНЫЙ потребитель может вызвать одну службу, эта служба может быть потребителем многих служб для выполнения своей задачи. - person BrandonZeider; 01.04.2011
comment
@BrandonZeider: Все дело в том, как вы воспринимаете SOA. Разные сообщества по-разному воспринимают SOA. Концепция, о которой вы говорите, относится к SOA некоторыми людьми из Microsoft, но лично я с ней не согласен. Я думаю, что это скорее компонентно-ориентированная архитектура, а не сервис-ориентированная архитектура. Я больше согласен с восприятием SOA сообщества Open Source, где сервис — это процесс, который автоматизирует какой-то бизнес-поток. Итак, из вашего примера я бы рассмотрел EmailService.SendNewUserNotification(User user) как часть службы уведомлений, но User - это просто бизнес-объект. - person Tayyab; 02.04.2011
comment
@BrandonZeider: В вашем примере также нет слабой связи. Существует синхронная связь между службой регистрации и службой пользователей. А также служба регистрации не может работать без сильной зависимости от службы пользователя, поэтому она не независима. - person Tayyab; 02.04.2011
comment
@Tayyab: Не знаю, почему мы все еще говорим об этом ... но ... мы можем не согласиться с определением SOA, с этим довольно часто не соглашаются, но мой пример слабо связан. Различные службы знают только о контракте службы, а не о реализации службы. Синхронизация/асинхронность не имеет ничего общего со связью, это просто деталь вызова потребителя. Я думаю, вы немного запутались. Та же история с зависимостью. Зависимость не равна связи. Независимо от того, как вы это реализуете (объекты или услуги), вы от чего-то зависите, но это не обязательно означает тесную связь. - person BrandonZeider; 02.04.2011
comment
@BrandonZeider: Ну, всегда приятно обсудить. Я бы порекомендовал вам взглянуть за пределы коробки Microsoft. Позвольте мне поделиться несколькими ссылками, даже если вы не хотите читать все, просто посмотрите.... blogs.sun.com/crupi/entry/soa_service_granularity - person Tayyab; 02.04.2011
comment
@BrandonZeider: И я не имею в виду, что служба не может вызывать другую службу. Могут быть составные службы, которые вызывают другие службы. Но мы не должны превращать все в услугу. Я просто говорю, что процесс регистрации — это услуга, НО пользователь — это сущность, а не услуга. В любом случае, я не хотел навязывать свои концепции вам или кому-либо... Просто мы согласны или нет, но дискуссия всегда хороша. - person Tayyab; 02.04.2011
comment
@Tayyab: Спасибо за ссылку, но она дает 404. У меня было несколько просмотров вне коробки Microsoft. У Microsoft прямо сейчас есть выигрышная рука с .NET (скорость внедрения в моем регионе, простота использования, функции и т. д.). И вы правы, мы не согласны с тем, что должно быть службами, потому что, используя WCF в качестве стека реализации, я поддерживаю каждый класс как философию службы, впервые предложенную Ювалем Лоуи. Я поместил все бизнес-функции/точки входа для извлечения данных в сервисы, что некоторых людей сильно пугает. ;) О, и пользователь ВСЕГДА был сущностью или DataContract, как это называется в WCF. - person BrandonZeider; 02.04.2011
comment
Извините, к ссылке добавлена ​​цитата, проверьте ее еще раз blogs.sun.com/crupi/entry /soa_service_granularity - person Tayyab; 02.04.2011
comment
@BrandnZeider: Да, вы правы, но я категорически не согласен с Microsoft, когда дело доходит до корпоративных решений... :) И, конечно же, у них лучшая среда разработки и простые в использовании компоненты, но это не делает их экспертами по архитектуре... Я Я читал Ювала Лоуи, и он тоже парень из Microsoft... Когда дело доходит до Enterprise, я выбираю Sun/Oracle, SAP и IBM.. Они правят... Может, это просто моя ненависть к Microsoft;) но я отчаянно хочу см. Opensource, выгоняющий Microsoft из Enterprise Business :) - person Tayyab; 02.04.2011

arrow_upward
1
arrow_downward

Какой уровень детализации приемлем для стабильной службы без ущерба для производительности?

Отдельные сущности. По описанию консультанта.

Не слишком ли я скептически отношусь к ударам по производительности, которые мы получим при реализации всех наших сущностей в виде сервисов?

да. Слишком скептически.

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

Как и в случае с базами данных SQL, проблемы в основном решены. Вы обнаружите, что базовые приложения, которые вы представляете как сервисы, являются узкими местами. Уровень SOA в значительной степени сантехнический. Биты по-прежнему должны перемещаться по каналам, уровень SOA просто организует их более разумно, чем большинство альтернатив.

Должны ли службы реализовываться только тогда, когда они необходимы, с упором на «подготовку» вместо того, чтобы переходить на проектирование бизнес-уровня с вероятностью того, что службы позже будут добавлены поверх него?

да.

Вот что значит Agile.

Найдите пользовательскую историю. Создайте только сервисы (и сущности) для этой истории.

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

Никогда не делайте обширной «подготовки» к вещам, которые вам «могут» понадобиться в каком-то невероятном будущем. Почитайте об Agile и о том, как расставить приоритеты в бэклоге.

person S.Lott    schedule 01.04.2011
comment
Я думаю, что вводил в заблуждение в своем вопросе «Должны ли службы реализовываться только тогда, когда они необходимы». Вопрос, который я хотел задать, заключался в следующем: разумно ли реализовывать для решения только объекты/сущности, не относящиеся к веб-службе, до тех пор, пока не возникнет явная потребность в веб-службе для этой функциональности? - person roberttdev; 01.04.2011
comment
ИМО, это зависит от того, как скоро вы хотите отправить... есть правильный способ делать вещи (к которому вы в конечном итоге можете стремиться) и способ, который быстро сделает всех счастливыми без дополнительной работы. - person Mr Shoubs; 01.04.2011
comment
Не могли бы вы ответить на stackoverflow.com/questions/9538710/? - person LCJ; 02.03.2012