Архитектура Erlang/OTP :Протокол RESTful для сервисов SOAish
Давайте представим, что у нас есть система обработки заказов для пиццерии, которую нужно спроектировать и построить.
Требования:
Р1. Система должна быть клиентской -и использовать -case -агностическую, что означает, что клиент может получить доступ к системе, что не учитывалось при первоначальном проектировании. Например, если пиццерия решит, что многие ее клиенты будут использовать смартфоны Samsung Bada позже, то написание клиента для ОС Bada не потребует переписывания API системы и самой системы; или, например, если выяснится, что использование iPad вместо Android-устройств как-то лучше для драйверов доставки, то будет легко создать iPad-клиент и это никак не повлияет на API системы;
Р2. Возможность повторного использования. Это означает, что систему можно легко перенастроить без необходимости переписывать большой объем кода в случае изменения бизнес-процесса. Например, если позже пиццерия начнет принимать платежи онлайн наряду с приемом наличных водителем-курьером (, принимающим оплату до принятия заказа, VS приемом оплаты при доставке ), то будет легко адаптировать систему к новый бизнес-процесс;
Р3. Высокая -доступность и отказоустойчивость -, что означает, что система должна быть онлайн и принимать заказы 24/7.
Итак, чтобы соответствовать R3, мы могли бы использовать Erlang/OTP и иметь следующую архитектуру:
Проблема здесь в том, что в такой архитектуре много «жестко закодированных» -функций. Если, например, магазин пиццы перейдет от приема наличных платежей при доставке к приему онлайн-платежей до размещения заказа,тогда потребуется много времени и усилий, чтобы переписать всю систему и изменить API системы.
Более того, если пиццерии потребуются какие-то доработки CRM-клиента, то опять же придется переписывать API, клиентов и саму систему.
Итак, следующая архитектура направлена на решение этих проблем и, таким образом, на соответствие R1, R2 и R3 :
. Каждая «служба» в системе представляет собой веб-сервер Webmachine с RESTful API. Такой подход имеет следующие преимущества:
- все преимущества Erlang/OTP, поскольку каждая веб-машина представляет собой приложение Erlang, за которым можно наблюдать и которое можно включить в выпуск Erlang;
- сервис-ориентированная архитектура со всеми преимуществами SOA;
- легко адаптируется к изменениям в бизнес-процессе;
- легко добавлять новых клиентов и новые функции для клиентов (, например. клиенту CRM ), так как клиент может использовать RESTful API всех сервисов в системе вместо одного «центрального» API (Компонуемость сервисов с точки зрения SOA ).
Таким образом, системная архитектура, предложенная на втором рисунке, представляет собой сервис-ориентированную архитектуру, в которой каждый сервис имеет RESTful API вместо WSDL-контракта и где каждый сервис представляет собой приложение Erlang/OTP.
А вот и мои вопросы:
- Picture 2 :Пытаюсь ли я заново изобрести велосипед? Должен ли я вместо этого просто придерживаться чистой архитектуры Erlang/OTP? («Чистый Erlang» означает приложения Erlang, упакованные в релиз, взаимодействующие друг с другом через вызов gen _server :и вызов gen _server :приведения );
- Какие недостатки в предложенном подходе вы можете назвать? (Изображение 2)
- Как вы думаете, было бы легче поддерживать и расширять (R1 и R2 )систему, подобную этой (Рисунок 2 ), чем действительно Erlang/OTP?
- Безопасность такой системы (Рисунок 2 )может быть проблемой,так как есть много точек входа, открытых для Интернета (RESTful API всех сервисов )вместо одной точки входа (Рисунок 1 ), не так ли?
- Можно ли иметь в такой системе несколько «инструментальных модулей» или, может быть, существует какая-то лучшая практика? (Сервисы "Прием заказов", "CRM" и "Отправка заказов" на Рисунке 2 );
- Есть ли у чистого Erlang/OTP (Picture 1 )какие-либо преимущества перед этим подходом (Picture 2 )с точки зрения передачи сообщений и ограничений протокола? (частично обсуждалось в моем предыдущем подобном вопросе , gen _сервер :вызов VS HTTP RESTful вызовы)