Jag har varit borta från webbutveckling i ett antal år.
Ärligt talat har det varit en trevlig upplevelse: inga "irriterande" kundförfrågningar, inga oändliga ändringar och omskrivningar, bara viktiga saker (TM).
Skojar bara förstås, men systemprogrammering är verkligen annorlunda. En av de avgörande egenskaperna för sådan utveckling är att din app helt enkelt ska fungera, aldrig sluta fungera, återställa sig automatiskt vid fel och logga alla intressanta problem automatiskt. Tänk, det är en bra idé att ha det överallt, eller hur?
Jag är inte alls någon front-end-kille, så vi begränsar oss till huvudrätten/grunden, en typisk trenivåapp, kanske bara med några nyanser av mikrotjänster, REST API:er, etc. Var inte rädd för akronymerna – de som nämns ovan betyder bara att vår applikation använder HTTP, det moderna internets lingua franca , och ibland använder en databas eller andra tjänster/applikationer (återigen via HTTP).
Vi har massor av valmöjligheter här. Jag tror inte att man kan göra ett fel val.
Mitt första val skulle vara Python, ett ganska populärt och lättillgängligt språk. Det är inte det snabbaste revolvermannen i väst, men det gör jobbet och är ganska skonsamt för både ögon och hjärna.
Andra populära språk fungerar utmärkt – det finns gott om utvecklare inom JavaScript, Go, Ruby, Java, C# och modernt PHP (har jag berättat skämtet om erfarna PHP-utvecklare?). Se bara till att du och ditt team behärskar språket väl och att det passar bra för problemområdet.
Jag har en bekännelse att göra. När jag sa att Python är mitt förstahandsval ljög jag, berätta det inte för någon. Nu för tiden försöker jag använda Rust till nästan allt. Smärta och lidande är aldrig omodernt , och det verkar finnas många människor som jag, med Stockholmssyndromet , som älskar Rust. Det är verkligen en galen värld.
Full metal jacket -utveckling är inget för den räddhågsne, men jag skulle ändå föreslå att alla provar konstiga eller exotiska språk. Programmering med Rust, Lisp/Clojure, Haskell, Prolog förändrar verkligen ditt perspektiv och muterar hur du programmerar i ditt favoritspråk.
Du frågar mig om ramverk? Hitta de 3 mest populära för ditt språk, välj vilket som helst, och livet kommer att bli bra.
De flesta användbara applikationer behöver lagra data någonstans. Ibland räcker det med vanliga filer, men så fort ditt samtidighetsnummer är större än ett blir det tråkigt att läsa/skriva/låsa (filer).
Så du go går vidare och väljer antingen ett klassiskt RDBMS, en modern NoSQL-databas, en dokumentdatabas eller någon leverantörs- eller molnspecifik produkt som är utformad för att likna något av ovanstående.
Och nu har du gjort ditt första misstag. Du förstår, även om val av programmeringsspråk verkar viktigt, är det faktiskt data som är kungen. Framgångsrika applikationer/projekt lagrar så mycket data, och den informationen är så viktig att den trumfar allt annat. Du kommer att hållas som gisslan av datan.
Utöver det finns det en inneboende koppling mellan data och hur du behöver programmera din app. Hoppas det inte bara är min fantasi .
Om jag inte vet något specifikt om hur min app kommer att fungera, skulle jag välja klassisk RDBMS, nämligen PostgreSQL. Det är ett härligt databassystem med en lång historia och gott rykte (det är mer än 25 år gammalt och det har ständigt ökat i popularitet under det senaste decenniet).
Om jag behöver använda en värdtjänst skulle jag använda en PostgreSQL-baserad/kompatibel tjänst, eftersom det borde vara enkelt att flytta data till ett annat PostgreSQL-system.
Datorer och program är uppbyggda av delar/lager med olika hastighet. Förutom att köpa snabbare datorer och koda snabbare algoritmer (lycka till med det) finns det bara en sak du kan göra – fuska! Undvik att arbeta eller cacha saker. Förvara det praktiska bordet under kudden.
Är cachen verkligen en nödvändig del av en pålitlig app? Absolut! Du behöver inte använda den direkt, men du bör aldrig missa möjligheten att snabba upp saker med lite cache. Det är inte så svårt. En välbevarad hemlighet är att när ditt program är långsamt, under stress, blir det opålitligt. Det finns många exempel där bra applikationer blir skräp bara för att de inte var tillräckligt snabba, inte kunde hålla jämna steg eller skala (horisontellt eller vertikalt). Allt eftersom din applikation växer kan prestanda bli en viktig funktion!
Det finns faktiskt många program-/applager där cachning är möjlig, uppslagstabeller, knep för funktionsmemoisering , privata cacher i minnet, Redis/Memcached, HTTP-cachning (Nginx), REST API-mikrocache (Nginx, HAProxy, Envoy) etc.
Du kände redan till de tidigare ingredienserna, men det här är förmodligen något nytt. Du kanske inte är medveten om det, men om du driftsätter din app i ett av de populära molnen använder du redan en proxy framför din app, kanske till och med "inuti", om du är en Kubernetes-person (jag måste erkänna att jag inte är det). Dessa proxyservrar exponerar bara en mycket begränsad uppsättning funktioner, och det finns mycket mer att utforska och använda. Vi ska utforska våra alternativ och några idéer för användning med HAProxy , en av de äldsta, snabbaste och mest mångsidiga proxyservrarna som finns. Det finns andra proxyservrar som kan användas när situationen kräver det:
HAProxy har så många funktioner att man allvarligt kan fundera på att beräkna dess Schwarzschild-radie. Ingen levande människa känner till allt HAProxy-material längre (för att citera dess skapare Willy Tarreau). Konfigurationsspråket är något obskyrt men koncist; åtminstone är det inte någon YAML-skräck.
Med allt ovanstående sagt är den fortfarande den bästa av de bästa. Den kan hantera Layer 4 (TCP) eller Layer 7 (HTTP) trafik, den använder TLS/SSL, har det största urvalet av lastbalanseringsalgoritmer, den har några knep för populära databaser (MySQL, PostgreSQL, Redis), du kan till och med lära den nya knep via binära kontroller, Lua-skript, etc. Den kan tillförlitligt logga din trafik, skugga trafiken, passivt och aktivt övervaka/observera HTTP-trafik…
Ytterligare ett område där en proxy kan hjälpa till i dina mikrotjänstorienterade eller distribuerade applikationer är att tillämpa DRY-principen. En proxy kan tillhandahålla tjänster som loggning, autentisering och transformation, så att du inte behöver implementera samma saker om och om igen för varje mikrotjänst (detta är särskilt viktigt om dina mikrotjänster inte är skrivna i samma språk eller ramverk).
Vi ska försöka presentera några idéer i följande avsnitt.
Denna introduktion är en del av en serie "recept" (essäer) som utforskar sätten att bygga pålitliga applikationer med (HA)Proxy.
Essäerna är kategoriserade enligt följande:
1. Club sandwich + Double PostgreSQL — Löser problem med fler lager
2. TLS Calzone + Wrap Crispy JWT — Autentisering på gränsen
3. ”Docker ” Cake + ”Say my name ” — Logga in och reda ut tvivel
4. Service Discovery-glass — Den långa och slingrande vägen till K8s
5. Belgisk OLAP-kub — Vänd på steken vid fel med shards
Jag hoppas att du finner dem användbara i ditt dagliga arbete.
Klicka nedan för att läsa den första essän, och under tiden – om du har några frågor: var inte blyg, hör av dig via kommentarsfältet.
Klicka här för att börja med del 1 .
