na przykładzie Wikia
Architektura systemów webowych wysokiej przepustowości
Agenda● Czym jest Fandom powered by Wikia● Ogólny zarys architektury - warstwy systemu● Ścieżka obsługi przykładowego żądania● Monolit vs Mikroserwisy● Omówienie wybranych komponentów
○ Mesos oraz Consul○ Stos ELK○ Monitorowanie wydajności○ Alerting
● Proces zmiany kodu i wydania wersji○ Continuous Integration & Deployment
17
1Jesteśmy największą na świecie bazą artykułów o grach video
4Czwarci pod względem odwiedzin z urządzeń mobilnych
jesteśmy 17-stą najczęściej odwiedzaną stroną w USA
Ogólny zarys architektury
San JoseMain Data Center
RestonBackup Data Center
FastlyContent Delivery Network
Desktop Web UsersStatic HTML+JS
Mobile Web UsersSPA - JS
Android + iOS UsersAPI: HTML+JS
San Jose Data Center
BorderVarnish - Load Balancer
API GatewayNginx
HeliosOAuthGolang
New Microservice Stack (głównie Java)Np. services.wikia.com/discussions
API
MediaWiki Stack (głównie PHP)Np. fallout.wikia.com
HTML + API
MediaWikiApache + PHP
80 Servers
MySQLMaster + Slave
10 Clusters, 4 Servers per cluster
ConsulService
DiscoveryMesos + Marathon
Container Orchestration4 Servers
... ...
Service X
Ścieżka obsługi przykładowego żądaniahttp://www.fallout.wikia.com
● Fastly CDN Edge - zwróć z pamięci podręcznej, jeśli istnieje● Fastly CDN Shield - zwróć z pamięci podręcznej, jeśli istnieje● Wikia Border (load balancer) - wybierz jeden z serwerów apache z puli● Apache+PHP - generuj HTML
○ Pobierz zawartość artykułu z bazy■ Sprawdź czy wynik zapytania jest w memcached, jeśli tak zwróć■ Znajdź cluster z bazą danych i wyszuk hosta “slave” z bazą■ Pobierz dane z bazy i zaktualizuj pamięć podręczną w memcached
○ Pobierz inne dane konieczne do generowania artykułu z mikroserwisów○ Zapisz logi oraz dane o wydajności w Elasticsearch’u oraz InfluxDB
● Zapisz wynik w pamięci podręczne Fastly (Shield + Edge) oraz zwróć wynik użytkownikowi
● Przez JavaScript pobierz reklamy od zewnętrznych partnerów● Pobierz obrazki (optymalizacja formatów np. WebP)
Monolit vs Mikroserwisy● Monolit
○ Nasz ma 4 miliony linii kodu○ Problemy
■ Trudność w zarządzaniu i rozwijaniu■ Liczba powiązań wewnętrznych modułów
● Mikroserwisy○ Domain Driven Design○ Zoptymalizowane pod zastąpienie a nie pod ponowne użycie (replace v. reuse)
- można napisać od zera w tydzień○ Autonomiczne zespoły odpowiedzialne za cały cykl życia serwisu○ Skalowalność○ Chmura, większa elastyczność w użyciu sprzętu
https://mesosphere.com/
Zalety dynamicznego zarządzania usługami i użycia kontenerów● Łatwiejsze i szybsze skalowanie - brak konieczności fizycznego konfigurowania serwerów pod
konkretne usługi. Łatwiejsze uruchomienie nowych usług przez programistów, bez interakcji z administratorami systemu.
● Możliwość automatycznego skalowania usług w zależności od ruchu w danym momencie● Kontrola zdrowia usług, możliwość automatycznego zrestartowania (fault recovery)● Bardziej efektywne wykorzystanie fizycznych zasobów i tym samym obniżenie kosztów● Możliwość użycia dostępnych w internecie kontenerów z komponentami np. Bazami danych
https://www.consul.io/
● Service Discovery○ API○ DNS
● Zarządzanie konfiguracją
Zarządzanie Logami● ElasticSearch - Document Storage
○ Zoptymalizowane pod wyszukiwanie tekstu○ Brak sztywnej struktury○ Shardowanie i sterowanie retencją danych
● Logstash○ Zbiera Logi i zapisuje do ElasticSearch
● Kibana - UI Napisany w JavaScript
Logi - Stos ELK
Monitorowanie wydajnościDlaczego wydajność jest ważna?
Różne obszary pomiaru● Frontend● Backend
○ Poziom aplikacji○ Baza danych
● A/B Testy
Alerting● Kapacitor● PagerDuty
27 unikalnych serwisów, większość w więcej niż jednej instancji
50 percentyl czasu odpowiedzi
Proces zmiany kodu i wydania wersji● Jira - Tickety● Github - kontrola wersji kodu
○ Pull Request - code review● TDD - testy jednostkowe, integracyjne oraz Selenium● Jenkins
○ SonarQube - statyczna analiza kodu○ Ponowne uruchomienie testów
● Deployment○ Manualny○ Cykliczny○ Continuous Deployment
Pytania?
Thank you!
Top Related