Jak wdrażany jest eCommerce Enterprise?
Przed e-commerce sieć była w większości statyczna. Strony internetowe składały się z HTML i obrazów - bez CSS, bez JavaScript i bez AJAX. Przeglądarki internetowe nie obsługiwały protokołu SSL aż do końca 1994 r. Wielu wiodących dostawców e-commerce, w tym Amazon, eBay, Tesco i Dell.com, po raz pierwszy pojawiło się w Internecie w 1994 i 1995 r. Ze statycznymi stronami internetowymi. Oczywiście ludzie wchodzący online chcieli mieć możliwość dokonywania transakcji. Dodanie możliwości transakcji do statycznego kodu HTML było technicznym wyczynem, który wymagał:
• Używanie kodu do obsługi danych wejściowych użytkownika i dynamicznego generowania stron HTML
• Zabezpieczenie komunikacji
• Przechowywanie danych w trwałej bazie danych
Dzisiejsze oprogramowanie i architektura użyta do budowy tych systemów w dużej mierze pozostały takie same od 1995 roku. Innowacje były co najwyżej przyrostowe. Przy tak dużej ilości pieniędzy generowanych przez e-commerce dostępność jest najważniejszą siłą napędową architektury. Wraz ze wzrostem sprzedaży detalicznej wielokanałowej i rosnącymi wymaganiami, obecne podejście do architektury nie jest zrównoważone. Przejrzyjmy status quo.
Obecna architektura wdrażania
Większość architektur wdrażania e-commerce jest zgodna ze starszym, trójwarstwowym modelem wdrażania obejmującym warstwy internetowe, aplikacyjne i bazy danych. Serwery WWW tworzą warstwę internetową i tradycyjnie są odpowiedzialne za dostarczanie treści statycznych do sieci dostarczania treści (CDN). Środkowa warstwa obejmuje serwery aplikacji i jest w stanie generować odpowiedzi, które mogą być wykorzystywane przez różnych klientów. Warstwa danych służy do przechowywania danych wymaganych dla aplikacji (np. katalogu produktów, metadanych różnych typów) oraz danych należących do klientów (np. Zamówienia, profile). Omówimy to w tej części, ale technologia, która leży u podstaw tej architektury, uległa zasadniczym zmianom. Każdy kanał zazwyczaj ma własną wersję tego stosu, z warstwą integracji lub integracjami punkt-punkt łączącymi wszystko razem. Wszystkie warstwy stosu są zwykle wdrażane z jednego centrum danych. Ta architektura nadal dominuje, ponieważ jest naturalnym rozszerzeniem oryginalnych wzorców wdrażania z pierwszych dni e-commerce i ogólnie działa. Zbadajmy każdą warstwę bardziej szczegółowo.
DNS
DNS jest odpowiedzialny za rozstrzyganie przyjaznych nazw domen (np. Witryna.com) na adres IP (np. 161.170.248.20). DNS istnieje, więc możesz zapamiętać "website.com" zamiast 161.170.248.20. Gdy platforma e-commerce jest obsługiwana z jednego centrum danych, zwykle zwracany jest tylko jeden adres IP, ponieważ klaster modułu równoważenia obciążenia udostępnia jeden adres IP światu. Jednak w przypadku ujawnienia wielu centrów danych lub wielu adresów IP na centrum danych DNS staje się bardziej skomplikowany, ponieważ jeden adres IP musi zostać wybrany z listy dwóch lub więcej (zazwyczaj jeden na centrum danych). Adresy IP są zwracane do klienta na uporządkowanej liście, przy czym pierwszy adres IP zwraca ten, z którym klient łączy się pierwszy. Jeśli ten adres IP nie odpowiada, klient kolejno przesuwa listę w dół, aż znajdzie taki, który działa. Często używane serwery DNS, takie jak BIND, działają dobrze z jednym adresem IP na nazwę domeny. Jednak wraz z rozwojem e-commerce wzrosła liczba wdrożeń w wielu centrach danych w konfiguracji aktywnej / aktywnej lub aktywnej / pasywnej. Zasadniczo działanie z więcej niż jednego centrum danych wymaga od serwera DNS wyboru między dwoma lub więcej adresami IP. Tradycyjne serwery DNS są w stanie obsługiwać podstawowe algorytmy równoważenia obciążenia, takie jak round-robin, ale nie są w stanie kopać głębiej niż to, aby ocenić kondycję centrum danych w czasie rzeczywistym, położenie geograficzne klienta, opóźnienie w obie strony między klientem a każdym centrum danych lub pojemność każdego centrum danych w czasie rzeczywistym. Ta bardziej zaawansowana forma równoważenia obciążenia jest znana jako Globalne równoważenie obciążenia serwera, w skrócie GSLB. Rozwiązania GSLB są już prawie wymagane, ponieważ za większością nazw domen kryje się więcej niż jeden adres IP. Rozwiązania GSLB mogą przyjmować następujące formy:
• Hostowany jako samodzielna usługa
• Hostowany jako część sieci dostarczania treści (CDN)
• Oparty na urządzeniach, rezydujący w lokalnym centrum danych
Wielu zaczyna przechodzić na rozwiązania hostowane. Omówimy później DNS i GSLB bardziej szczegółowo, ale nie trzeba dodawać, że GSLB oparty na urządzeniach nie będzie już działać, gdy przejdziemy do chmury. Rozwiązania muszą być oparte na oprogramowaniu i muszą być bardziej inteligentne.
Równoważenie obciążenia w centrach danych
Dzisiejsze platformy e-commerce są obsługiwane z setek, a nawet tysięcy fizycznych serwerów, z tylko jednym adresem IP dostępnym dla świata. Równoważenie obciążenia odbywa się na każdej warstwie w centrum danych. Urządzenia do równoważenia obciążenia sprzętowego oparte na urządzeniach są dziś używane jako punkt wejścia do centrum danych i do równoważenia obciążenia w centrum danych. Jeśli warstwa serwera WWW obsługuje ruch i wysyła go do warstwy serwera aplikacji, serwer WWW często ma wbudowane funkcje równoważenia obciążenia. Równoważenia obciążenia ewoluowały z czasem, od wykonywania prostych zadań równoważenia obciążenia do zapewnienia pełnego zestawu kontroli aplikacji usługi. Nawet termin równoważenia obciążenia jest teraz często zastępowany przez większość dostawców kontrolerem dostarczania aplikacji, który dokładniej oddaje ich rosnącą rolę. Oto niektóre z tych zaawansowanych funkcji:
• Podawanie treści statycznych
• Dynamiczne buforowanie stron
• Zakończenie SSL / TLS
• Przepisywanie adresów URL
• Zasady przekierowania
• Manipulowanie nagłówkiem pamięci podręcznej
• Dynamiczne przepisywanie stron w celu poprawy wydajności
• Zapora sieciowa aplikacji
• Równoważenie obciążenia
• Kompresja treści
• Ograniczanie / ograniczanie prędkości
• Szybkie, bezpieczne połączenia z chmurami
Równoważenie obciążenia na dzisiejszych platformach e-commerce będzie musiało ulec zasadniczej zmianie, aby spełnić przyszłe wymagania.
Serwery WWW
We wczesnych dniach e-commerce serwery WWW były narażone bezpośrednio na publiczny Internet, przy czym każdy serwer miał własny adres IP i własny wpis w rekordzie DNS. Aby spełnić wymagania klientów dotyczące prawdziwie transakcyjnego e-commerce, do serwerów sieciowych dodano obsługę interfejsu CGI (Common Gateway Interface). Ponieważ potrzeby przewyższyły możliwości CGI, serwery aplikacji zostały dodane za serwerami WWW, przy czym serwery WWW nadal odpowiadają za dostarczanie zawartości statycznej i służą jako moduł równoważenia obciążenia dla puli serwerów aplikacji. Wraz ze wzrostem wykorzystania e-commerce i wzrostem liczby serwerów WWW, przed serwerami WWW dodano sprzętowe równoważenia obciążenia sprzętowe. Serwery sieci Web nie mogą grupować się w klastry i udostępniać światu jednego adresu IP, podobnie jak usługi równoważenia obciążenia. Usługi równoważenia obciążenia zaczęły również oferować wiele takich samych funkcji jak serwery WWW. Linia między serwerami WWW a modułami równoważenia obciążenia zaciera się. Serwery sieciowe nie są absolutnie wymagane. W rzeczywistości ich wykorzystanie maleje wraz z rozwojem technologii serwerów sieciowych. Jeśli używane są serwery internetowe, mogą one technicznie wykonywać następujące funkcje:
• Podawanie treści statycznych
• Buforowanie dynamicznych stron
• Zakończenie SSL / TLS
• Przepisywanie adresów URL
• Zasady przekierowywania
• Manipulowanie nagłówkami pamięci podręcznej
• Dynamiczne przepisywanie stron w celu poprawy wydajności
• Tworzenie zapory sieciowej
• Równoważenie obciążenia
• Kompresowanie treści
Jednak serwery sieciowe zwykle po prostu wykonują następujące funkcje:
• Udostępnianie treści statycznych w sieci dostarczania treści
• Przepisywanie adresów URL
• Zasady przekierowywania
• Równoważenie obciążenia
W miarę dojrzewania sieci CDN, modułów równoważenia obciążenia i serwerów aplikacji coraz częściej przekazuje się im funkcje zazwyczaj wykonywane przez serwery WWW. Biorąc pod uwagę, że wymagane są serwery aplikacji, usługi równoważenia obciążenia i sieci dostarczania treści, serwery WWW stają się coraz bardziej marginalizowane, a ich wykorzystanie spada wśród głównych dostawców e-commerce. Prawdziwy problem polega na tym, że serwery WWW znacznie komplikują elastyczność.
Dodanie nowego serwera aplikacji wymaga:
1. Sprzęt do obsługi administracyjnej nowego serwera aplikacji
2. Instalowanie / konfigurowanie nowego serwera aplikacji
3. Wdrażanie aplikacji na serwerze aplikacji
4. Rejestracja serwera aplikacji za pomocą serwera WWW lub modułu równoważenia obciążenia
Jeśli chcesz zwiększyć pojemność serwera WWW ze względu na zwiększoną pojemność serwera aplikacji, wykonaj następujące czynności:
1. Zaopatrz sprzęt w nowy serwer WWW.
2. Zainstaluj / skonfiguruj nowy serwer WWW.
3. Zarejestruj nowy serwer WWW w module równoważenia obciążenia.
Dodanie nawet jednego serwera aplikacji może wymagać dużo pracy i koordynacji. Podczas gdy niektóre pary serwer WWW i serwer aplikacji umożliwiają skalowanie każdej warstwy niezależnie, nadal musisz martwić się o zależności. Jeśli dodasz wiele serwerów aplikacji bez uprzedniego dodania serwerów WWW, może zabraknąć pojemności serwera WWW. Kolejność ma znaczenie. Często łatwiej jest wyeliminować warstwę serwera WWW i przekazać odpowiedzialność za nią na CDN, moduł równoważenia obciążenia i serwer aplikacji. Wiele modułów równoważenia obciążenia automatycznie wykrywa nowe punkty końcowe, co jeszcze bardziej ułatwia szybkie dodawanie i usuwanie nowej pojemności. Spłaszczając hierarchię, zyskujesz dużą elastyczność. Serwery WWW nadal mogą wnieść wartość dodaną, jeśli robią coś, czego inna warstwa nie może.
Aplikacje eCommerce
"E" jest szybko usuwane z "e-commerce", aby odzwierciedlić fakt, że nie ma już tak wyraźnego rozgraniczenia między kanałami. Niektórzy detaliści nie są dziś w stanie zgłaszać sprzedaży według kanałów, ponieważ ich kanały są ze sobą powiązane. Jak omówiono w części 1, ten jeden kanał, zwany omnichannel, służy jako podstawa wszystkich kanałów. Przykłady kanałów obejmują:
• Sieć
• Społeczny
• Mobilny
• Sklep fizyczny
• Kiosk
• Czat
• Centrum telefoniczne
Z jednej strony przekonasz się, że każdy kanał ma swój własny pionowy stos, w tym bazę danych. W tym modelu każdy kanał jest połączony ze sobą poprzez swobodne użycie warstwy integracyjnej. Oto jak naturalnie ewoluował e-commerce, ale cierpi z powodu wielu pułapek:
• Trzeba napisać dużo kodu, aby wszystko skleić.
• Kanały są zawsze niezsynchronizowane.
• Różnice w funkcjonalności denerwują klientów (np. Promocje online nie pojawiają się w systemach punktów sprzedaży w sklepie).
• Testowanie całego stosu jest niezwykle skomplikowane ze względu na wszystkie zasoby, które muszą być skoordynowane.
• Te same dane klientów mogą być aktualizowane jednocześnie z dwóch lub więcej kanałów, co prowadzi do konfliktów danych i złego doświadczenia.
W ciągu ostatnich kilku lat pojawiła się tendencja do kupowania lub budowania kompletnych platform z jedną logiczną bazą danych i brakiem integracji między kanałami. Oczywiście osiągnięcie tego wymaga czasu, ale wyraźnie jest to kierunek, w którym zmierza rynek. Ma to sens, biorąc pod uwagę wzrost sprzedaży detalicznej wielokanałowej i coraz większe oczekiwania. Obsługa prawdziwej sprzedaży detalicznej wielokanałowej jest obecnie konkurencyjnym wyróżnikiem komercyjnych platform e-commerce.
Serwery aplikacji
Serwery aplikacji, znane również jako kontenery, odgrywają kluczową rolę na dzisiejszych platformach e-commerce. Zapewniają środowisko wykonawcze dla aplikacji e-commerce i zapewniają takie usługi, jak obsługa żądań HTTP, zarządzanie sesjami HTTP, połączenia z bazą danych, uwierzytelnianie, usługi katalogowe, przesyłanie wiadomości i inne usługi wykorzystywane przez aplikacje e-commerce. Dzisiejsze serwery aplikacji są bardzo dojrzałe, oferując dziesiątki funkcji, które upraszczają projektowanie, wdrażanie i zarządzanie środowiskiem wykonawczym aplikacji e-commerce. Z biegiem lat nadal dojrzewają w następujący sposób:
• Bardziej modułowa architektura, uruchamiająca tylko usługi wymagane przez wdrażaną aplikację
• Szybsza, lżejsza architektura
• Ścisła integracja z bazami danych, a niektórzy dostawcy oferują prawdziwą dwukierunkową komunikację z bazami danych
• Pełna integracja z siatkami pamięci podręcznej
• Ulepszona diagnostyka
• Łatwiejsze zarządzanie
Serwery aplikacji nadal odgrywają kluczową rolę na dzisiejszych platformach e-commerce.
Bazy danych
Bazy danych nadal odgrywają ważną rolę we współczesnej architekturze e-commerce. Typowe przykłady danych w aplikacji e-commerce, które muszą być przechowywane, to zamówienia, profile, produkty, kody SKU, zapasy, ceny, oceny i recenzje oraz historia przeglądania. Dane mogą być przechowywane przy użyciu trzech podejść wysokiego poziomu.
W pełni znormalizowana
Znormalizowane dane mają zdefiniowaną, sztywną strukturę z ograniczeniami obejmującymi typy danych, niezależnie od tego, czy wymagana jest każda kolumna itd. Oto jak zdefiniowałbyś bardzo prostą tabelę produktów dla relacyjnej bazy danych SQL:
CREATE TABLE PRODUCT
(
PRODUCT_ID VARCHAR(255) NOT NULL,
NAME VARCHAR(255) NOT NULL,
DESCRIPTION CLOB NOT NULL,
PRIMARY KEY(PRODUCT_ID)
);
Aby pobrać dane, wykonaj zapytanie:
SELECT * FROM PRODUCT;
Ten format bardzo naśladuje arkusz kalkulacyjny. Dzięki danym w znormalizowanym formacie możesz wykonywać złożone zapytania, zapewniać integralność danych i selektywnie aktualizować bity danych. Relacyjne bazy danych są budowane w celu przechowywania i wyszukiwania znormalizowanych danych i były szeroko stosowane w e-commerce. Tradycyjne relacyjne bazy danych są zazwyczaj zgodne z ACID. ACID oznacza:
Atomicity (Atomowość)
Cała transakcja kończy się powodzeniem lub niepowodzeniem.
Consistency (Konsystencja)
Transakcja zostaje dokonana bez naruszenia jakichkolwiek ograniczeń integralności (np. Typ danych, czy kolumna ma wartość zerową, ograniczenia klucza obcego).
Isolation (Izolacja)
Każda transakcja jest wykonywana we własnym prywatnym obszarze izolowanym i nie jest widoczna dla żadnej innej transakcji, dopóki nie zostanie zatwierdzona.
Durability (Trwałość)
Dokonana transakcja nie zostanie utracona.
Większość aplikacji e-commerce korzysta ze skalowanej w pionie i poziomie relacyjnej bazy danych zgodnej z ACID dla podstawowych danych zamówienia i profilu. Relacyjne bazy danych były pierwotnym wąskim gardłem w aplikacjach e-commerce, ale wraz z dojrzewaniem tej technologii rzadko jest to kiedyś wąskie gardło, pod warunkiem przestrzegania odpowiednich praktyk kodowych. Buforowanie na poziomie aplikacji (zarówno w pamięci, jak i w siatkach danych) pomogło w dalszym skalowaniu relacyjnych baz danych.
NoSQL
Coraz popularniejszą alternatywą dla relacyjnych baz danych są magazyny kluczy / wartości lub dokumentów. Zamiast dzielenia i przechowywania danych w całkowicie znormalizowanym formacie, dane są reprezentowane jako XML, JSON, a nawet w formacie binarnym, przy czym dane są dostępne tylko wtedy, gdy znasz klucz rekordu. Implementacje różnią się znacznie, ale łącznie są one znane jako rozwiązania NoSQL. Oto przykład tego, co może być przechowywane dla tego samego produktu w poprzedniej sekcji:
{
"name": "Thermos Stainless King 16-Ounce Food Jar",
"opis": "Wykonany ze stali nierdzewnej o podwójnych ściankach, ten 16-uncjowy słoik na żywność jest praktycznie niezniszczalny, ale jego elegancki wygląd to jedno i drugie przyciągające wzrok i funkcjonalne … ",
…
}
NoSQL jest coraz częściej wykorzystywany do buforowania i przechowywania nierelacyjnych mediów, takich jak dokumenty i dane, które nie muszą być przechowywane w bazie danych zgodnej z ACID. Rozwiązania NoSQL ogólnie poświęcają spójność i dostępność w zamian za wydajność i możliwość skalowania w rozproszonej naturze. Zdjęcia produktów, oceny i recenzje, historia przeglądania i inne podobne dane są bardzo odpowiednie dla baz danych NoSQL, w których zgodność z ACID nie stanowi problemu. NoSQL coraz częściej zaczyna znajdować swoje miejsce w e-commerce na dużą skalę. Technologia ma prawdziwą wartość, ale dojście do niej i jej rozwój do poziomu relacyjnych baz danych zajmie trochę czasu. Relacyjne bazy danych istnieją w nowoczesnej formie od lat siedemdziesiątych. NoSQL istnieje już od kilku lat.
W pełni zdenormalizowane
Historycznie wiele danych było przechowywanych w zwykłym formacie HTML. Sprzedawcy używają edytorów WYSIWYG i zapisują sam HTML, albo w pliku, albo w bazie danych. Te fragmenty HTML byłyby następnie wstawiane na większe strony w celu utworzenia kompletnych stron internetowych. Dane wyglądały tak:
< h2 > Słoik na żywność 16-uncji Thermos Stainless King < /h2 >
< div id = "opis_produktu" >
Ten 16-uncyjny słoik na żywność wykonany ze stali nierdzewnej o podwójnych ściankach jest praktycznie niezniszczalny, a jego elegancki wygląd przyciąga wzrok i jest funkcjonalny …
< /div >
Jedną z wielu wad tego podejścia jest to, że nie można ponownie wykorzystywać tych danych w różnych kanałach. Będzie to działać na stronie internetowej, ale jak możesz uzyskać aplikację na iPhone′a, aby z niej korzystać? To podejście zanika i nie należy go już używać.
Hosting
Kluczem do sukcesu e-commerce jest model hostingu. Hosting obejmuje co najmniej fizyczne centrum danych, szafy na sprzęt, zasilanie i łączność z Internetem. Jest to również znane jako ping, power i pipe. Ponadto dostawcy mogą oferować sprzęt komputerowy, infrastrukturę wspierającą, taką jak sieć i pamięć, oraz różne usługi zarządzania z umowami o poziomie usług. Z punktu widzenia hostingu chmura jest znacznie bardziej ewolucyjna niż rewolucyjna. Przez wiele lat nie posiadano centr danych fizyczny ,z których prowadzisz działalność. Sprzęt używany do obsługi Twojej platformy i sieci, przez które często przesyłane są dane należący do dostawcy centrum danych. Rzadko można znaleźć dostawcę e-commerce na poziomie przedsiębiorstwa, który sam hostuje się na miejscu. To był kiedyś model, ale w ciągu ostatnich dwóch dekad nastąpił gwałtowny ruch w kierunku w pełni zarządzanego hostingu, a teraz publicznej infrastruktury jako usługi. Duzi, oddani dostawcy oferują znacznie lepsze centra danych i infrastrukturę wspierającą dla handlu elektronicznego. Nie trzeba dużo przerastać lokalnego centrum danych. Ci dedykowani dostawcy oferują następujące funkcje:
• Wysoka dostępność energii przez wielu dostawców i stosowanie generatorów zapasowych
• Bezpośrednie połączenia z wieloma szkieletami Internetu
• Wysokie bezpieczeństwo, w tym zapory ogniowe, strażnicy z bronią, fizyczne bezpieczeństwo biometryczne
• Umieszczenie centrów danych z dala od samolotów powodziowych, z dala od obszarów podatnych na trzęsienia ziemi i blisko taniej energii
• Zaawansowane tłumienie ognia
• Chłodzenie o wysokiej gęstości
Dedykowani dostawcy oferują znacznie więcej niż to, co można zbudować na terenie własnego centrum danych, za znacznie niższe koszty. Niektóre z tych centrów danych mają miliony metrów kwadratowych. Koszt krańcowy, jaki ci dostawcy ponoszą za jeszcze jednego najemcę, jest niewielki, co pozwala im przekazać część tych oszczędności. Korzyści skali są wiodącą zasadą dla tych dostawców. Większość tych dostawców oferuje usługi uzupełniające ofertę sprzętu i infrastruktury. Usługi te obejmują (w rosnącej kolejności złożoności):
• Zasilanie cykliczne
• Zarządzanie z systemu operacyjnego w dół (w tym łatanie)
• Usługi wspólne, takie jak magazynowanie i równoważenie obciążenia
• Zarządzanie z serwera aplikacji w dół (w tym łatanie)
• Zarządzanie z aplikacji w dół
• Bieżące opracowywanie / konserwacja na poziomie aplikacji
Platforma jako usługa i oprogramowanie jako usługa to to, co dostawcy infrastruktury jako usługi zbudowali na swojej infrastrukturze, próbując przesunąć łańcuch wartości i uzyskać większe przychody z wyższymi marżami. Wszystko, czego nie możesz odróżnić od siebie, powinno zostać zlecone na zewnątrz. Dotyczy to teraz szczególnie mocy obliczeniowej
Ograniczenia obecnej architektury wdrażania
Współczesna architektura wdrażania e-commerce opiera się na starych dekadach architektury, a dostępność jest motorem wszystkich decyzji. Ludzie są często zachęcani do dostępności platformy i karani, często zwolnieniami, za przerwy w pracy. Awaria w dzisiejszym coraz bardziej wielokanałowym świecie jest podobne do blokowania klientom dostępu do wszystkich fizycznych sklepów. Ponieważ fizyczne sklepy detaliczne coraz częściej korzystają z jednej platformy e-commerce omnichannel do systemów punktów sprzedaży w sklepach, przestanie istnieć faktycznie uniemożliwiają również sprzedaż w sklepie. Utrzymanie włączonych świateł jest koniecznością, która kosztuje prawie wszystko inne. Obecna architektura wdrażania ma wiele problemów:
• Wszystko jest statycznie konfigurowane i konfigurowane, co utrudnia skalowanie w górę lub w dół.
• Platforma jest skalowana pod kątem pików, co oznacza, że większość sprzętu jest rażąco niewykorzystana.
• Przerwy występują przy szybkich skokach ruchu.
• Zbyt dużo czasu spędza się na budowaniu infrastruktury, w przeciwieństwie do działań o wyższej wartości dodanej.
Przetwarzanie w chmurze może rozwiązać te problemy. Przeanalizujmy każdy z nich nieco dalej.
Provisioning statyczny
Większość dostawców e-commerce statycznie buduje i konfiguruje środowiska. Problem polega na tym, że ruch e-commerce jest z natury elastyczny. Ruch może łatwo wzrosnąć 100 razy ponad poziom podstawowy. Wystarczy, że najnowsza gwiazda muzyki pop opublikuje tweeta o swojej marce dla swoich 50 milionów obserwujących i dość szybko zobaczysz gwałtowny ruch, gdy inni ponownie tweetują oryginalny tweet. Świat jest o wiele bardziej połączony niż kiedyś. Albo musisz skalować do szczytu, albo ryzykujesz awarię pod dużym obciążeniem. Koszt awarii często przewyższa koszt zakupu kilku dodatkowych serwerów, więc serwery są nadmiernie rezerwowane, często o wiele więcej niż jest to konieczne. Dostarczanie statyczne jest złe, ponieważ jest nieefektywne. Nie można skalować w górę lub w dół na podstawie zapotrzebowania w czasie rzeczywistym. Prowadzi to do skalowania dostawców e-commerce dla pików w przeciwieństwie do skalowania dla rzeczywistego obciążenia. Ponieważ nikt nie chce zostać zwolniony, wszyscy po prostu szaleją w przesadzie w w celu utrzymania 100% czasu sprawności. Nadmierne przydzielanie zasobów prowadzi do poważnych problemów:
• Zmarnowane miejsce w centrum danych, które jest coraz droższe
• Niepotrzebne koszty ze względu na centrum danych i koszty ludzkie
• Skoncentruj się na podstawowej kompetencji - bez względu na to, czy sprzedajesz najnowsze buty do koszykówki, czy sprzedajesz wózki widłowe
Większość dostawców e-commerce musi zapewniać obsługę statyczną, ponieważ ich platformy e-commerce nie nadają się do dynamicznego skalowania. Na przykład wiele platform e-commerce wymaga, aby porty i adresy IP były zapisane na stałe w plikach konfiguracyjnych. Cały przemysł opierał się na zaopatrzeniu statycznym. Chmura i koncepcja dynamicznego udostępniania to najnowsze osiągnięcie.
Skalowanie dla pików
Wielu dostawców e-commerce po prostu zgaduje, jakie będą ich szczyty, a następnie pomnożymy to przez pięciu, aby dostosować ich środowiska produkcyjne. Sprzęt jest rozmieszczony statycznie i pozostaje bezczynny, z wyjątkiem kilku godzin w roku, w których zwiększa się do 20%. Głównym czynnikiem było zapewnienie 100% dyspozycyjności, ponieważ przestoje prowadzą do bezrobocia. Następnie należy zakupić sprzęt dla środowisk programistycznych i testowych, które rzadko są używane. Jest to bardziej odpowiednie dla większych dostawców niż dla mniejszych dostawców, którzy zwykle nie mają pieniędzy na zbudowanie tak wielu środowisk. Ponieważ ruch może być tak podatny na gwałtowne wzrosty, wielu dostawców e-commerce pomnaża swój rzeczywisty oczekiwany szczyt przez pięć, tak że szczyt zużywa tylko 20% procesora lub cokolwiek to jest czynnik ograniczający. Następnie większość konfiguruje kopię lustrzaną produkcji w innym fizycznym centrum danych na potrzeby odzyskiwania po awarii lub jako w pełni aktywne dodatkowe centrum danych. Oprócz produkcji istnieje wiele środowisk przedprodukcyjnych, z których wszystkie stanowią niewielką część produkcji. Każda gałąź kodu zazwyczaj wymaga własnego środowiska. Jest to dużo sprzętu! Przy normalnym ruchu produkcyjnym wymaganych jest tylko pięć serwerów (10% rzeczywistej wartości szczytowej 50 serwerów = 5). Środowiska programowania i kontroli jakości są rzadko używane, a jedynymi klientami są wewnętrzni testerzy kontroli jakości. Środowiska przejściowe są okresowo używane do testów obciążenia i dla kadry kierowniczej do podglądu funkcjonalności, ale to wszystko.
Przerwy spowodowane szybkim skalowaniem
Ponieważ stos jest tak niewykorzystany, gwałtowne skoki ruchu często powodują upadek całych platform. Testy obciążenia wykorzystują starannie przygotowane czasy rozruchu, które określają, jak szybko dodawani są klienci wirtualni. Po każdym okresie rampy platforma zawsze może się ustabilizować. Stabilizacja, znana również jako poziomowanie, ma na celu przywrócenie czasu systemu po obciążeniu nim dużym obciążeniem. Skuteczne kampanie w mediach społecznościowych, niewłaściwie wycenione produkty (np. 0,01 USD zamiast 100 USD), podmuchy e-maili, kupony / promocje, wzmianki w prasie i ważne premiery produktów mogą w krótkim czasie spowodować znaczny ruch do punktu, w którym może wyglądać rozproszony atak typu "odmowa usługi". Platformy nie mają okresów "wyrównania" w prawdziwym życiu.
Studium przypadku: wpadka cenowa firmy Dell
Tajwańska filia firmy Dell, www.dell.com.tw, przypadkowo ustawiła cenę jednego z 19-calowych monitorów na około 15 USD zamiast planowanej ceny na około 148 USD. Niepoprawna cena została zaksięgowana lokalnie o godzinie 23:00. W ciągu ośmiu godzin zakupiono 140 000 monitorów z prędkością około pięciu na sekundę. Ten gwałtowny wzrost ruchu powoduje tworzenie połączeń na każdej warstwie, co prowadzi do gwałtownego wzrostu ruchu i zużycia pamięci. Tworzenie połączeń jest kosztowne - dlatego wszystkie warstwy używają pewnego rodzaju puli połączeń. Ale nie ma sensu dysponować ogromnymi pulami połączeń, które są wykorzystywane tylko w kilku procentach. Połączenia i inne cięższe zasoby są zwykle tworzone na żądanie, co może prowadzić do awarii pod dużym obciążeniem. Oprogramowanie na ogół nie działa dobrze, gdy zostaje obciążone dużym obciążeniem.