Wyobraźmy sobie, że mamy system przetwarzania zamówień dla sklepu z pizzą do projektowania i budowy.

Wymagania są następujące:

R1. System powinien być agnostyczny dla klienta i użytkownika, co oznacza, że ​​klient może uzyskać dostęp do systemu, którego nie uwzględniono podczas początkowego projektu. Na przykład, jeśli sklep z pizzą zdecyduje, że wielu jego klientów korzysta później ze smartfonów Samsung Bada, napisanie klienta dla systemu Bada OS nie będzie wymagało przepisania API systemu i samego systemu; lub na przykład, jeśli okaże się, że korzystanie z iPadów zamiast urządzeń z systemem Android jest w jakiś sposób lepsze dla sterowników doręczeniowych, to łatwo byłoby stworzyć klienta iPada i nie wpłynie to w żaden sposób na API systemu;

R2. Możliwość ponownego użycia, co oznacza, że ​​system można łatwo zmienić, bez konieczności przepisywania dużej ilości kodu, jeśli proces biznesowy ulegnie zmianie. Na przykład, jeśli później pizzeria zacznie przyjmować płatności online wraz z przyjmowaniem gotówki przez kierowców dostawczych (przyjęcie płatności przed przyjęciem zamówienia VS przyjmującego płatność przy odbiorze), wówczas łatwo będzie dostosować system do nowego procesu biznesowego ;

R3. Wysoka dostępność i odporność na awarie, co oznacza, że ​​system powinien być online i powinien przyjmować zamówienia 24/7.

Aby więc spełnić R3, możemy użyć Erlang / OTP i mieć następującą architekturę:

Problem polega na tym, że ten rodzaj architektury ma wiele „zakodowanych na stałe” funkcji. Jeśli na przykład sklep z pizzą przejdzie od przyjmowania płatności gotówką przy odbiorze do przyjmowania płatności online przed złożeniem zamówienia, ponowne napisanie całego systemu i zmodyfikowanie interfejsu API systemu zajmie dużo czasu i wysiłku.

Ponadto, jeśli sklep z pizzą będzie potrzebował ulepszeń do swojego klienta CRM, ponownie musielibyśmy przepisać API, klientów i sam system.

Poniższa architektura ma na celu rozwiązanie tych problemów, a tym samym pomoc w spełnieniu R1, R2 i R3:

Każda „usługa” w systemie jest serwerem Webmachine z interfejsem API RESTful. Takie podejście ma następujące korzyści:

cała dobroć Erlang / OTP, ponieważ każda Webmachine jest aplikacją Erlang, która może być nadzorowana i może być umieszczona w wydaniu Erlang;architektura zorientowana na usługi ze wszystkimikorzyści SOA;łatwy do dostosowaniazmiany w procesie biznesowym;łatwe dodawanie nowych klientów i nowych funkcji do klientów (np. do klienta CRM), ponieważ klient może korzystać z RESTful API wszystkich usług w systemie zamiast jednego „centralnego” API (możliwość kompilacji usług w zakresie SOA).

Tak więc zasadniczo architektura systemu zaproponowana na drugim zdjęciu to architektura zorientowana na usługi, w której każda usługa ma API RESTful zamiast umowy WSDL, a każda usługa jest aplikacją Erlang / OTP.

A oto moje pytania:

Rysunek 2: Czy próbuję tu odkryć koło? Czy powinienem po prostu trzymać się czystej architektury Erlang / OTP? („Pure Erlang” oznacza aplikacje Erlang upakowane w wydaniu, rozmawiające ze sobą za pomocą gen_server: call i gen_server: wywołania funkcji cast);Czy możesz wymienić jakiekolwiek wady w proponowanym podejściu? (Zdjęcie 2)Czy uważasz, że łatwiej byłoby utrzymać i rozwijać (R1 i R2) taki system (Rysunek 2) niż prawdziwie Erlang / OTP?Problemem może być bezpieczeństwo takiego systemu (Rysunek 2), ponieważ istnieje wiele punktów wejścia otwartych dla sieci (RESTful API wszystkich usług) zamiast tylko jednego punktu wejścia (Rysunek 1), czyż nie?Czy można mieć kilka „modułów orkiestrujących” w takim systemie, a może istnieje lepsza praktyka? („Akceptuj zamówienia”, „CRM” i „Zamówienia wysyłkowe” na Zdjęciu 2);Czy czysty Erlang / OTP (Rysunek 1) ma przewagę nad tym podejściem (Rysunek 2) pod względem przekazywania komunikatów i ograniczeń protokołu? (częściowo omówione w moim poprzednim podobnympytanie, gen_server: wywołanie VS HTTP RESTful)