основанная на услугах архитектура не обязательно должна подразумевать распространение?

Question

На моем рабочем месте (и во многих других областях) большое внимание уделяется построению архитектуры вокруг сервисов. (Я работаю в стартапе электронной коммерции). Тем не менее, я думаю, что сервисы неявно рассматриваются как распределенные. Я сторонник первого закона распределения - «не распространяй». Поэтому я считаю, что мы не должны обязательно усложнять архитектуру. Это должна быть архитектура, которая может развиваться. Таким образом, одним из способов решения этой проблемы было бы создание четко определенных пространств имен и создание кода вокруг него, но поддержание связи с помощью Java API. (это снижает требования к мониторингу, а проблемы с надежностью / доступностью остаются низкими). Это может быть легко преобразовано в распределенную архитектуру путем включения модулей в веб-сервис, когда и когда требования к масштабированию вступают в силу. Итак, вопрос в том, каковы же преимущества написания кода в виде единого приложения и превращения в распределенные сервисы, а не прямой переход к реализации архитектуры на основе веб-сервисов? Прав ли я, предполагая, что сервисы должны подразумевать базовые принципы проектирования (абстракция, инкапсуляция и т. Д.), А не распространение по сети?

Answer 1

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

Например, в однопроцессной системе электронной коммерции у вас могут быть отдельные модули для управления корзиной покупок пользователя и расчета цен. Они могут взаимодействовать с корзиной, прося калькулятор оценить цену товара, затем другой товар и т. Д. Это было бы прекрасно.

Однако в распределенной системе это потребует потока небольших вызовов методов, что неэффективно; это может сойти с рук, если вы будете использовать CORBA для распространения, но с SOAP у вас будут проблемы. Скорее, вы хотите, чтобы корзина попросила калькулятор оценить весь заказ за один раз. Это может быть хуже с точки зрения разделения проблем (почему калькулятор должен знать об идее тележек?), Но для обеспечения адекватной работы системы потребуется

В связи с гранулярностью существует также проблема взаимодействия модулей через интерфейсы или реализации. С помощью одного процесса вы можете определить набор интерфейсов, через которые будут взаимодействовать модули; модули могут передавать друг другу объекты, реализующие эти интерфейсы, без необходимости сообщать друг другу о реализациях (например, модуль планировщика может передавать все, что реализует interface Job { void run(); }). Во всей сети требование грубого зерна означает, что любые передаваемые объекты должны передаваться по значению (потому что передача по ссылке повлечет за собой детальные вызовы обратно в модуль передачи - если только вы не использовали мобильный код, которым вы не являетесь, потому что никто не), что означает, что оба модуля должны знать и согласовывать реализации объектов.

Таким образом, хотя модульное построение однопроцессной системы облегчает последующее внедрение SOA, оно не делает ее такой простой, как упаковка каждого модуля в интерфейс SOAP. По крайней мере, до тех пор, пока вы с самого начала не построите свою систему в общих чертах, что означает отказ от целого ряда полезных и полезных методов разработки программного обеспечения.