Rozproszona i asynchroniczna architektura - case study - Spread it
•Als PPTX, PDF herunterladen•
0 gefällt mir•309 views
Slajdy z prezentacji wygłoszonej na Spread IT 2016 w Gliwicach
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (16)
Andere mochten auch
Andere mochten auch (16)
Ähnlich wie Rozproszona i asynchroniczna architektura - case study - Spread it
Ähnlich wie Rozproszona i asynchroniczna architektura - case study - Spread it (20)
Rozproszona i asynchroniczna architektura - case study - Spread it
- 1. Rozproszona i asynchroniczna architektura oparta na Azure - case study Krzysztof Szabelski
- 2. Krzysztof Szabelski Konsultant techniczny, trener, prelegent Obszary zainteresowań ► .NET ► Architektura systemów ► Przywództwo techniczne ► Microsoft Azure Prywatnie ► Skialpinista, ► Motocyklista, ► Podróżnik Great software… because we put People first ► Software development services ► Training and consulting
- 4. O projekcie • Powiedzmy, że chodzi o: • Nowatorski system zamawiania i obsługi taksówek. • SaaS • Multitenant • Mali klienci (małe miasteczka) • Wymagania niefunkcjonalne • Dostępność bliska 24/7 • Duża liczba zleceń w szczycie • Niezbędna responsywność dla użytkownika, nawet w szczycie
- 5. Website Services Browser application SQL Databases Storage blob Email Service Commands Service SignalR Hub Host New order topic Application Insights Order Database Order Service Notification topic Mobile Gateway Push Notification Ack Service Notification timeout topic Notification ack topic Timedout notification topic Order Processor Service Mobile App
- 6. Asynchroniczność na poziomie architektury Browser application Booking Commands Service Bookings Hub Host New booking topic Booking Database Booking Service Notification topic Booking Processor Service Scenariusz 1 – normalne działanie
- 7. Asynchroniczność na poziomie architektury Browser application Booking Commands Service Bookings Hub Host New booking topic Booking Database Booking Service Notification topic Booking Processor Service Scenariusz alternatywny – maksymalna prostota
- 8. Asynchroniczność na poziomie architektury Browser application Booking Commands Service Bookings Hub Host New booking topic Booking Database Booking Service Notification topic Booking Processor Service Scenariusz 2 – godziny szczytu Δt=?
- 9. Asynchroniczność na poziomie architektury Browser application Booking Commands Service Bookings Hub Host New booking topic Booking Database Booking Service Notification topic Booking Processor Service Scenariusz 3 – wzrost liczby klientów
- 10. Asynchroniczność na poziomie architektury Browser application Booking Commands Service Bookings Hub Host New booking topic Booking Database Booking Service Notification topic Booking Processor Service Scenariusz 4 – coś poszło nie tak
- 11. Mikroserwisy • Osiągnięte korzyści • Segmentacja danych • Modularność systemu • Koszty i nieosiągnięte korzyści • Koszty vs prędność • Brak odporności na awarie pojedynczych serwisów – ukryte zależności • Niezależny deployment – nadmierna komplikacja dla jednego zespołu
- 12. Mikroserwisy „Almost all the successful microservice stories have started with a monolith. Almost all (...) system that was built as a microservice system from scratch, has ended up in serious trouble.” Martin Fowler
- 13. Chmura obliczeniowa w praktyce IaaS czy PaaS? + Koszt usług - Koszt obsługi - Czas uruchomienia - Podatność na błędy ludzkie + Koszt obsługi + Czas uruchomienia + Bezpieczeństwo/skalowalność - Ograniczenia - Koszt usług
- 14. Microsoft Azure – wykorzystane usługi • Cloud Service • Trochę przestarzałe • App Services (Web App) – lepsza alternatywa • SQL Database • Ograniczony Sql Server – perspektywa DB Nazi • Wygodny SQL Server – perspektywa developera • Azure Service Bus • Tanio, wygodnie i stabilnie, żyć nie umierać • Application Insights • Send Grid • Search
- 15. Podsumowanie • PaaS – the way to go! • Realnie globalny zasięg dla małej organizacji • Duża oszczędność czasu zarządzania środowiskiem • Microservices • Unikaj • Lub bądź pewien, że wiesz co robisz i rób to dobrze • Kolejki i przetwarzanie w tle • Potężny, obosieczny miecz • Używaj z rozwagą, licz się z konsekwencjami
Hinweis der Redaktion
- Microserwisy: Separacja zasobów dla funkcji użytkownika. Fragmentacja bazy danych
- Dobrze obsługuje picki - zapewnia responsywność strony, użytkownik dostaje potwierdzneie przyjęcia, message będzie obsłużone za maks kilka minut, - dobrze zaprojektowane pozwala unikać timeoutów przy nagłym wzroście nowych zleceń (zanim serwis się przeskaluje – o ile wąskim gardłem nie jest baza) - utrzymanie backend serwisów to koszmar (failed messages, content or other problem, mail to support? retry? default retry's too quick, - czas obsługi, wizualizacja postępu na frontendzie, generowanie numeru zlecenia na kliencie (jak zapewnić unikalnosć itp) - sprawy się komplikują.
- Dobrze obsługuje picki - zapewnia responsywność strony, użytkownik dostaje potwierdzneie przyjęcia, message będzie obsłużone za maks kilka minut, - dobrze zaprojektowane pozwala unikać timeoutów przy nagłym wzroście nowych zleceń (zanim serwis się przeskaluje – o ile wąskim gardłem nie jest baza) - utrzymanie backend serwisów to koszmar (failed messages, content or other problem, mail to support? retry? default retry's too quick, - czas obsługi, wizualizacja postępu na frontendzie, generowanie numeru zlecenia na kliencie (jak zapewnić unikalnosć itp) - sprawy się komplikują.
- Dobrze obsługuje picki - zapewnia responsywność strony, użytkownik dostaje potwierdzneie przyjęcia, message będzie obsłużone za maks kilka minut, - dobrze zaprojektowane pozwala unikać timeoutów przy nagłym wzroście nowych zleceń (zanim serwis się przeskaluje – o ile wąskim gardłem nie jest baza) - utrzymanie backend serwisów to koszmar (failed messages, content or other problem, mail to support? retry? default retry's too quick, - czas obsługi, wizualizacja postępu na frontendzie, generowanie numeru zlecenia na kliencie (jak zapewnić unikalnosć itp) - sprawy się komplikują.
- Dobrze obsługuje picki - zapewnia responsywność strony, użytkownik dostaje potwierdzneie przyjęcia, message będzie obsłużone za maks kilka minut, - dobrze zaprojektowane pozwala unikać timeoutów przy nagłym wzroście nowych zleceń (zanim serwis się przeskaluje – o ile wąskim gardłem nie jest baza) - utrzymanie backend serwisów to koszmar (failed messages, content or other problem, mail to support? retry? default retry's too quick, - czas obsługi, wizualizacja postępu na frontendzie, generowanie numeru zlecenia na kliencie (jak zapewnić unikalnosć itp) - sprawy się komplikują.
- Dobrze obsługuje picki - zapewnia responsywność strony, użytkownik dostaje potwierdzneie przyjęcia, message będzie obsłużone za maks kilka minut, - dobrze zaprojektowane pozwala unikać timeoutów przy nagłym wzroście nowych zleceń (zanim serwis się przeskaluje – o ile wąskim gardłem nie jest baza) - utrzymanie backend serwisów to koszmar (failed messages, content or other problem, mail to support? retry? default retry's too quick, - czas obsługi, wizualizacja postępu na frontendzie, generowanie numeru zlecenia na kliencie (jak zapewnić unikalnosć itp) - sprawy się komplikują.
- Nie zostawiaj niczego na potem. Circuit breaker, retry policy, fail independent Odporność na awarie - jeśli pricing service jest potrzebny, żeby złożyć zamówienie w booking service, to i tak nic z tego.
- Nie zostawiaj niczego na potem. Circuit breaker, retry policy, fail independent
- Po prostu działają ale są ciężkie. Dlaczego one? Były stabilne, ograniczona wiedza. DevOps: Prostota deploymentu - w porównaniu do IaaS torpeda! Skryptowanie w powershellu bardzo proste. Wprawdzie nie działa ARM, ale do nie zbyt złożonego środowiska service manager jest ok. Czas deploymentu Irytuje przy developmencie, Testowanie na bieżąco w środowisku cloudowym robi się żmudne Skalowanie trwa. Liczba instancji + niemożliwość łączenia worker roli na jeden serwis. nie do końca umożliwia purystczne podejście microserviceowe, gdzie host per service nie jest efektywny kosztowo. Nasz trochę ugryzło. Robiliśmy przez jakiś czas backgroundowe workery jako web role, żeby umożliwć ich łączeni. Ale to jak wiadomo działa w kontekście IIS’a i rozbiliśy się o ryzyko ubijania instancji. Są na to odpowiendnie konfiguracje (do ustawienia w trochę hakerski sposób), ale trudno powiedzieć, czy można im zaufać. (Pokazać skrypt) Obejście do emulatora naszczęście da się obejść (pokazać kod i duplikację configuracji)
- Po prostu działają ale są ciężkie. Dlaczego one? Były stabilne, ograniczona wiedza. DevOps: Prostota deploymentu - w porównaniu do IaaS torpeda! Skryptowanie w powershellu bardzo proste. Wprawdzie nie działa ARM, ale do nie zbyt złożonego środowiska service manager jest ok. Czas deploymentu Irytuje przy developmencie, Testowanie na bieżąco w środowisku cloudowym robi się żmudne Skalowanie trwa. Liczba instancji + niemożliwość łączenia worker roli na jeden serwis. nie do końca umożliwia purystczne podejście microserviceowe, gdzie host per service nie jest efektywny kosztowo. Nasz trochę ugryzło. Robiliśmy przez jakiś czas backgroundowe workery jako web role, żeby umożliwć ich łączeni. Ale to jak wiadomo działa w kontekście IIS’a i rozbiliśy się o ryzyko ubijania instancji. Są na to odpowiendnie konfiguracje (do ustawienia w trochę hakerski sposób), ale trudno powiedzieć, czy można im zaufać. (Pokazać skrypt) Obejście do emulatora naszczęście da się obejść (pokazać kod i duplikację configuracji)