Vill Startups sinn duerch dëst gaang: Vill vun neie Benotzer registréieren all Dag, an d'Entwécklungsteam kämpft fir de Service weider ze halen.
Et ass e flotte Problem ze hunn, awer et gëtt wéineg kloer Informatioun um Internet iwwer wéi een eng Webapplikatioun suergfälteg aus näischt op Honnerte vun Dausende vu Benotzer skala kann. Typesch ginn et entweder Feierléisungen oder Flaschenhalsléisungen (an dacks béid). Dofir benotze d'Leit zimlech cliched Techniken fir hiren Amateurprojet an eppes wierklech eescht ze skaléieren.
Loosst eis probéieren d'Informatioun ze filteren an d'Basisformel opzeschreiwen. Mir wäerten eisen neie Foto-Sharing Site Graminsta Schrëtt fir Schrëtt vun 1 op 100 Benotzer skaléieren.
Loosst eis opschreiwen wéi eng spezifesch Handlunge musse gemaach ginn wann d'Publikum op 10, 100, 1000, 10 an 000 Leit eropgeet.
1 Benotzer: 1 Maschinn
Bal all Applikatioun, sief et eng Websäit oder eng mobil Applikatioun, huet dräi Schlësselkomponenten:
- API
- Datebank
- Client (mobil Applikatioun selwer oder Websäit)
D'Datebank späichert persistent Daten. D'API servéiert Ufroen un a ronderëm dës Donnéeën. De Client iwwerdréit Daten un de Benotzer.
Ech sinn zur Conclusioun komm datt et vill méi einfach ass iwwer d'Skaléierung vun enger Applikatioun ze schwätzen, wann aus architektonescher Siicht de Client an d'API Entitéite komplett getrennt sinn.
Wa mir als éischt ufänken eng Applikatioun ze bauen, kënnen all dräi Komponenten um selwechte Server lafen. Op e puer Weeër ass dëst ähnlech wéi eis Entwécklungsëmfeld: een Ingenieur leeft d'Datebank, API a Client op der selwechter Maschinn.
An der Theorie kënne mir et an der Wollek op enger eenzeger DigitalOcean Droplet oder AWS EC2 Instanz ofsetzen, wéi hei ënnendrënner:
Mat deem gesot, wann et méi wéi ee Benotzer op engem Site gëtt, mécht et bal ëmmer Sënn fir eng Datebankschicht ze widmen.
10 Benotzer: d'Datebank op e separaten Niveau réckelen
D'Datebank opzedeelen a verwaltete Servicer wéi Amazon RDS oder Digital Ocean Managed Database wäert eis fir eng laang Zäit gutt déngen. Et ass e bësse méi deier wéi Self-Hosting op enger eenzeger Maschinn oder EC2 Instanz, awer mat dëse Servicer kritt Dir vill nëtzlech Extensiounen aus der Këscht, déi an der Zukunft praktesch kommen: Multi-Regioun Backup, Lies Repliken, automatesch Backups, a méi.
Dëst ass wéi de System elo ausgesäit:
100 Benotzer: Plënneren de Client op eng separat Niveau
Glécklecherweis hunn eis éischt Benotzer eis Applikatioun wierklech gär. Den Traffic gëtt méi stabil, also ass et Zäit de Client op e separaten Niveau ze réckelen. Et soll feststellen, datt Trennung Entitéiten ass e Schlëssel Aspekt vum Bau vun enger skalierbarer Applikatioun. Wéi een Deel vum System méi Traffic kritt, kënne mir et opdeelen fir ze kontrolléieren wéi de Service skaléiert baséiert op spezifesche Verkéiersmuster.
Dofir denken ech gär un de Client als separat vun der API. Dëst mécht et ganz einfach iwwer d'Entwécklung fir verschidde Plattformen ze denken: Web, mobil Web, iOS, Android, Desktop Uwendungen, Drëtt Partei Servicer, etc.. Si sinn all just Clienten déi déiselwecht API benotzen.
Zum Beispill, elo froen eis Benotzer meeschtens eng mobil Applikatioun ze verëffentlechen. Wann Dir de Client an API Entitéiten trennt, gëtt dëst méi einfach.
Dëst ass wéi esou e System ausgesäit:
1000 Benotzer: Füügt Lastbalancer derbäi
D'Saachen kucken op. Graminsta Benotzer lued ëmmer méi Fotoen erop. D'Zuel vun den Aschreiwungen wiisst och. Eis eenzegen API Server huet et schwéier mat all de Traffic ze halen. Braucht méi Eisen!
Load Balancer ass e ganz mächtegt Konzept. D'Schlësselidee ass datt mir e Lastbalancer virun der API setzen, an et verdeelt Traffic op eenzel Serviceinstanzen. Dëst ass wéi mir horizontal skaléieren, dat heescht datt mir méi Servere mam selwechte Code addéieren, wat d'Zuel vun den Ufroen erhéijen déi mir kënne veraarbechten.
Mir setzen getrennte Lastbalancer virum Web Client a virun der API. Dëst bedeit datt Dir verschidde Instanzen ausféiere kënnt mat API Code a Web Client Code. De Lastbalancer leet Ufroe un de Server dee manner gelueden ass.
Hei kréie mir en anere wichtege Virdeel - Redundanz. Wann eng Instanz feelt (vläicht iwwerlaascht oder erofgefall), si mir mat aneren hannerlooss déi weider op erakommen Ufroe reagéieren. Wann et nëmmen eng Instanz funktionnéiert, dann am Fall vun engem Echec de ganze System Crash.
De Lastbalancer bitt och automatesch Skala. Mir kënnen et konfiguréieren fir d'Zuel vun Instanzen virun der Spëtzbelaaschtung ze erhéijen, a se erofsetzen wann all Benotzer schlofen.
Mat engem Lastbalancer kann den API Niveau bal onbestëmmt skaléiert ginn, einfach nei Instanzen bäizefügen wéi d'Zuel vun den Ufroen eropgeet.
Note. De Moment ass eise System ganz ähnlech wéi PaaS Firmen wéi Heroku oder Elastic Beanstalk op AWS offréieren aus der Këscht (dofir si se sou populär). Heroku setzt d'Datebank op engem getrennten Host, geréiert en Auto-Scaling Lastbalancer, an erlaabt Iech de Web Client separat vun der API ze hosten. Dëst ass e super Grond Heroku fir fréi Etapp Projeten oder Startups ze benotzen - Dir kritt all Basis Servicer aus der Këscht.
10 Benotzer: CDN
Vläicht hätte mer dat vun Ufank un gemaach. Veraarbechtung vun Ufroen an akzeptéieren nei Fotoen fänkt un eis Serveren ze vill Belaaschtung aus.
Op dëser Etapp musst Dir e Cloud-Service benotzen fir statesch Inhalt ze späicheren - Biller, Videoen a vill méi (AWS S3 oder Digital Ocean Spaces). Am Allgemengen, sollt eis API vermeiden Saachen ze handelen wéi Biller ze servéieren an Biller op de Server eropzelueden.
En anere Virdeel vu Cloud Hosting ass den CDN (AWS nennt dësen Add-on Cloudfront, awer vill Cloud Storage Ubidder bidden et aus der Këscht). D'CDN cache automatesch eis Biller a verschiddenen Datenzentere ronderëm d'Welt.
Och wann eisen Haaptrechenzenter an Ohio läit, wann iergendeen e Bild aus Japan freet, mécht de Cloud Provider eng Kopie an späichert et an hirem japanesche Rechenzentrum. Déi nächst Persoun, déi dëst Bild a Japan freet, kritt et vill méi séier. Dëst ass wichteg wa mir mat grousse Dateien schaffen, wéi Fotoen oder Videoen, déi laang daueren fir erofzelueden an iwwer de Planéit ze vermëttelen.
100 Benotzer: Skala vun der Dateschicht
CDN huet vill gehollef: Traffic wiisst mat voller Geschwindegkeet. De berühmte Videoblogger Mavid Mobrick huet sech just bei eis registréiert a seng "Geschicht" gepost, wéi se soen. Dank dem Lastbalancer gëtt d'CPU an d'Erënnerungsverbrauch op den API Server niddereg gehal (zéng API Instanzen lafen), awer mir fänken un vill Timeouts op Ufroen ze kréien ... wou kommen dës Verspéidungen hier?
Gruef e bëssen an d'Metriken, gesi mir datt d'CPU um Datebankserver 80-90% gelueden ass. Mir sinn op der Grenz.
D'Skaléierung vun der Dateschicht ass wahrscheinlech dee schwieregsten Deel vun der Equatioun. API Server déngen stateless Ufroen, sou datt mir einfach méi API Instanzen bäidroen. Nues d'Majoritéit Datenbanken kënnen dat net maachen. Mir schwätzen iwwer populär relational Datebankmanagementsystemer (PostgreSQL, MySQL, etc.).
cachen
Ee vun den einfachste Weeër fir d'Performance vun eiser Datebank z'erhéijen ass eng nei Komponent aféieren: d'Cache-Schicht. Déi meescht üblech Cachingmethod ass en In-Memory Schlësselwäert Rekordgeschäft, wéi Redis oder Memcached. Déi meescht Wolleke hunn eng verwaltet Versioun vun dëse Servicer: Elasticache op AWS an Memorystore op Google Cloud.
E Cache ass nëtzlech wann e Service vill widderholl Uruff un d'Datebank mécht fir déiselwecht Informatioun ze recuperéieren. Am Wesentlechen kréien mir nëmmen eemol Zougang zu der Datebank, späicheren d'Informatioun am Cache, a beréieren se net erëm.
Zum Beispill, an eisem Graminsta Service, all Kéier wann een op d'Profil Säit vum Star Mobrik geet, freet den API Server d'Datebank fir Informatioun aus sengem Profil. Dëst geschitt ëmmer erëm. Zënter dem Mobrik seng Profilinformatioun ännert sech net mat all Ufro, ass et exzellent fir Cache.
Mir Cache d'Resultater vun der Datebank am Redis duerch Schlëssel user:id mat enger Validitéit Period vun 30 Sekonnen. Elo, wann een op de Profil vum Mobrik geet, kontrolléiere mir als éischt Redis, a wann d'Donnéeën do sinn, transferéiere mir se einfach direkt vu Redis. Elo Ufroe fir de beléifste Profil um Site praktesch net eis Datebank lueden.
En anere Virdeel vun de meeschte Caching-Servicer ass datt se méi einfach si ze skaléieren wéi Datebankserver. Redis huet en agebaute Redis Cluster Modus. Ähnlech wéi e Lastbalancer, et erlaabt Iech Äre Redis Cache iwwer verschidde Maschinnen ze verdeelen (iwwer Dausende vu Serveren wann néideg).
Bal all grouss-Skala Uwendungen benotzen Caching; et ass en absolut integralen Deel vun enger séier API. Méi séier Ufroveraarbechtung a méi produktiv Code sinn all wichteg, awer ouni Cache ass et bal onméiglech fir e Service op Millioune Benotzer ze skaléieren.
Liest Repliken
Wann d'Zuel vun den Ufroen an d'Datebank immens eropgaang ass, ass eng méi Saach déi mir maache kënnen, gelies Repliken am Datebankmanagement System ze addéieren. Mat den uewe beschriwwene verwalteten Servicer kann dëst an engem Klick gemaach ginn. Déi gelies Replik bleift aktuell an der Haaptdatenbank an ass fir SELECT Aussoen verfügbar.
Hei ass eise System elo:
Nächst Schrëtt
Wéi d'Applikatioun weider Skala gëtt, wäerte mir weiderhin d'Servicer trennen fir se onofhängeg ze skaléieren. Zum Beispill, wa mir ufänken Websockets ze benotzen, da mécht et Sënn fir de Websockets Veraarbechtungscode an e separaten Service ze zéien. Mir kënnen et op nei Instanzen hannert eisem eegene Lastbalancer placéieren, deen op an erof kanaléiere baséiert op oppene Websockets Verbindungen an onofhängeg vun der Unzuel vun HTTP-Ufroen.
Mir wäerten och weider Restriktiounen um Datebankniveau bekämpfen. Et ass op dëser Etapp datt et Zäit ass d'Datebankpartitionéierung an d'Sharding ze studéieren. Béid Approche erfuerderen zousätzlech Overhead, awer erlaben Iech d'Datebank bal onbestëmmt ze skaléieren.
Mir wëllen och en Iwwerwaachungs- an Analyseservice wéi New Relic oder Datadog installéieren. Dëst hëlleft Iech lues Ufroen z'identifizéieren an ze verstoen wou Verbesserung gebraucht gëtt. Wéi mir skaléieren, wëlle mir eis fokusséieren op Flaschenhals ze fannen an se ze eliminéieren - dacks benotzt e puer vun den Iddien aus de fréiere Sektiounen.
Quellen vun Informatiounen
Dëse Post ass vun engem vun inspiréiert . Ech wollt den Artikel e bësse méi spezifesch fir déi initial Etappe vu Projeten maachen an et vun engem Verkeefer ofschléissen. Gitt sécher ze liesen wann Dir un dësem Thema interesséiert sidd.
Foussnoten
- Och wann ähnlech wat d'Laaschtverdeelung iwwer verschidde Fäll ugeet, ass déi ënnerierdesch Implementatioun vun engem Redis Cluster ganz anescht wéi e Lastbalancer.
Source: will.com