Skaalbere applikaasje-ûntwerp sûnder magy

Gearfetting

As ûnderdiel fan de online app foar iten bestellen dy't ik bou, moast ik in skaalbere backend-ynfrastruktuer ûntwerpe dy't in protte brûkers tagelyk oankin. Skaalberens wurdt sjoen as in dreech probleem. Faak wurdt it presintearre as wie it wat magysk, dien troch miljoenebedriuwen dy't geheime ark brûke. Mar der is gjin magy, of is der wol?

Folsleine tekst

Wat is skaalberens?

As do in app boust, begjinst do wierskynlik hiel lyts. Mar in pear brûkers (of allinnich do, de programmeur) dy't mei de app wurkje. Alles is dan moai: de app wurket goed, rap en der binne gjin problemen. (Koester dit gefoel!)

Yn dit iere en lytse senario kin de iene server dy't de app draait, de brûker oan dy't der mei omgiet. Elke kear as de brûker op in knop tikket of klikt, docht de iene server wat wurk. As do goed programmearrest, kinne dizze wurklêsten optimalisearre wurde ta effisjinte brokken wurk. Dit sa dwaan is in typysk foarbyld fan in monolityske software-arsjitektuer.

Ek as dyn projekt of app frijwat lyts is, kin der op in stuit in stream brûkers komme. As dyn systeem gjin hege belêsting oankin, is de kâns op mislearring grut.

Troch it monolityske app-ûntwerp hawwe alle brûkers kontakt mei deselde server. Al har ynteraksje (tikken, klikken, ynfier) wurdt troch dizze server ôfhannele. Mei mear belêsting moat er in stik hurder wurkje. Op in stuit sjochst do dat dingen traach wurde, om't de server de hoemannichte wurk dy't er dwaan moat net by kin. Dat betsjut dat dyn app net goed skaalet, mei oare wurden: do sitst yn de problemen.

Mislearring op it 'momint supreme'

Net goed skaalje is in grut probleem dat nimmen ûnderskatte moat. De measte apps (en har bedriuwsmodellen) rekkenje op hege folumes mei in lyts bedrach oan ynkomsten per brûker. As do wolst dat dyn app in (finansjeel) sukses wurdt, moatst do derfoar soargje dat er goed wurket as der ynienen in soad mear ferkear is. As dyn app delstoart op it momint dat er ynienen de oandacht fan de massa kriget, mist do in 'ienris-yn-in-libben'-kâns foar (organyske) groei.

In bepaalde sin is ûntwerpe foar skaalberens as dyn feiligensriem fêst hâlde as do yn dyn sels boude romteskip sitst, mei eksperimintele motoren. Do witst nea krekt wannear't er ûntstekt, mar as dat bart, hast do der better foar soarge dat do fêst sitst (en fan de rit genietest!).

Gongbere wizen om skaalberens te berikken

Der is in soad skreaun oer it bouwen fan skaalbere apps, gongbere wizen om skaalberens te ferbetterjen binne:

• De kapasiteit fan de server ferheegje: mear ûnthâld, CPU-krêft en opslach tafoegje. Dit wurket, mar bringt dy mar 'safier'.
• Mear servers tafoegje: yn plak fan ien server dy't as flessehals wurket, kinst do mear servers tafoegje dy't de wurklast diele. Dat is makliker sein as dien, want it fereasket loadbalancing en dielen fan gegevens, wat lestich wêze kin (bygelyks as do in bestellingsteller hast en twa servers tellen, hokker bepaalt dan it folgjende nûmer?)
• De programmakoade optimalisearje: brûk de goeie ark! Kies in programmeartaal en serversoftware dy't op prestaasje rjochte binne. Sjoch nei funksjoneel programmearjen, sadat dyn koade asynchroon op meardere kearnen draaie kin. Meitsje it steatleas. Benchmark it. Optimalisearje it. Elke tûzenste fan in sekonde dy't do op ien fersyk wynst, telt gau op as do grutte folumes ôfhannelest.
• Brûk de databank en skied dy fan de applikaasjeserver: As do in databank brûkst, brûk dan syn krêft! Meitsje gebrûk fan query-caching, yndeksen en sykfunksjes. De measte databankoplossingen biede bewiisd betroubere klusteropsjes; besykje it tsjil net út te finen dat oaren al perfekt makke hawwe.

It bêste wat do dwaan kinst is al dizze opsjes te beskôgjen. Ek as do net daliks mear servers tafoegest, moatst do dyn koade skriuwe sadat dat letter kin. Benchmarking en it optimalisearjen fan dyn koade moatte in yntegraal diel fan dyn wurk wêze, net allinnich in neitocht.

De rekkenkrêft fan de klant brûke

As do alle gongbere wizen om skaalberens te berikken beskôge hast, is der "noch ien ding".

Mar in pear programmeurs tinke hjir oan: it skaalberensprobleem befettet de oplossing! As do 1000 brûkers hast, hast do 1000 kompjûters mei krêftige CPU's en in protte ûnthâld. Moderne kompjûters en smartphones binne hieltyd betûfter wurden.

Do moatst gewoan in wei fine om de rekkenkrêft fan de klant oan te tapjen. Hoewol it klinkt as wat ferkeards (de rekkenkrêft fan de brûker brûke), jout it har in folle bettere, rappere ûnderfining. It bêste is dat har rekkenkrêft bestege wurdt oan har fantastyske ûnderfining, wêrby't dyn skaalberensprobleem as noflike bysaak oplost wurdt.

Troch de rekkenkrêft fan de brûker te brûken, ferminderest do de hoemannichte wurk dy't de server dwaan moat. Yn plak dat de server elke kear as de brûker op in knop tikket of klikt in bytsje wurk docht, wurdt dit wurk no foaral dien troch it apparaat fan de brûker. Dat is effisjinter as kommunisearje oer in Wifi/4G-ferbining mei in server (it kostet minder batterij en tiid).

It freget wat opnij neitinke, mar dit prinsipe kin ek tapast wurde op webapplikaasjes. Yn plak fan alles op de server ôf te hanneljen, kinst do in soad wurk op de klant dwaan. Dingen as sykje, blêdzje, filterje, navigearje en sels dingen yn in winkelwein dwaan kinne dien wurde mei JavaScript oan de klantkant. Do - leave programmeur - moatst wizen sykje om dit wurkjend te krijen, mar as it slagget hast do sa goed as ûneinige skaalberens binnen hânbereik.

Yn de praktyk: app foar iten bestellen

Foar de app foar iten bestellen socht ik nei manieren om de rekkenkrêft fan de klant te brûken foar hege prestaasjes. De grutte útdaging by leveringen en meinimbestellingen is dat se it drokst binne om etenstiid hinne. In soad minsken brûke de app sawat tagelyk, en dat is in resept foar skaalberensproblemen.

As do tinkst oan online iten bestellen, kinst it hiele proses yn lytsere brokken opdiele:

• 1) De side iepenje: de app/side lade
• 2) De ferskillende opsjes trochblêdzje: de produkten, har beskriuwingen, prizen, foto's, ensfh. sjen
• 3) Sykje nei wat spesifyks: sykje op kategory, produktnamme, ensfh.
• 4) In produkt kieze: it oan dyn bestelling tafoegje
• 5) In produkt oanpasse: in saus, in byrjocht, in topping, ensfh. kieze.
• 6) Dyn gegevens ynfiere: dyn namme, tillefoannûmer, leveringsgegevens, ensfh.
• 7) Dyn bestelling betelje: in betelmetoade kieze, ferbine mei dyn bank of kredytkaart
• 8) De app slute

De measte fan dizze stappen kinne sa programmearre wurde dat de server net nedich is. Allinnich stap 1 (laden) en stap 7 (betelje) fereaskje kontakt mei de backend-ynfrastruktuer. It is wichtich om te beseffen dat stap 2 oant 5 meardere kearen werhelle wurde, want it is gewoan dat brûkers meardere produkten oan har bestelling tafoegje.

Troch de oerbleaune wurklast per taak te skieden kin de software fierder optimalisearre wurde. De "produktserver" is optimalisearre om statyske bestannen (teksten, prizen, ôfbyldingen) te leverjen wêrmei't de klant de ûnderfining fan it trochblêdzjen fan produkten oanmeitsje kin. Dit soarte server kinst do tige optimalisearje, troch gebrûk fan caching, HTTP/2, kompresje, ensfh.

Allinnich de brûkers dy't it bestelproses foltôgje, wurde trochjûn nei de "bestelserver" dy't de betelling ôfhannelet. Dy makket ferbining mei de betelprovider. Sadree't in betelling foltôge is, nimt de betelprovider kontakt op mei de bestelserver om him te ynformearjen oer de betelstatus. Dit is wat do folslein (oan de serverkant) yn eigen hân hawwe wolst, lykas ik die doe't ik earder in betelsysteem ûntwurp. De oerbleaune wurklast op de "bestelserver" is folle lytser, want net elkenien pleatst in bestelling, en in protte fan it ferwurkjen fan bestellingen kin op de eftergrûn dien wurde.

Om skaalberens te maksimalisearjen kinst do maklik meardere servers tafoegje (of in content delivery network brûke) om de statyske bestannen te leverjen. Foar de app foar iten bestellen brûk ik in aparte "produktserver" per restaurant. Dat soarget foar hege prestaasjes en koartere laadtiden. Minsken fernimme dat it rap is, guon kinne net leauwe dat it webtechnology is, it is hast magysk.

Konklúzje

In skaalbere applikaasje ûntwerpe kin sûnder magy of budzjetten fan miljoenen. Do moatst it gewoan trochtinke en sykje nei de kânsen dy't har oanbiede tegearre mei de útdagings.

It probleem befettet de oplossing. In soad brûkers tagelyk is net allinnich in probleem: se bringe har eigen rekkenkrêft mei, dat is de oplossing! Do moatst it mar brûke.