Ez a cikk azt ismerteti, hogy a Microsoft Kereskedelmi Szoftvermérnöki (CSE) csapata egy globális viszonteladóval együttműködve hogyan helyez üzembe magas rendelkezésre állású kiszolgáló nélküli megoldást az Azure és az Amazon Web Services (AWS) felhőplatformokon a kiszolgáló nélküli keretrendszer használatával.
Architektúra
Töltse le az architektúra Visio-fájlját.
Adatfolyam
- A felhasználói alkalmazás bármely olyan forrásból származhat, amely képes a felhőbe való bejelentkezésre. Ebben az implementációban a felhasználó egy átjáróalkalmazásba jelentkezik be, amely 50–50-et terheléseloszt az Azure és az AWS-felhők között.
- Minden válasz az API Manager-átjárón keresztül is áthalad, amely aztán elküldi azt a kérelmező alkalmazásnak.
Összetevők
A kiszolgáló nélküli keretrendszer
Ez a megoldás a Kiszolgáló nélküli, Inc. szolgáltatásból elérhető kiszolgáló nélküli keretrendszert használja. A kiszolgáló nélküli keretrendszer ingyenes verziója cli-t, további beépülő modulokat és korlátozott monitorozási szolgáltatásokat tartalmaz. A Pro kiadás működési képességeket kínál a felhőkben, például továbbfejlesztett monitorozást és riasztásokat. A keretrendszer támogatja a Node.js és a Python nyelveket, valamint az AWS-t és az Azure-felhőgazdákat is.
Az Azure kiszolgáló nélküli keretrendszerrel való használatához a következőkre van szüksége:
- Node.js mikroszolgáltatások csomagolásához
- Azure Functions, hogy más felhőplatformokkal összehasonlítható funkciókat biztosítson
- A kiszolgáló nélküli keretrendszer, amely támogatja a többfelhős üzembe helyezést és monitorozást
- A kiszolgáló nélküli többfelhős kódtár, amely normalizált futtatókörnyezeti API-kat biztosít a fejlesztők számára
- A Azure Functions kiszolgáló nélküli beépülő modul, amely támogatja a többfelhős üzembe helyezést. Ez a beépülő modul kezdetben nem volt paritásos a hasonló AWS Lambda beépülő modullal, és kiterjesztették erre a projektre.
Az alábbi ábrán a feldolgozási folyamat látható. A köztes szoftverrétegek a kezelő elérése előtt szükséges köztes funkciókat jelölik.
Felhőbeli agnosztikus API-k
A kiszolgáló nélküli implementáció minden platformon támogatja az egyes függvényeket mikroszolgáltatásként, egy-egy funkcionális virtuálisgép-csomópontot, és szükség szerint végrehajtja a feldolgozást. Minden AWS Lambda-függvény megfelelő Azure Functions függvénnyel rendelkezik. A kiszolgáló nélküli többfelhős kódtár mindkét felhőből hasonló mikroszolgáltatásokat épít fel egy felhőalapú normalizált REST API-ba , amelyet az ügyfélalkalmazások bármelyik platformhoz használhatnak. Mivel az absztrakciós API-réteg kódot biztosít az egyes platformok megfelelő mikroszolgáltatásainak kezeléséhez, a tranzakcióknak nincs szükségük fordításra. A felhőbeli agnosztikus felület lehetővé teszi a felhasználói alkalmazások számára a felhővel való interakciót anélkül, hogy tudnák vagy gondoskodnának arról, hogy melyik felhőplatformhoz férnek hozzá.
Az alábbi ábra ezt a fogalmat szemlélteti:
CI/CD a GitOpsszal
A kiszolgáló nélküli keretrendszer elsődleges feladata, hogy elvonja az alkalmazás felhőben való üzembe helyezésének összes infrastrukturális aggályát. Jegyzékalapú megközelítéssel a kiszolgáló nélküli keretrendszer képes kezelni az összes üzembe helyezési problémát, így az üzembe helyezés szükség szerint automatizálható a GitOps támogatásához.
Bár ez a kezdeti projekt manuális üzembe helyezést használt, reális a jegyzékalapú kiszolgáló nélküli buildek, tesztek és üzembe helyezések megvalósítása a felhőkben vagy felhőkben. Ez a folyamat egy GitOps-fejlesztői munkafolyamatot használhat: a Gitből való építést, a teszteléshez és a kiértékeléshez használt minőségi kapukat, valamint kiszolgáló nélküli megoldások küldését mindkét felhőszolgáltatóra. A leghatékonyabb módszer az összes üzembe helyezés végrehajtása a kiszolgáló nélküli keretrendszer használatával a projekt elejétől.
API-kezelő
Az API Manager lehet egy meglévő vagy egyéni alkalmazás. Az Apigee™ API Manager ebben az implementációban csak útválasztóként nyújtott 50–50 tranzakciós terheléselosztást a két felhőplatformnak, és kihasználatlan volt a képességeihez.
Az API Managernek képesnek kell lennie a következőkre:
- Szükség szerint üzembe helyezhető felhőplatformon belül vagy azon kívül
- Üzenetek átirányítása mindkét felhőplatformra és onnan
- Forgalomkérések naplózása az aszinkron üzenetforgalom koordinálásához
- Kérelmek és válaszok továbbítása a közös REST API használatával a felhasználói alkalmazásból és az alkalmazásba
- Mindkét felhőalapú kiszolgáló nélküli keretrendszer üzemelő példányának állapotának monitorozása a kérések fogadásának ellenőrzéséhez
- Automatizált állapot- és rendelkezésre állási ellenőrzések végrehajtása az egyes felhőplatformokon az útválasztás és a magas rendelkezésre állás támogatásához
Alternatív megoldások
Más nyelvek, például a Python implementálhatják a megoldást, amennyiben a felhőplatformok kiszolgáló nélküli implementációi, az AWS Lambda és ebben az esetben a Azure Functions támogatják őket. Ez a projekt Node.js használt a mikroszolgáltatások csomagolására, mivel az ügyfél jól használta a Node.js, és az AWS és az Azure platform is támogatja azt.
A megoldás bármilyen felhőplatformot használhat, amely támogatja a kiszolgáló nélküli keretrendszert, nem csak az Azure-t és az AWS-t. A kiszolgáló nélküli keretrendszer jelenleg nyolc különböző felhőszolgáltatóval való kompatibilitást jelent. Az egyetlen kikötés annak biztosítása, hogy a többfelhős architektúrát vagy annak megfelelőjét támogató elemek elérhetők legyenek a célfelhőplatformokon.
Az API Manager ebben a kezdeti implementációban csak útválasztóként járt el, hogy 50–50 tranzakciós terheléselosztást biztosítson a két felhőplatformnak. Az API Manager más üzleti logikát is tartalmazhat adott forgatókönyvekhez.
Forgatókönyv részletei
A kiszolgáló nélküli számítástechnikában a felhőszolgáltató dinamikusan lefoglalja a mikroszolgáltatás-erőforrásokat a kód futtatásához, és csak a felhasznált erőforrások díjait. A kiszolgáló nélküli számítástechnika elvonja az alkalmazáskódot az infrastruktúra implementálásától, a kód üzembe helyezésétől és az olyan üzemeltetési szempontoktól, mint a tervezés és a karbantartás.
A többi szolgáltatáshoz hasonlóan minden felhőszolgáltató saját kiszolgáló nélküli implementációval rendelkezik, és az ügyfelek nehezen használhatnak másik szolgáltatót jelentős működési hatás és költségek nélkül. A potenciális ügyfelek úgy tekinthetnek erre a helyzetre, mintha gyengítenék alkupozíciójukat és rugalmasságukat. A szállítói zárolás az egyik legnagyobb akadálya a vállalati felhő bevezetésének.
A nyílt forráskódú kiszolgáló nélküli keretrendszer egy univerzális felhőfelület a kiszolgáló nélküli számítási megoldások felhőszolgáltatók közötti fejlesztéséhez és üzembe helyezéséhez. A nyílt forráskezelés és a kiszolgáló nélküli funkciókhoz használható gyakori API-k segítenek a szolgáltatóknak, az ügyfeleknek és a partnereknek a felhők közötti megoldások létrehozásában a legkülönfélébb szolgáltatásokhoz. A kiszolgáló nélküli keretrendszer csökkenti a felhőbevezetés akadályait a szállítói zárolás és a felhők közötti szolgáltatói redundancia problémáinak megoldásával. Az ügyfelek költség, rugalmasság és egyéb szempontok alapján optimalizálhatják megoldásaikat.
A CSE és az Azure termékcsapata közösen átírta a kiszolgáló nélküli cli-t, hogy támogassa az olyan új Azure Functions funkciókat, mint a Premium Functions, a API Management és a KeyVault. A kiszolgáló nélküli parancssori felület mostantól szabványos felületet biztosít a GitOps azure-beli és AWS-alapú üzembe helyezéséhez. A csapat kifejlesztette a kiszolgáló nélküli többfelhős kódtárat is, amely egy normalizált futtatókörnyezeti API-t biztosít a kiszolgáló nélküli alkalmazások AWS-ben és az Azure-ban történő üzembe helyezéséhez.
Ez a kialakítás magas rendelkezésre állást biztosít több felhőplatform közötti aktív-aktív feladatátvétellel, szemben az aktív-passzív feladatátvétellel. Ha egy felhőszolgáltató szolgáltatása nem megfelelő állapotúvá válik vagy elérhetetlenné válik, ez a megoldás átirányíthatja a kéréseket egy másik felhőplatformra.
Ez a projekt a következő technikai célokat teljesítette:
- Iparágközi megoldás létrehozása.
- A többfelhős kiszolgáló nélküli kódtár használatával támogatja a felhőbeli agnosztikus API-t, amely bárhol is van üzembe helyezve, a mikroszolgáltatásokkal is együttműködik.
- A GitOps CI/CD-folyamat munkafolyamatának támogatása fejlesztéshez, teszteléshez és üzembe helyezéshez az összes támogatott felhőplatformon.
- Api-alapú hozzáférés használata hitelesített felhőátjárón keresztül, és terheléselosztás a felhőplatformok között az átjáró útválasztóként való használatával.
A kiszolgáló nélküli keretrendszer használatának további lehetséges előnyei a következők:
- A szállítói zárolás megelőzése vagy csökkentése
- 40-60+%-os kódcsökkentés a fejlesztés során a többfelhős kiszolgáló nélküli kódtár használatával
- A legkedvezőbb megoldások fejlesztése, amelyek kombinálják a különböző felhőszolgáltatók szolgáltatásait
- A legtöbb platform- és infrastruktúra-összetettségi és karbantartási követelmény kiküszöbölése
- Egyszerűbb adatmegosztás, teljesítmény- és költség-összehasonlítás, valamint a különleges ajánlatok előnyeinek kihasználása
- Aktív-aktív magas rendelkezésre állás
Lehetséges használati esetek
- Több platform ügyféloldali alkalmazásainak írása a kiszolgáló nélküli többfelhős kódtár felhőbeli agnosztikus API-jának használatával.
- Funkcionális mikroszolgáltatások gyűjteményének üzembe helyezése kiszolgáló nélküli keretrendszerben több felhőplatformon.
- Használjon felhőalapú alkalmazásokat felhőplatformokon anélkül, hogy tudná vagy gondoskodott volna arról, hogy melyik platform üzemelteti azt.
Megfontolandó szempontok
Ez a cikk nem ismerteti a biztonsági megoldásokat, bár a kezdeti üzembe helyezés tartalmazza őket. Számos lehetséges biztonsági megoldás létezik, néhány platformfüggő, és ennek a keretrendszernek minden ésszerű megoldást be kell fogadnia. A felhasználói hitelesítés a minimálisan feltételezett biztonság.
Mivel nehéz meghatározni az AWS és az Azure kiszolgáló nélküli funkcionális ajánlatai közötti különbségeket, a korai erőfeszítéseknek az egyes felhőplatformokon elérhető funkciók leképezésére és a szükséges átalakítási követelmények azonosítására kell összpontosítaniuk. Ebből az információból platform-agnostic API-t fejleszthet.
A nyílt forráskódú megoldások használata kockázatokat okozhat a nyílt forráskódú szoftverekkel kapcsolatos hosszú távú karbantartási és támogatási kihívások miatt.
Az ingyenes kiszolgáló nélküli keretrendszerben a figyelés elsősorban a felügyeleti irányítópultra korlátozódik. A monitorozás a fizetős vállalati ajánlatban érhető el. Jelenleg a Azure Functions kiszolgáló nélküli beépülő modul nem tartalmaz a megfigyelhetőségre vagy a figyelésre vonatkozó rendelkezéseket, és módosítania kell ezeket a képességeket.
Ez a megoldás metrikákkal hasonlíthatja össze a felhőplatformok teljesítményét és költségeit, így az ügyfelek zökkenőmentesen optimalizálhatják a felhőplatformok használatát.
A forgatókönyv üzembe helyezése
A hagyományos kék-zöld üzembe helyezés egy alkalmazást fejleszt és helyez üzembe két különálló, de azonos környezetben, kék és zöld környezetben, növelve a rendelkezésre állást és csökkenti a kockázatokat. A kék környezet általában az éles környezet, amely általában az élő forgalmat kezeli, a zöld környezet pedig szükség szerint feladatátvételi környezet. A CI/CD-folyamat általában kék és zöld környezeteket is automatikusan üzembe helyez ugyanazon a felhőplatformon belül. Ez a konfiguráció aktív-passzív konfigurációnak minősül.
A többfelhős megoldásban a kék-zöld üzembe helyezés mindkét felhőplatformon implementálva van. A kiszolgáló nélküli esetben két ismétlődő mikroszolgáltatás-készlet van üzembe helyezve minden felhőplatformon, az egyik az éles környezet, a másik pedig feladatátvételi környezet. Ez az aktív-passzív beállítás az egyes felhőplatformokon belül csökkenti a platform leállásának kockázatát, növeli a rendelkezésre állását, és lehetővé teszi a többfelhős aktív-aktív magas rendelkezésre állást.
A kék-zöld üzembe helyezés másodlagos előnye, hogy a feladatátvételi üzembe helyezést az egyes felhőplatformokon a mikroszolgáltatás-frissítések tesztelési környezeteként használhatja, mielőtt azokat az éles üzembe helyezésre bocsátja.
Következő lépések
- Mintakód és README az implementációhoz a GitHubon
- Kiszolgáló nélküli keretrendszer
- Oktatás: A Azure Functions bemutatása
- A Azure Functions áttekintése