Co powinienem zrobić, aby skalować witrynę o dużym ruchu?

Jakie najlepsze praktyki należy podjąć w przypadku strony internetowej, która musi zostać „skalowana”, aby obsłużyć pojemność? Jest to szczególnie istotne teraz, gdy ludzie zastanawiają się nad chmurą, ale może brakować podstaw.

Chciałbym usłyszeć o wszystkim, co uważasz za najlepszą praktykę, od zadań na poziomie programistycznym, przez infrastrukturę, aż po zarządzanie.

Projekt dla współbieżności

Oznacza to, że podczas kodowania planuj uruchomienie wielu wątków. Zaplanuj stan współdzielony (często tylko db). Zaplanuj wiele procesów. Zaplanuj rozkład fizyczny.

Umożliwia to dystrybucję systemu na wielu komputerach i na wielu procesach z równoważeniem obciążenia. Pozwala to na uruchomienie nadmiarowych procesów w przypadku awarii, aw przypadku konieczności modyfikacji systemu w miejscu, nie musisz zabijać wszystkich usług, aby to zrobić.

Kilka rzeczy, które możesz rozważyć:

• Oddzielanie stron zapisu i odczytu danych.
  
  • CQRS / Sourcing zdarzeń
  • CQS
  • Przekazywanie wiadomości / aktorzy
• Unikanie wspólnego procesu i stanu wątku
  • Stąd unikanie blokowania
  • Można tego uniknąć dzięki systemowi typów, tworząc klasy, struktury i inne typy danych, które będą niezmienne, tzn. Nie ulegną zmianie po zbudowaniu. Zwłaszcza w przypadku złożonych abstrakcyjnych typów danych działa zaskakująco dobrze (np. Implementacja jQuery)
• Nie blokuje wątków serwera WWW na IO. Jeśli używasz ASP.Net, użyj asynchronicznych stron / akcji z biblioteką wzorców / zadań równoległych APM (TPL)
• Nie zapisywanie obciążeń stanu w słowniku sesji użytkownika
  • Należy to przenieść między wątkami, gdy migracja wątków występuje w IIS.
  • Posiadanie inteligentnego routingu, takiego, że niezabezpieczone / statyczne zasoby nie są obsługiwane w tej samej strukturze aplikacji (np. ASP.Net), która dodaje koszty ogólne. Spójrz na przykład na różne serwery sieciowe.
• Pisanie kodu przekazywania kontynuacji przy użyciu asynchronicznego wzorca przepływu pracy (np. Bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Użyj teorii kolejkowania, aby obliczyć, gdzie mogą wystąpić wąskie gardła
• Używaj aktualizacji push-pull zamiast pull-read-modeli i innych stanów aplikacji. Np. Przez RabbitMQ / nServiceBus
• Użyj najmniejszej funkcji „procedury obsługi http”
• W przypadku plików statycznych podaj e-tagi i zasady wygasania pamięci podręcznej, aby umożliwić infrastrukturę sieciową działanie tak, jak powinno (np. Z kałamarnicą proxy)
• (Zatrudnij mnie, aby rozwiązać problemy ze skalowaniem i uzyskać samouczki na miejscu;))

Udostępnij architekturę Nic.

Mając to na uwadze i wbrew pozorom, nie od razu przejdź do rozwiązania skalowalnego w poziomie. Narzut poza systemem a wywołanie wewnątrz systemu nie powinny być niedoważone. Na przykład nawiązanie połączenia DB w dowolnym interfejsie sieciowym trwa dużo dłużej niż w przypadku połączenia lokalnego. Budżetuj ile czasu potrzeba na zarządzanie, zasilanie i strojenie potrzebne do skalowania w stosunku do dodatkowych $ za prawdziwy duży system.

Niezależnie od tego, nadal mam wielką wartość w architekturze „nic nie udostępniaj” i możesz warstwować i skalować swoje systemy, gdy przyjdzie czas.

Równoległe żądania z kilku nazw hostów

Część standardu HTTP to sekcja, która mówi, że webclients zażądają maksymalnie 2 sesji na hosta DNS. Oto rozwiązanie, w którym ty i twój alias twoja www.domain.com otrzymujesz wyższą współbieżność żądań, dzięki czemu Twoja strona ładuje się szybciej:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

Zasadniczo wymaga edycji programu obsługi HTTP ASP.NET na przemian z hostami docelowymi, do których wysyłasz klientów, gdzie każdy host to CNAME na „www”.

Bezpieczny, szybki, niezawodny DNS

Znalazłem kilka witryn o dużej pojemności, korzystających z serwera DNS rejestratora, który nie miał SLA na czas działania ani wydajność. Ponadto ich serwery znajdowały się w Indiach, a samo opóźnienie zwiększa ryzyko, że spoofer DNS może zatruć pamięć podręczną klienta lub pośredniego dostawcę usług internetowych. Spowodowałoby to przekierowanie nawet twojego ruchu chronionego SSL bez wiedzy.

Szybkość DNS wpływa również na początkowy czas ładowania serwera, zanim rekordy zostaną buforowane.

Używam DynDNS lub Neustar do większości moich klientów, ponieważ mają dość solidną infrastrukturę DNS (chociaż jest to droga i nie mam innych powiązań z tymi firmami).

Myślę, że klucz będzie prosty:

Mieć prosty kod. To oznacza coś, na co patrzysz i rozumiesz. Rozwijając i zmieniając serwery, musisz wiedzieć, co się dzieje. Konieczne może być także dodanie koderów, którzy muszą szybko zrozumieć. Haki i pliki XML, które wywołują losowy kod, który nie jest oczywisty, są bardzo złe.

Następnie możesz przetestować i znaleźć problemy.

Zajrzyj tutaj: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

W Stellarbuild staramy się, aby nasze strony skalowały się bez przestojów. Oznacza to, że musisz wiedzieć, co robi Twój kod i gdzie to robi. Nawet jeśli testujesz inną maszynę, skalowanie nie może zająć zbyt długo. Niestety większość ludzi zaczyna dopiero wtedy, gdy jest już za późno. Moim zdaniem możesz zoptymalizować tylko raz, gdy to zrobisz.