Ser­ver­lose Archi­tek­tur ist eine Mög­lich­keit, Anwen­dun­gen und Dienste zu erstel­len und aus­zu­füh­ren, ohne die Infrastruktur ver­wal­ten zu müs­sen. Die­ser Ansatz hilft den Teams, sich auf den tat­säch­li­chen geschäft­li­chen Mehr­wert zu kon­zen­trie­ren und die Ver­wal­tung der Infrastruktur zu ver­ges­sen. Es gibt viele wei­tere Vor­teile der Ser­ver­less-Archi­tek­tur, die in ver­schie­de­nen Blogs behan­delt werden.

In die­sem Blog möchte ich einige der Ser­ver­less-Archi­tek­tur­mus­ter vor­stel­len, die ich in rea­len Pro­jek­ten ver­wen­det habe. Wer­fen wir einen Blick auf sie -

Mus­ter 1 - Dies ist das ein­fachste Archi­tek­tur­mus­ter, auf das man stößt, wenn man nach einer Ser­ver­less-basier­ten Archi­tek­tur sucht.

Ein Backend-Ser­vice, bei dem AWS API Gate­way als Proxy-Ebene für die Lambda-basier­ten Geschäfts­funk­tio­nen fun­giert. Lambda-Funk­tio­nen wer­den von API Gate­way auf syn­chrone Weise auf­ge­ru­fen. Daten wer­den in AWS Dyna­moDB, einem ver­wal­te­ten NoSQL-Ser­ver­less-Ser­vice von AWS, gespei­chert oder abgerufen.

API Gate­way ver­fügt über viele zusätz­li­che Funk­tio­nen wie Caching, Raten­be­gren­zung usw., die je nach Geschäfts­an­for­de­run­gen genutzt wer­den können.

Eine einzige Lambda-Funktion für alle Geschäftsfunktionen oder ein Lambda pro Geschäftsfunktion ist eine typische Frage, die mir im Allgemeinen gestellt wird? Nun, um es einfach und sicher zu halten - Verwenden Sie das Prinzip der einzigen Verantwortung und haben Sie eine Lambda-Funktion pro Geschäftsfunktion. Vereinigen Sie alle verwandten Lambda-Funktionen, um eine hohe Kohäsion zu erreichen und einen Microservice für die spezifische Domäne zu bilden. Und folgen Sie dem Least Privilege Prinzip - Jede Lambda Funktion hat eine Ausführungsrolle mit nur den Berechtigungen, die für die Geschäftsfunktionalität erforderlich sind.

Mus­ter 2 – Wenn Sie mit meh­re­ren Micro­ser­vices in Ihrem Pro­dukt arbei­ten, wobei jeder Ser­vice einem ande­ren Team gehört, ist die Frage, wie Sie diese Ser­vices bereit­stel­len, sehr wichtig.

Nun, einer der Ansätze ist unten abgebildet

Wich­tige Punkte 

1. Jedes Team ver­wal­tet und besitzt die End-to-End-Ser­vice­be­reit­stel­lung – API Gate­way, Lambda-Funk­tio­nen und DynamoDB.
2. Jeder Ser­vice wird in einem ande­ren AWS-Konto bereit­ge­stellt (ver­wal­tet durch das Ser­vice-Team). Dies erhöht die TPS des Gesamt­pro­dukts, da die Gleich­zei­tig­keits­grenze für API-Gate­way und Lambda-Funk­tio­nen auf Kon­to­e­bene liegt. Diese Gren­zen sind natür­lich wei­che Gren­zen und kön­nen erhöht wer­den, indem Sie einen Fall über die AWS-Kon­sole mel­den, wenn Sie pla­nen, die Ser­vices im sel­ben AWS-Konto zu hosten.
3. Jedem Ser­vice kann eine benut­zer­de­fi­nierte Domäne zuge­wie­sen wer­den. So etwas wie – catalog.example.com OR order.example.com.

Wenn Sie planen, Microservices in einem einzigen Konto bereitzustellen, können Sie auch auf den Service mit einem einzigen Domänennamen zugreifen, der jedoch unter verschiedenen URL-Pfaden eingebunden ist. Zum Beispiel - example.com/api/order für den Bestelldienst ODER example.com/api/catalog für den Katalogdienst. Diese Konvention ist nicht möglich, wenn die Services auf verschiedenen AWS-Konten gehostet werden. OK…ich lüge! Es ist möglich, aber auf eine andere Art und Weise. Wir werden es in Muster 5 behandeln.

Mus­ter 3 – Ein Stan­dard­ar­chi­tek­tur­mus­ter für ein Pro­dukt mit Backend und Front­end, wobei das Front­end eine Sin­gle Page Appli­ca­tion (SPA) wie eine React- oder Angu­lar-basierte Anwen­dung ist.

Wich­tige Punkte

1. Die sta­ti­sche SPA-Front­end-Anwen­dung wird in einem pri­va­ten S3-Bucket gehos­tet und über den AWS Cloud­Front-Ser­vice ver­mit­telt. Dadurch kön­nen Sie der Web­an­wen­dung eine benut­zer­de­fi­nierte Domäne zuwei­sen. Außer­dem kön­nen die CDN-Fähig­kei­ten von Cloud­Front genutzt wer­den, um eine geringe Latenz bei der Bereit­stel­lung der Inhalte zu erreichen.
2. Der Backend-Ser­vice wird mit dem API-Gate­way + Lambda + Dyna­moDB-Stack gehos­tet, der aus Mus­ter 1 stammt.

Mus­ter 4 - Eine Erwei­te­rung von Mus­ter #3. Wenn Sie Kun­den haben, die geo­gra­fisch ver­streut sind, und Sie mehr Kon­trolle über die Ver­tei­lung haben möch­ten, kön­nen Sie Cloud­Front als Proxy für ein regio­na­les API-Gate­way konfigurieren.

Ein Edge-optimiertes API-Gateway wird über CloudFront vermittelt, das von AWS verwaltet wird und über das Sie keine Kontrolle haben.

Mus­ter 5 - Eines der Pro­bleme mit Mus­ter 3 und 4 ist, dass Sie CORS hand­ha­ben müs­sen, was zu einer zusätz­li­chen Latenz für jeden API-Auf­ruf vom Brow­ser (Cli­ent) an die Backend-API führt. Diese zusätz­li­che Latenz ent­steht durch den OPTI­ONS-Auf­ruf des Brow­sers an das Backend zur Über­prü­fung des CORS. Es fin­det also ein zusätz­li­cher Round­trip vom Brow­ser zum Ser­ver statt, bevor der eigent­li­che API-Auf­ruf auf­ge­ru­fen wird. Um dies zu umge­hen, kann das fol­gende Mus­ter genutzt werden.

Bei die­sem Mus­ter wer­den sowohl Front­end- als auch Backend-APIs von einem ein­zi­gen Cloud­Front-Proxy bereit­ge­stellt und durch den­sel­ben Domä­nen­na­men zugäng­lich gemacht. Sowohl S3 als auch API-Gate­way (einfach/mehrfach) wer­den als Ursprünge kon­fi­gu­riert und die Cache-Ver­hal­tens­wei­sen wer­den für jeden Ursprung kon­fi­gu­riert. Etwas wie -

https://example.com/ui/index.html geht zu S3 Ori­gin und 

https://example.com/api/orders geht zu API Gateway

Und da die Domäne für den Zugriff auf die Front­end-Anwen­dung und die Backend-APIs die­selbe ist, spielt CORS keine Rolle.

Mus­ter 6 - Sto­rage First-Mus­ter, bei dem die Daten zuerst gespei­chert wer­den, bevor sie ver­ar­bei­tet wer­den. API-Gate­way fun­giert als HTTP-basier­ter Proxy und kann Daten in SQS, Kine­sis oder ähn­li­chen Spei­cher­diens­ten spei­chern. Die Daten wer­den dann von den Lambda-Funk­tio­nen verarbeitet.

Die­ses Mus­ter ermög­licht einen hohen ein­ge­hen­den Daten­ver­kehr, selbst wenn die Backend-Dienste nicht ska­lier­bar sind.

Mus­ter 7 – Die­ses Mus­ter ist die fort­schritt­lichste Ver­sion, die sowohl die vom Backend-Dienst gehos­te­ten APIs als auch die in S3 gehos­te­ten Front­end-Inhalte sichern kann.

API-Gate­way kann AWS Lambda Aut­ho­ri­zer und/oder AWS Cognito Ser­vice nut­zen, um expo­nierte API-End­punkte zu sichern. AWS AWS Lambda@Edge-Funktionen hel­fen bei der Siche­rung von Inhal­ten, die über Cloud­Front bereit­ge­stellt werden.

AWS Lambda@Edge ist eines der leis­tungs­fä­hi­gen Kon­strukte, das in Kom­bi­na­tion mit der Cloud­Front-Dis­tri­bu­tion für eine ganze Reihe inter­es­san­ter Auf­ga­ben ver­wen­det wer­den kann. Zum Beispiel

1. Sichere sta­ti­sche Website
2. Erwei­ter­tes Ori­gin Failover
3. Hin­zu­fü­gen von Sicher­heits-Hea­dern für die sta­ti­sche Website
4. A/B‑Tests
5. Pro­gres­si­ver Roll­out für sta­ti­sche Website

Ich habe nicht jedes ein­zelne Mus­ter ein­ge­hend unter­sucht, hoffe aber, dass die­ser Blog Ihnen einen Ein­druck von den ver­schie­de­nen Ser­ver­less-Archi­tek­tur­mus­tern ver­mit­telt, die für die Erstel­lung und Bereit­stel­lung von Anwen­dun­gen ver­wen­det werden.

Quelle: medium

Erfah­ren Sie mehr über Lösun­gen im Bereich Snow­flake oder besu­chen Sie eines unse­rer kos­ten­lo­sen Web­i­nare.