Bid Now

Autor: Grzegorz Glonek

Opublikowano: 2011-07-04

Pobierz i uruchom Windows Azure SDK 1.6

Wprowadzenie

Aplikacje sklepów internetowych lub systemów aukcyjnych są wręcz klasycznymi przykładami programów, które mogą zyskać na wykorzystaniu w nich chmury. Specyfiką tych aplikacji są obciążenia generowane przez użytkowników, które charakteryzują się zrównoważonym obciążeniem przez większą część roku oraz dużym wzrostem liczby użytkowników w grudniu. Przygotowany przez programistów Microsoft projekt Bid Now to portal aukcyjny prezentujący wykorzystanie mechanizmów dostarczanych przez platformę Windows Azure do zbudowania wysokoskalowalnych aplikacji mających sprostać takiemu scenariuszowi.

Technologie

Wersja projektu 1.0.2 udostępniona na stronie domowej (https://archive.msdn.microsoft.com/BidNowSample) pochodzi z grudnia 2010 roku. Została napisana w całości na podstawie platformy .Net Framework 4.0 oraz Windows Azure Guest OS 1.3. Aplikacja udostępnia uwierzytelnianie oparte na mechanizmie Live ID dostarczanym przez Microsoft. Oprócz Azure Compute, portal korzysta także ze struktur dostępnych w Azure Storage oraz SQL Azure. Dodatkowo w projekcie pokazana jest integracja aplikacji mobilnej dla Windows Phone 7 z Windows Azure.

Architektura

Projekt zawiera aplikację internetową napisaną w technologii Asp.Net MVC i uruchomiającą się na instancjach Web Role. Korzysta ona z SQL Azure oraz kolejek i obiektów Blob udostępnianych przez Azure Storage, a poza tym wykorzystuje instancję Worker Role do obsługi wykonywanych przez użytkownika akcji. Kolejnym elementem jest aplikacja mobilna dla Windows Phone 7, która pozwala na dostęp do całego systemu z poziomu telefonu komórkowego. Interfejsem łaczącym chmurę Azure z WP7 jest usługa sieciowa WCF, uruchomiona jako instancja Web Role, udostępniająca wybrane funkcjonalności. Ogólny schemat budowy całego projektu przedstawia poniższy rysunek:

Rys.1. Ogólny model architektury projektu Bid Now.

Jak widać, aplikacje uruchomione na instancjach Wroker i Web Role nie są ze sobą zbyt sztywno powiązane. Dzięki temu każdy z elementów może być niezależnie skalowany, jeśli zajdzie taka potrzeba. To zapewni nam optymalne działanie aplikacji i uniknięcie nadmiarowego zużycia zasobów w tych częściach aplikacji, które nie wymagają zmian. Aplikacje klienckie (klient webowy oraz mobilny) korzystają z tych samych usług, które mają dostęp do SQL Azure oraz do obiektów Blob. Wszystkie długotrwałe zadania (np. kompresja zdjęć przed umieszczeniem w Azure Storage) wykonywane są przez instancję Worker Role. Zlecenie wykonania przez tę instancję jakiejś operacji następuje przez wiadomości umieszczane w kolejkach Azure Storage. Taka architektura, oprócz skalowalności, zapewnia również stałą responsywność całego systemu.

Przykładowy scenariusz: prowadzenie licytacji

Teraz prześledźmy, co dzieje się na przykładzie akcji wręcz podstawowej dla tego typu aplikacji. Licytacjarozpoczyna się od podania swojej oferty kupna przedmiotu. W danych dotyczących aukcji, które posiada portal aukcyjny, istnieje informacja o dotychczasowej najwyższej ofercie. Jeśli nowa suma jest większa od dotychczasowej, informacja o nowej ofercie zostaje umieszczona w kolejce newbidq. Następnie proces przetwarzający sprawdza, czy nowa oferta ,,przebiła'' ofertę innej osoby, czy może jest to pierwsza oferta. Jeśli istniały już wcześniejsze oferty, odpowiednie powiadomienie zaadresowane do osoby, której oferta została właśnie ,,przebita'', zostanie umieszczone w kolejce notificationq.

Budowa instancji Worker Role

Wszystkie długotrwałe zadania wykonywane są przez moduł uruchamiany jako instancja Worker Role. Ponieważ to na nim w dużej mierze spoczywa odpowiedzialność za szybkie działanie systemu, warto zobaczyć jak jest on zbudowany.

Obiekt klasy WorkerRole, będący punktem wejściowym dla instancji Windows Azure, posiada własną implementację trzech metod OnStart(), OnStop() oraz Run(). Ponadto utrzymuje on listę uchwytów odpowiedzialnych za obsługę nadchodzących wiadomości. Każdy z takich uchwytów działa w osobnym wątku uruchamianym w metodzie Run(). Każdy uchwyt dziedziczy po klasie abstrakcyjnej BaseHandler, która zawiera publiczną metodę Run() odpowiadającą za nasłuchiwanie wiadomości przychodzących w kolejce i ich odbiór oraz publiczną abstrakcyjną metodę ProcessMessage() odpowiedzialną za przetwarzanie tych wiadomości.

Analizując implementację metody Run() w klasie bazowej uchwytu, widzimy, że cały proces trwa w pętli dopóty, dopóki wartość pola keepRunning nie zostanie zmieniona na false (zmiana taka zachodzi w metodzie Stop() znajdującej się także w klasie BaseHandler). Przy każdym przejściu pętli zostaje pobrana wiadomość z odpowiedniej kolejki i następnie (o ile istnieje) zostaje przetworzona i po pomyślnym zakończeniu tej operacji jawnie usunięta z kolejki (przypomnienie -- na platformie Windows Azure wiadomości w chwili odczytu są jedynie ukrywane, a nie usuwane). Implementacja przetwarzania wiadomości jest indywidualna dla każdego uchwytu.

Podsumowanie

Na przykładzie tego projektu widać, w jaki sposób można zbudować skalowalną aplikację internetową. Przygotowany system pozwala na szybką naukę budowania tego typu aplikacji, efektywnie wykorzystując platformę Windows Azure. Z drugiej strony widać także, że zaprojektowanie nawet stosunkowo prostego portalu nie jest rzeczą trywialną. Na pewno budowę takiego systemu należy poprzedzić wnikliwą analizą rozwiązywanego zadania oraz mechanizmów, jakie oferuje chmura, tak aby wybrać te odpowiednie. Ważne jest także dobrze przemyślane wykorzystanie Azure Storage.

Zachęcam do zapoznania się z tym projektem, ponieważ może on pomóc zrozumieć jak dobrze projektować aplikacje w chmurach.

 

---