Komponentowe i rozproszone Kompozycja gui Cap theorem Wydajne Systemy Rozproszone CQRS

Czym serwis nie jest Serwis, który dostarcza tylko funkcjonalność a nie posiada stanu jest funkcją  Np walidacja Serwis, który tylko posiada i udostępnia dane jest bazą danych  CRUD

Co to jest serwis? Serwis jest techniczną realizacją pewnych biznesowych możliwości. Serwis powinien być niezależny. Czy to znaczy, że musi przechowywać (niekoniecznie być właścicielem) wszystkie dane i reguły niezbędne mu do działania Jakie powinny być "granice serwisu"?

Przykład Subscribe to Customer Status Updated Publish Customer Status Updated Save status locally Subscribe to Product Pricing Updated Publish Product Pricing Updated Save pricing locally Place Order Publish Order Accepted Sales Marketing Customer Care

Zdarzenia w przykładowym systemie Otrzymanie zamówienia Wystawienie faktury Wysyłka towaru Uzupełnienie magazynu Zmiana Ceny

Jaki serwis jest właścicielem strony?

Żaden

Kompozycja strony (w przeglądarce) Gateway/Firewall+LB Katalog Koszyk Licytacja Cross Sell Spedycja Zdjęcia/Media Server Server Server Server

Kompozycja strony (na serwerze) Server Katalog Koszyk Licytacja Cross Sell Spedycja Zdjęcia/Media

Proces sprzedaży Jaki serwis jest właścicielem procesu sprzedaży? Żaden

Posadowienie serwisów Jeden komputer może gościć wiele serwisów Jedna aplikacja może obejmować wiele serwisów Pojedynczy workflow może angażować wiele serwisów Pojedyncza strona może łączyć dane z wielu serwisów

Proces sprzedaży

Który serwis odpowiada za proces?

Żaden

Składowe workflow-u Spedycja Rachunkowość Spedycja Rachunko wość Sprzedaż Sprzedaż

CAP theorem Nie można zbudować systemu, który spełni jednoczesnie 3 postulaty: Spójność (Consistency) Dostępnośc (Availiability) Odporność na podziały (Partition tolerance)

CAP theorem Mozna wybrać 2 CA – Brak podziałów oznacza monolit CP – Spójny, ale pot. niedostępny w przypadku problemu z wewn. transmisjami AP – Dostępny, ale potencjalnie lokalnie niespójny – Eventual Consistency

AP – przykład 1: Request/Response Sprzedaz Uprawnienia Zarządzanie klientami Ostatnia ver. upr. Cache

AP – przykład 2 : Pub/Sub SprzedazMarketing Zaakceptowana transakcja klienta X wolumen zaku- pów klienta X Kod zniżkowy na przesyłkę dla stałych klientów spedycja Zaakceptowana transakcja klienta X

Współpraca wielu użytkowników Pobranie danych Zmiana danych Użytkownik widzi stare dane

Cache = efektywność+problemy DB Cache

Zapytania Cache = efektywność+problemy

Dane zmieniają się często Dane poprawne 10 minut temu Lista klientów Można to pokazać ex-plicite: Twitter, Facebook

Zapytania powinny być proste Normalizacja implikuje zapytania oparte na wielu tabelach Widoki kosztują Persistent View Model UIUI Query only

Command Query Responsibility Segregation

CQRS Komendy są przetwarzane oddzielnie od zapytań Wynik aktualizacji danych jest replikowany do widoku zapytań (cache) Możliwe jest w przechowywanie tylko listy komend i bieżącego stanu w cache CQRS – to nie jest wzorzec wysokopoziomowy

Ale co zrobić z nieaktualnymi danymi w cache-u Co jeżeli do generowana update-u użyte zostaną niektualne dane Orders CancelCancelSaveSave OrderTotalPaymentShippedCustomerConfirmed IDAmountReceivedDateID 321$ Yes 322$ No 323$ Yes 324$ Yes

Nowoczesny interfejs Może wcale nie trzeba korzystać z nieaktualnych danych lub nie trzeba ich pokazywać Ważne jest uchwycenie intencji Można troche “oszukać”  Wysyłka może pójść na adres, który był aktualny kilka minut wcześniej  Nie można oczekiwać, że zawsze uda sie rezygnacja z wysyłki w ciagu kilku sekund  Właściwy zakup udbywa sie przy potwierdzeniu a nie kliknieciu "kup teraz"

System rezerwacji

Tradycyjne podejście Checkbox-y Problemem mogą wyścigi jesli kilka osób spróbuje zarezerwowac nakładające sie obszary Po co użytkownikowi kilka miejsc? Bo chce zarezerwowac miejsca obok siebie dla rodziny/przyjaciół

Uchwycenie intencji użytkownika Rezerwacja grupowa:  Mała grupa – siedzi razem  Duża grupa – kilka małych grup Podaj liczbę miejsc Podaj typ miejsc – określa koszt Propozycja z czasowym ograniczeniem – wymaga potwierdzenia/płatności

System rezerwacji

Drobne optymalizacje i oszustwa Walidacja przed wysłaniem Odgadywanie zmian Bezpośrednia aktualizacja widoku na podstawiwie komendy przed wprowadzeniem i przetworzeniem zmian przez BackEnd)

Komenda vs. encja Łatwiej walidować komendę  z mała iloscią danych  bardziej konkretną  Chodzi o potencjalną poprawność (wynik walidacji nie jest ostateczny) Walidacja dużych encji jest trudna