Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Komponentowe i rozproszone Systemy rozproszone. System aplikacja Aplikacja: jeden proces, jeden system op., jeden komputer System: wiele procesow, (zwykle)

Podobne prezentacje


Prezentacja na temat: "Komponentowe i rozproszone Systemy rozproszone. System aplikacja Aplikacja: jeden proces, jeden system op., jeden komputer System: wiele procesow, (zwykle)"— Zapis prezentacji:

1 Komponentowe i rozproszone Systemy rozproszone

2 System aplikacja Aplikacja: jeden proces, jeden system op., jeden komputer System: wiele procesow, (zwykle) wiele systemów op. i wiele komputerów System = N*aplikacja => połączenia

3 Połączenia nie są bez znaczenia … Typowe założenia deweloperów (i architektów) dla systemów rozproszonych: Sieć jest niezawodna Opóźnienia nie są problemem Pasmo nie jest problemem Sieć jest bezpieczna Topologia się nie zmienia Administrator zawsze wie co robić Koszty transportu danych nie są problemem Sieć jest jednorodna Deutsch 94 Gosling 97

4 Połączenia nie są bez znaczenia … Typowe założenia deweloperów (I architektów) dla systemów rozproszonych: … System jest atomowy/monolityczny System jest skończony Logika biznesowa może (i powinna) być scentralizowana Neward 06

5 3 wymiary systemu Scalability Availiability Reliability

6 Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn Przykładowy sklep

7 Przykładowa funkcjonalność

8 Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn

9 A gdzie są dane?

10 Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn

11 Klienci Transakcje Towary Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn Może być gorzej?

12 To była tylko jedna akcja … Są i inne: Raporty Przeceny Przyjecie nowych towarów Wysyłka Zwroty i reklamacje * Liczba użytkowników

13 Podejście synchroniczne – powoli, ale przynajmniej działa Procesy głównie czekają na wyniki/zasoby/potwierdzenie Deadlock/problemy w jednym podsystemie może zdegradować cały system Lepszy sprzęt często oznacza, że poświęcamy więcej cykli (szybszego) procesora na czekanie Timeout – powoduje ponowienie żądania (a stare może być jeszcze przetważane) System działa w developmencie a w produkcji (od razu lub nie) całość pada

14 Podejście synchroniczne - czasem nie działa … Maintenance/awaria jednego serwera może spowodować zatrzymanie całego systemu Przenosimy serwer - Jak np. zmienić adresację w sieci? Skalujemy system – jak dodać drugą instancję serwisu magazyn? Co z utrzymywaniem starych wersji ?

15 Zależności Utrudniają development Utrudniają wdrażanie Ograniczają stabilność Utrudniają zarządzanie i utrzymanie Nie można ich wyeliminować ale trzeba je ograniczać...

16 Zależności (coupling) w kodzie Powiązanie wynika z zalezności Wywołanie funkcji zalęzy od sygnatury czyli kod wywołujacy zależy od definicji funkcji Miary zależności w kodzie Ca – liczba klas (funkcji), które zależą od danej klasy (funkcji) Ce - liczba klas (funkcji), od których zależy dana klasa (funkcja)

17 Zależności (coupling) w systemach Platformowe (protokół, format – interoperability) Czasowe (żądanie - odpowiedź) Przestrzenne (adresy – identyfikacja)

18 Kilka scenariuszy Zmiana szczegółów implementacyjnych serwisu Zmiana (deplyment) komponentu od którego zależy wiele serwisów Upadek bazy = timeout + utrata danych Deadlock = rollback transakcji Upadek serwisu = blad przy wywołaniu

19 Redukcja powiązań... jest złożona Efferent Afferent Platformowe Czasowe Przestrzenne

20 Jak ? Ca, Ce – zależności w kodzie, SOA – opieramy się na kontraktach Platformowe – użycie XML Przestrzenny – wirtualne endpointy, routowanie (np. po typie komunikatu) Czasowe – asynchroniczne komunikaty

21 Wołanie synchroniczne Tradycyjne WS, RPC, COM, WCF (?) Serwis A Wołanie synchroniczne czekanie praca zwrot Serwis B

22 Wołanie asynchroniczne Typowa implementacja tworzy nowy wątek, który czeka synchronicznie i wykonuje callback (w swoim kontekście) Wątek główny i tak czeka na wyniki (ale może ew. uruchomić kilka zapytań)

23 Wołania jednokierunkowe ASP.NET: oneway WCF: IsOneWay=True Kolejki

24 Wołania jednokierunkowe ASP.NET: oneway WCF: IsOneWay=True Kolejki Serwis Klient Id Odpowiedź: ekspozycja interfejsu przez klienta pooling w oczekiwaniu na odpowiedź Wysyła i pracuje dalej

25 Podejście request response (synch lub asynch) Możliwe problemy

26 Upadek serwera DBDB AppApp [HTTP] $$ OrderTxTx Call 1 of 3 Call 2 of 3 Krytyczny update dla Windows Rollback Co sie dzieje z zamówieniem ?

27 AppApp [HTTP] $$ Order TxTx Baza jest wyłączona Exception Zapis do logu DBDB Call 1 of 3DownDown Co sie dzieje z zamówieniem?

28 TxTx AppApp [HTTP] $$ Order Gdy przydarzy sie deadlock DBDB Call 1 of 3DeadlockDeadlock Exception Zapis do logu AB Call 2 of 3 Co sie dzieje z zamówieniem ?

29 TxTx Co zmiania messaging? QQ $$ OrderAppApp Receive DBDB Call 1 of 3 Rollback Call 2 of 3 Rollback Zamówienie wraca do kolejki

30 Wołania usług vs. messaging ABCD WSWS DBDB [HTTP] Invoke $$ OrderDeadlockDeadlock Rollback Nie można wycofać

31 Wołania usług vs. messaging MessagingGateway ABCD WSWS MsgDBDB $$ Order [HTTP] Invoke Przy błędzie komunikat nie zostanie wysłany

32 Wzorzec: Adres zwrotny Oddzielny kanał dla odpowiedzi Addres zwrotny Serwis B Addres zwrotny Kiedyś w przyszłości Serwis A

33 Adres zwrotny jest ważny Service B Server 2 Service A Server 1 Request 0 Request 1 Service A Server 3 Response 1 Pozwala na równoważenie obciążenia Iub utworzenie potoku obsługujacego zlecenia

34 Skorelowane Request/Response Serwis B Kiedyś w przyszłości Serwis A Ticket (guid) W bardziej skomplikowanych przypadkach id umożliwia skojarzenie req. i resp.

35 Publish / Subscribe Zdarzenia na poziomie systemowym Wystąpienie zdarzenia oznacza wysłanie komunikatu Obsługa zdarzenia odpowiada obsłużeniu komunikatu Zdarzenia powinny być rozpatrywane na poziomi biznesowym (zmienił sie stan zamówienia, ktoś ma inny adres, rabt itd.)

36 Kolejność zdarzeń Sprzedaz Rachunko wosc Spedycja Zaakceptowane Opłacone Nie ma zamówienia w DB Komunikat zostaje odrzucony Czeka na Opłacone (które już było)

37 Kolejność zdarzeń Nie należy zakładać konkretnej kolejności nadchodzenia komunikatów W przypadku problemów mozna założyć próbę ponownego przetworzenia komunikatu w przyszłości Zyski to m.in. Lepsza skalowalność Większa odporność na błędy

38 Własność komunikatu Co oznacza własność ? W ReqResp nie za bardzo wiadomo kto jest wlaścicielem formatu/protokolu W PubSub właścicielem jest publikujący

39 Publish / Subscribe

40 Subscribe Aby zredukować powiazania przestrzenne (spatial coupling) niezbędne jest mapowanie między typem komunikatu i adresem sewisu Subskrypcja oznacza gotowość do obsługi danego typu komunikatów rejestracja handlera oznacza właśnie subbskrypcje (może przekładać się na wysłanie wewnętrznych komunikatów w obrębie infrastruktury) W takim wypadku zapamietywany jest adres handlera.

41 Publisher Subscriber Subscribe Subscriber

42 Publisher Subscriber abcdefgh

43 Styl architektoniczny An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style. Fielding 2000 Zbiór wskazówek nt. tego co jest a co nie jest dozwolone.

44 SOA jest stylem architektonicznym SOA opiera się na komunikatach Soa zakłada autonomię serwisów … Dwa najczestsze podejscia Bus vs. Broker służą redukcji powiązań przstrzennych

45 Styl architektoniczny Broker Inicjator żąda usługi od brokera Broker obsługuje po kolei żądania i przekazuje je dalej Service A Service B Service C Service D Broker

46 Cechy Broker-a Broker jest fizycznie odseparowany Cała komunikacja odbywa się przez niego Broker musi obsłużyć upadki serwisów i przekazywanie wiadomości Broker stanowi single point of failure – musi być wydajny i niezwykle stabilny Technologie: BizTalk, CORBA, UDDI

47 Zalety Broker-a Dzieki skoncentrowaniu komunikacji w jednym miejscu łatwo zarządzać centralnie konfiguracją Łatwe jest uzyskanie inteligentnego przekazywania danych, tramsformacje, orkiestracje itd. Nie wymaga wielu zmian w serwisach

48 Wady Broker-a Narusza autonomię serwisów Stanowi single point of failure i b. często jest wąskim gardłem

49 Styl architektoniczny Szyna Sink SourceSink Source Bus Źródła i ujścia zdarzeń komunikują się za pośrednictwem kanałów w szynie Źródło umieszcza komunikaty (zdarzenia) w kanale a ujscie jest notyfikowane odostępności komunikatu

50 Topologia Szyny AppApp Bus.dllBus.dll AppApp Bus.dllBus.dll AppApp Bus.dllBus.dll AppApp Bus.dllBus.dll AppApp Bus.dllBus.dll AppApp Bus.dllBus.dll AppApp Bus.dllBus.dll AppApp Bus.dllBus.dll

51 Cechy Szyny Szyna niekoniecznie jest fizycznie odseparowana Kanały mogą być zarówno fizyczne jak logiczne Komunikacja jest rozproszona pomiedzy wieloma kanalami Szyna jest prostsza Brak single point of failure

52 Zalety Szyny Brak single point of failure Nie narusza autonomii serwisu The anti-broker

53 Wady szyny Trudniejsza do zaprojektowania niż Broker

54 Komercyjne implementacje ESB Adeptia ESB Suite webmethods Enterprise Service Bus (SoftwareAG) (TIBCO) ActiveMatrix Service Bus IBM WebSphere ESB IBM WebSphere Message Broker ttxNgine (3Txpert GmbH) Microsoft BizTalk Server Windows Azure Service Bus Neudesic Neuron-ESB NServiceBus Oracle Enterprise Service Bus (BEA Logic) Progress Sonic ESB Red Hat JBoss Fuse IONA (acquired by Progress) InterSystems Ensemble

55 Otwarte implementacje ESB Apache ServiceMix Apache Synapse JBoss ESB MassTransit NetKernel NServiceBus Rhino Service Bus Petals ESB Spring Integration Open ESB WSO2 ESB Mule UltraESB Talend ESB Shuttle Service Bus Red Hat Fuse ESB (based on Apache ServiceMix)

56 Połączenie obu światów

57 Co to jest serwis? Serwis jest techniczną realizacją pewnych biznesowych możliwości. Serwis powinien przejechowywać (niekoniecznie być właścicielem) wszystkie dane i reguły niezbędne mu do działania

58 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

59 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

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

61 Który serwis jest właścicielem strony?

62 Żaden

63 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

64 Kompozycja strony Server Katalog Ceny Magazyn Cross Sell

65 Amazon.com - sprzedaż

66 Który serwis odpowiada za proces?

67 Żaden

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

69 Cache = efektywność+problemy DB Cache

70 Zapytania ?

71 Dane zmieniają się często Dane poprawne 10 minit temu Lista klientów

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

73 Command Query Responsibility Segregation

74 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

75 Ale co zrobić z nieaktualnymi danymi w cache dla potrzeb query Co jeżeli do generowana updateu użyte zostana niektualne dane IDTotalDateShippe d Accou nt etc 317$37.871/9/09YesA17T5 318$99.993/7/09YesA17T5 319$ /8/09YesP313Z 320$69.479/9/09NoP599Z Orders CancelCancel SaveSave

76 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 zawse uda sie rezygnacja z wysyłki w ciagu kilku sekund Właściwy zakup udbywa sie przy potwierdzeniu a nie kliknieciu kup

77 System rezerwacji

78

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

80 Uchwycenie intencji użytkownika Rezerwacja grupowea: 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

81 Odgadywanie zmian Koszyk nie jest aktualny! Produkt pokazywany na podstawie cmd

82 Komenda vs. encja Łatwiej walidować komendę Z mała iloscią danych Bardziej konkretną Chodzi o potencjalną poprawność (wynik nie jest ostateczny) Walidacja dyżych encji jest trudna


Pobierz ppt "Komponentowe i rozproszone Systemy rozproszone. System aplikacja Aplikacja: jeden proces, jeden system op., jeden komputer System: wiele procesow, (zwykle)"

Podobne prezentacje


Reklamy Google