Hos Jitterbit er vores mission at forenkle selv de mest komplekse forbindelsesudfordringer og give enhver mulighed for at blive forbundet i nutidens digitale verden. Selvom vi understreger, at du ikke behøver at være en udvikler for at bruge Jitterbits produkter – bag enhver fantastisk softwareløsning er et team af fantastiske udviklere. I Jitterbit Tech Talk blog serien giver medlemmer af Jitterbit-udviklingsteamet os indsigt i at bygge en cloudplatform i virksomhedsklassen og de udfordringer, de skulle løse omkring multi-lejemål, skalerbarhed og sikkerhed.
I denne uge ser Pankaj Arora, vores seniordirektør for teknologi, på, hvordan du designer og arkitekterer en meget skalerbar cloudplatform i virksomhedsklassen.
Skyen tilbyder virksomheder en effektiv måde at tilbyde deres produkter og tjenester, som er nemme at få adgang til fra hvor som helst og på enhver enhed. Det giver også store fordele for leverandøren, herunder synlighed i, hvordan deres tilbud bruges, hurtig udvikling og implementering og overordnede reduktioner i it- og vedligeholdelsesomkostninger. Som et resultat, næsten hver company i dag søger at gøre deres løsninger tilgængelige i skyen.
Men der er meget mere til at blive en sand sky company end at installere software på en hostet server og smække "Cloud" på dit marketingmateriale.
Jeg chattede for nylig med en teknologistrateg, og de bemærkede, at omkring 75 % af virksomhederne gerne vil migrere deres gamle virksomhedstilbud til skyen. Overraskende nok udarbejder 90 % af dem en indledende plan, der ville blive bygget på en arkitektur, hvor deres ældre applikationer bare ville blive implementeret på en offentligt tilgængelig cloud-server. Denne tilgang ophæver alle de fordele, som skyen har at tilbyde.
Opbygning af en ægte multi-tenant Cloud-platform kræver løsning af en række forskellige slags udfordringer såsom sikkerhed, pålidelighed, skalerbarhed, høj tilgængelighed, fejltolerance, logning, overvågning, notifikationssystem, mulighed for kontinuerlig implementering og mere.
I dagens indlæg vil vi se dybere på, hvordan vi håndterede 'skalerbarheds'-udfordringen, da vi udviklede vores multi-tenant cloud-integrationsplatform.
Omfanget af skalerbarhed af en applikation er bundet til dens evne til at skalere lodret og vandret. I et cloud-miljø betyder det at designe tjenester, der betjener eksterne anmodninger, der skaleres, så de kan udnytte interne backend-systemer såsom databaser, caches, mediator-lag, batch-processer (analytisk motor, anbefalingsmotor) osv. til at håndtere praktisk talt uendelige anmodninger på en rimelig måde kort tid. Det er ikke altid muligt at forudsige antallet af brugere, der rammer din platform. At designe en arkitektur, der tager højde for dette i multi-tenancy-modellen, er med til at gøre denne usikkerhed til et generisk skalerbarhedsproblem.
Lodret skalering
Vertikal skalerbarhed involverer tilføjelse af ressourcer såsom yderligere CPU'er eller hukommelse til en enkelt node i et system, og dette bør være den første ting, du tænker på, når du skalerer dine tjenester. Det er meget vigtigt at designe dine applikationer, så de udnytter disse ressourcer optimalt. Tag den almindelige brugssag for vores hybride integrationsskyplatform, hvor integrationsoperationer betjenes af on-premise eller cloud-servernode. Her skal tjenesterne tage en anmodning om at køre integrationer, videregive anmodningen til servernoder og fortsætte med at betjene flere anmodninger. Tjenestelaget bør ikke være afhængigt af eller blokeret af de processer, der sker på forskellige lag af systemet. Som sådan er det meget vigtigt at have en asynkron, begivenhedsdrevet arkitektur.
En enkel måde at forstå asynkron arkitektur på er at tænke på din arkitektur som en restaurant. En tjener tager imod ordrer fra et bord og giver dem videre til kokken. Mens kokken, food-runneren og bus-drengen tager sig af aktiviteter som madlavning, servering og rengøring, fortsætter tjeneren med at betjene nye kunder og kører checks i slutningen af gudstjenesten.
Det er meget vigtigt at opretholde asynkronitet, mens systemet arbejder med alle komponenter som database, cache og mediatorlag. Ved at overføre belastning til klyngede, yderst tilgængelige servernoder, der kører integrationer, frigøres ressourcerne til servicelaget til at tage flere anmodninger og svare, når processer er afsluttet.
Vandret skalering
Den næste vigtige overvejelse bør være, at tjenesterne er skrevet på en måde, så det er ligegyldigt, hvor mange forekomster af disse tjenester, der kører, og hvilket delt system, der udfører transaktioner på et givet tidspunkt. Dette giver vores cloud-platform fleksibilitet til automatisk at skalere servicelaget. Hver del af backend'en er yderst tilgængelig og automatisk skalerbar for at holde trit med efterspørgslen efter voksende servicecontainere.
Vi kan dog ikke have uendelige containere, der kører servicelag, der bruger delte komponenter. Det er ikke det optimale design. Lad os gå tilbage til vores restauranteksempel. Med lodret skalering kan en enkelt restaurant blive meget skalerbar ved at tilføje mere personale, men på et vist tidspunkt vil antallet af ressourcer (kokke, løbere, bus-drenge) nå et mætningspunkt. For at skalere yderligere skal denne virksomhed åbne yderligere lokationer, der vil hjælpe med at distribuere kunder og afbalancere belastningen.
Det er bedre at opdele hele platformen i flere zoner, hvor hver zone opfører sig som en kopi af den oprindelige zone. Dette giver os mulighed for at bruge flere zoner til at belaste fremtidige behov.
Denne model har flere fordele:
1. Mulig uendelig vandret skalering, da vi kan bringe et hvilket som helst antal zoner ind
2. Fejltolerance, hvis hele zonen svigter på grund af en naturkatastrofe
3. Dataadskillelse, hvis der er tale om en SaaS-platform, der kræver endog lokationsbaseret metadataadskillelse, såsom for USA, EMEA-zoner osv.
Det ønskede resultat her er, at en brugers oplevelse skal være den samme, uanset hvor de er, og hvilken zone de rammer. Der bør ikke kræves nogen manuel indgriben fra en bruger for at få arbejdet udført.
I vores hybrid integrationssky blog, diskuterede vi, hvordan vi løb ind i udfordringen med at bruge et mediatorlag på en måde, så det understøttede begrænset vertikal skala. Ved at skrive vores eget tilpassede ikke-blokerende forbindelseslag baseret på sikker HTTPS-transport var vi i stand til at udvide arkitekturen til at have 50x lodret skala. Det er selvfølgelig også vandret skalerbart. Denne kombination af lodret og vandret skalering gav os et billigere og let udvideligt lag for at imødekomme vores voksende behov.
Optimering af brugen af delte komponenter:
Delte komponenter skal i sig selv være skalerbare og meget tilgængelige for at understøtte Cloud-platformen. Men delte komponenter deles og er derfor ikke så skalerbare som servicelaget. Det er meget vigtigt at tage sig af nogle komponenter, der kan være følsomme over for en høj belastning, for eksempel databaser. En model kan være at prioritere og sætte brugen af delte komponenter i kø, hvor flere samtidige højvolumenbelastninger kan forårsage problemer. Prioritering kan sænke belastningen og afbøde fejl på alle missionskritiske anmodninger. Tilbage i vores restaurant er køkkenet en fælles komponent, og mens tjeneren kan tage imod en diners bestilling på en forret, entré og dessert, vil køkkenet prioritere tilberedningen af disse genstande og balancere deres belastning.
En anden måde at adressere belastning på kan være caching af data, der sjældent ændres for at forhindre høj brug af disse komponenter. Hvis pommes frites er et populært element på menuen, kan restauranten beslutte at "cache" en kontinuerlig batch i stedet for at stege dem på bestilling.
Overvågning af komponenter:
Endelig er det meget vigtigt at overvåge hver komponent og at kende dens begrænsninger. Systemet skal være i stand til at øge båndbredden automatisk og på det rigtige tidspunkt for at holde systemerne oppe og køre i henhold til Cloud-platformens behov. Overvågning kan være eksternt eller applikationsinitieret, men i begge tilfælde er det endelige mål at lade systemet autoskalere baseret på belastningen.
I det næste blog post, vil vi tale om overvågning, logning og andre elementer i arkitekturen.
