Share via

Mikroszolgáltatások értékelése és felkészültsége

  • Cikk

A mikroszolgáltatás-architektúra számos előnnyel jár az alkalmazások számára, beleértve az agilitást, a méretezhetőséget és a magas rendelkezésre állást. Ezen előnyök mellett ez az architektúra kihívásokat is jelent. Ha mikroszolgáltatás-alapú alkalmazásokat hoz létre, vagy meglévő alkalmazásokat alakít át mikroszolgáltatás-architektúrává, elemeznie és értékelnie kell a jelenlegi helyzetet, hogy azonosítsa a fejlesztésre szoruló területeket.

Ez az útmutató segít megérteni azokat a szempontokat, amelyek figyelembe veendők a mikroszolgáltatás-architektúrára való áttéréskor. Ezzel az útmutatóval felmérheti az alkalmazás, az infrastruktúra, a DevOps, a fejlesztési modell és egyebek fejlettségét.

Az üzleti prioritások ismertetése

A mikroszolgáltatás-architektúra értékelésének megkezdéséhez először meg kell ismernie a vállalat alapvető prioritásait. Az alapvető prioritások lehetnek például az agilitás, a változásbevezetés vagy a gyors fejlődés. Elemeznie kell, hogy az architektúra megfelel-e az alapvető prioritásoknak. Ne feledje, hogy az üzleti prioritások idővel változhatnak. Az innováció például az első számú prioritás a startupok számára, de néhány év elteltével a legfontosabb prioritás lehet a megbízhatóság és a hatékonyság.

Az alábbiakban néhány prioritást érdemes figyelembe venni:

  • Innováció
  • Megbízhatóság
  • Hatékonyság

Dokumentálja az alkalmazás különböző részeihez igazodó SLA-kat, hogy biztosítsa a szervezeti elkötelezettséget, amely útmutatóként szolgálhat az értékeléshez.

Architekturális döntések rögzítése

A mikroszolgáltatás-architektúra segít a csapatok önállóvá válásában. A csapatok saját döntéseket hozhatnak például a technológiákról, a módszertanokról és az infrastruktúra-összetevőkről. Ezeknek a döntéseknek azonban tiszteletben kell tartaniuk a hivatalosan elfogadott, közös irányításnak nevezett alapelveket, amelyek kifejezik a csapatok közötti megállapodást a mikroszolgáltatások szélesebb körű stratégiájának kezelésére vonatkozóan.

Vegye figyelembe az alábbi tényezőket:

  • Működik a megosztott irányítás?
  • Nyomon követi a döntéseket és azok kompromisszumait egy architektúranaplóban?
  • Könnyedén hozzáférhet a csapata az architektúranaplóhoz?
  • Rendelkezik az eszközök, technológiák és keretrendszerek értékelésének folyamatával?

Csapatösszetétel felmérése

A csapatok közötti szükségtelen kommunikáció elkerülése érdekében megfelelő csapatstruktúrával kell rendelkeznie. A mikroszolgáltatás-architektúra kis, koncentrált, keresztfunkcionális csapatok létrehozását ösztönzi, és szemléletváltást igényel, amelyet a csapatátalakításnak kell megelőznie.

Vegye figyelembe az alábbi tényezőket:

  • A csoportok altartományok alapján vannak felosztva, a tartományalapú tervezés (DDD) alapelveit követve?
  • A csapatok keresztfunkcionálisak, és elegendő kapacitásuk van a kapcsolódó mikroszolgáltatások egymástól függetlenül történő kiépítéséhez és működtetéséhez?
  • Mennyi időt töltenek olyan alkalmi tevékenységekben és tevékenységekben, amelyek nem kapcsolódnak projektekhez?
  • Mennyi időt tölt a csapatközi együttműködés?
  • Van egy folyamat a technikai adósság azonosítására és minimalizálására?
  • Hogyan kommunikálnak a leckék és a tapasztalatok a csapatok között?

A Twelve-Factor módszertan használata

A mikroszolgáltatás-architektúra kiválasztásának alapvető célja az érték gyorsabb elérése és a változáshoz való alkalmazkodás az agilis eljárások követésével. A Twelve-Factor alkalmazás módszertana útmutatást nyújt a karbantartható és méretezhető alkalmazások létrehozásához. Ezek az irányelvek olyan attribútumokat támogatnak, mint a megváltoztathatatlanság, a rövid élettartam, a deklaratív konfiguráció és az automatizálás. Ezen irányelvek beépítésével és a gyakori buktatók elkerülésével lazán összekapcsolt, önálló mikroszolgáltatásokat hozhat létre.

A felbontási megközelítés megismerése

A monolitikus alkalmazások mikroszolgáltatás-architektúrává alakítása időt vesz igénybe. Kezdje a peremhálózati szolgáltatásokkal. Az edge-szolgáltatások kevesebb függőséget használnak más szolgáltatásoktól, és független szolgáltatásként könnyen lebomlaszthatók a rendszerből. Erősen ajánljuk az olyan mintákat, mint a Strangler Fig és az Anti-corruption Layer , hogy a monolitikus alkalmazás működőképes állapotban maradjon, amíg az összes szolgáltatás külön mikroszolgáltatásra nem bomlik. A szegregáció során a DDD alapelvei segíthetnek a csapatoknak az altartományok alapján kiválasztani az összetevőket vagy szolgáltatásokat a monolitikus alkalmazásból.

Egy e-kereskedelmi rendszerben például a következő modulok lehetnek: kosár, termékkezelés, rendeléskezelés, díjszabás, számlakészítés és értesítés. Úgy dönt, hogy elindítja az alkalmazás átalakítását az értesítési modullal, mert nem függ más moduloktól. Más modulok azonban attól is függhetnek, hogy a modul értesítéseket küld-e. Az értesítési modul könnyen külön mikroszolgáltatássá bontható, de az új értesítési szolgáltatás meghívásához módosítania kell a monolitikus alkalmazásban. Úgy dönt, hogy a következő lépésben átalakítja a számlagenerálási modult. Ezt a modult a rendszer a rendelés létrehozása után hívja meg. Az átalakítás támogatásához használhat olyan mintákat, mint a Strangler és az Anti-corruption.

Az adatszinkronizálás, a több írás monolitikus és mikroszolgáltatási felületekre, az adatok tulajdonjoga, a séma felbontása, az illesztések, az adatmennyiség és az adatintegritás megnehezítheti az adatok lebontását és migrálását. Számos módszer használható, például a megosztott adatbázisok mikroszolgáltatások közötti megtartása, az adatbázisok leválasztása egy szolgáltatáscsoporttól az üzleti képesség vagy tartomány alapján, valamint az adatbázisok elkülönítése a szolgáltatásoktól. Az ajánlott megoldás az egyes adatbázisok lebontása az egyes szolgáltatásokkal. Sok esetben ez nem praktikus. Ezekben az esetekben olyan mintákat használhat, mint az Adatbázisnézet minta és az Adatbázisburkoló szolgáltatás mintája.

A DevOps felkészültségének értékelése

Amikor mikroszolgáltatás-architektúrára vált, fontos felmérni a DevOps-kompetenciát. A mikroszolgáltatási architektúra célja, hogy megkönnyítse az alkalmazások agilis fejlesztését a szervezeti rugalmasság növelése érdekében. A DevOps az egyik legfontosabb eljárás, amelyet e kompetencia eléréséhez végre kell hajtania.

Amikor kiértékeli a DevOps-képességet egy mikroszolgáltatási architektúra esetében, tartsa szem előtt az alábbi szempontokat:

  • Ismerik a szervezet tagjai a DevOps alapvető gyakorlatait és alapelveit?
  • Ismerik a csapatok a forrásvezérlő eszközöket és azok CI/CD-folyamatokkal való integrációját?
  • Megfelelően implementálja a DevOps-eljárásokat?
    • Követi az agilis eljárásokat?
    • Implementálva van a folyamatos integráció?
    • Implementálva van a folyamatos teljesítés?
    • A folyamatos üzembe helyezés implementálva van?
    • A folyamatos figyelés implementálva van?
    • Működik az infrastruktúra kódként (IaC) ?
  • A megfelelő eszközökkel támogatja a CI/CD-t?
  • Hogyan kezeli az előkészítési és éles környezetek konfigurációját az alkalmazás?
  • Rendelkezik az eszközlánc közösségi támogatással és támogatási modellel, és megfelelő csatornákat és dokumentációt biztosít?

A gyakran változó üzleti területek azonosítása

A mikroszolgáltatás-architektúra rugalmas és adaptálható. Az értékelés során vitafórumot kezdeményezhet a szervezeten belül, hogy meghatározza a munkatársai által gyakran változó területeket. A mikroszolgáltatások létrehozása lehetővé teszi, hogy a csapatok gyorsan reagáljanak az ügyfelek által kért változásokra, és minimalizálják a regressziós tesztelési erőfeszítéseket. Egy monolitikus alkalmazásban egy modul módosítása számos regressziós tesztelési szintet igényel, és csökkenti az új verziók kiadásának rugalmasságát.

Vegye figyelembe az alábbi tényezőket:

  • A szolgáltatás egymástól függetlenül telepíthető?
  • A szolgáltatás követi a DDD alapelveit?
  • Követi a szolgáltatás a SOLID alapelveit?
  • Az adatbázis privát a szolgáltatás számára?
  • A szolgáltatást a támogatott mikroszolgáltatások vázmintájának használatával hozta létre?

Infrastruktúra-felkészültség felmérése

Amikor mikroszolgáltatás-architektúrára vált, az infrastruktúra felkészültsége kritikus fontosságú szempont. Az alkalmazás teljesítménye, rendelkezésre állása és méretezhetősége akkor lesz hatással, ha az infrastruktúra nincs megfelelően beállítva, vagy ha a megfelelő szolgáltatásokat vagy összetevőket nem használják. Előfordul, hogy az alkalmazás az összes javasolt módszertansal és eljárással létrejön, de az infrastruktúra nem megfelelő. Ez gyenge teljesítményt és karbantartást eredményez.

Az infrastruktúra felkészültségének értékelésekor vegye figyelembe ezeket a tényezőket:

  • Biztosítja az infrastruktúra az üzembe helyezett szolgáltatások méretezhetőségét?
  • Támogatja az infrastruktúra a CI/CD-n keresztül automatizálható szkripteken keresztüli kiépítést?
  • Az üzembehelyezési infrastruktúra SLA-t kínál a rendelkezésre álláshoz?
  • Rendelkezik vészhelyreállítási (DR) tervvel és rutinszerű részletezési ütemtervekkel?
  • Az adatok replikálva lesznek a DR különböző régióiba?
  • Rendelkezik adatmentési csomaggal?
  • Dokumentálva vannak az üzembehelyezési beállítások?
  • Figyelik az üzembehelyezési infrastruktúrát?
  • Támogatja az üzembehelyezési infrastruktúra a szolgáltatások öngyógyítását?

Kiadási ciklusok értékelése

A mikroszolgáltatások alkalmazkodnak a változáshoz, és kihasználják az agilis fejlesztés előnyeit a kiadási ciklusok lerövidítése és az ügyfelek számára történő értékük érdekében. A kiadási ciklusok kiértékelésekor vegye figyelembe ezeket a tényezőket:

  • Milyen gyakran készít és bocsát ki alkalmazásokat?
  • Milyen gyakran hiúsulnak meg a kiadások az üzembe helyezés után?
  • Mennyi ideig tart a problémák helyreállítása vagy elhárítása egy kimaradás után?
  • Szemantikai verziószámozást használ az alkalmazásaihoz?
  • Különböző környezeteket tart fenn, és egy sorrendben propagálja ugyanazt a kiadást (például először az előkészítéshez, majd az éles környezethez)?
  • Verziószámozást használ az API-khoz?
  • Betartja az API-k megfelelő verziószámozási irányelveit?
  • Mikor módosítja az API-verziót?
  • Mi a megközelítése az API-verziószámozás kezeléséhez?
    • URI-elérési út verziószámozása
    • Lekérdezési paraméter verziószámozása
    • Tartalomtípus-verziószámozás
    • Egyéni fejléc verziószámozása
  • Van gyakorlata az események verziószámozására?

A szolgáltatások közötti kommunikáció értékelése

A mikroszolgáltatások olyan önálló szolgáltatások, amelyek folyamathatárokon keresztül kommunikálnak egymással az üzleti forgatókönyvek kezelése érdekében. A megbízható és megbízható kommunikációhoz ki kell választania egy megfelelő kommunikációs protokollt.

Vegye figyelembe az alábbi tényezőket:

  • Az API-k elsőrendű megközelítését követi, ahol az API-kat első osztályú polgárokként kezelik?
  • Rendelkezik hosszú láncú műveletekkel, ahol több szolgáltatás egymás után kommunikál egy szinkron kommunikációs protokollon keresztül?
  • Fontolóra vette az aszinkron kommunikációt bárhol a rendszerben?
  • Értékelte az üzenetközvetítő technológiáját és képességeit?
  • Tisztában van a szolgáltatások által fogadott és feldolgozott üzenetek átviteli sebességével?
  • Közvetlen ügyfél-szolgáltatás kommunikációt használ?
  • Meg kell őriznie az üzeneteket az üzenetközvetítő szintjén?
  • A Materialized View mintát használja a mikroszolgáltatások csevegéses viselkedésének kezelésére?
  • Implementálta már az Újrapróbálkozást, a Megszakítót, az Exponenciális backoffot és a Jittert a megbízható kommunikáció érdekében? Ennek kezelésére gyakran a Nagykövet mintát használjuk.
  • Definiált tartományi eseményeket a mikroszolgáltatások közötti kommunikáció megkönnyítése érdekében?

Annak kiértékelése, hogy a szolgáltatások hogyan érhetők el az ügyfelek számára

Az API-átjáró a mikroszolgáltatás-architektúra egyik alapvető összetevője. A szolgáltatások ügyfeleknek való közvetlen felfedése problémákat okoz a kezelhetőség, az ellenőrzés és a megbízható kommunikáció szempontjából. Az API-átjáró proxykiszolgálóként szolgál, amely elfogja a forgalmat, és átirányítja azt a háttérszolgáltatásokhoz. Ha IP-cím, engedélyezés, szimulált válaszok stb. alapján szeretné szűrni a forgalmat, akkor ezt az API-átjáró szintjén teheti meg anélkül, hogy módosítanák a szolgáltatásokat.

Vegye figyelembe az alábbi tényezőket:

  • A szolgáltatásokat közvetlenül az ügyfelek használják fel?
  • Létezik olyan API-átjáró, amely az összes szolgáltatás homlokzataként működik?
  • Beállíthat az API-átjáró olyan szabályzatokat, mint a kvótakorlátok, a válaszok szimulálása és az IP-címek szűrése?
  • Több API-átjárót használ különböző típusú ügyfelek, például mobilalkalmazások, webalkalmazások és partnerek igényeinek kielégítésére?
  • Biztosít az API-átjáró egy portált, ahol az ügyfelek felderíthetik és feliratkozhatnak a szolgáltatásokra, például egy fejlesztői portálra az Azure API Managementben?
  • A megoldás L7 terheléselosztási vagy webalkalmazási tűzfal (WAF) képességeket biztosít az API-átjáróval együtt?

Tranzakciókezelés értékelése

Az elosztott tranzakciók több művelet végrehajtását teszik lehetővé egyetlen munkaegységként. A mikroszolgáltatás-architektúrában a rendszer számos szolgáltatásra bontható. Egyetlen üzleti használati esetet több mikroszolgáltatás kezel egyetlen elosztott tranzakció részeként. Az elosztott tranzakciókban a parancsok olyan műveletek, amelyek esemény bekövetkezésekor kezdődnek. Az esemény elindít egy műveletet a rendszerben. Ha a művelet sikeres, előfordulhat, hogy egy másik parancsot aktivál, amely aztán egy másik eseményt indíthat el, és így tovább, amíg az összes tranzakció befejeződik vagy vissza nem kerül, attól függően, hogy a tranzakció sikeres-e.

Vegye figyelembe a következő szempontokat:

  • Hány elosztott tranzakció található a rendszerben?
  • Hogyan kezeli az elosztott tranzakciókat? Értékelje ki a Saga minta használatát vezényléssel vagy koreográfiával.
  • Hány tranzakció terjed ki több szolgáltatásra?
  • ACID vagy BA Standard kiadás tranzakciós modellt követ az adatkonzisztencia és az integritás elérése érdekében?
  • Hosszú láncú műveleteket használ több szolgáltatásra kiterjedő tranzakciókhoz?

A szolgáltatásfejlesztési modell értékelése

A mikroszolgáltatási architektúrák egyik legnagyobb előnye a technológia sokfélesége. A mikroszolgáltatás-alapú rendszerek lehetővé teszik, hogy a csapatok az általuk választott technológiákkal fejlesszék a szolgáltatásokat. A hagyományos alkalmazásfejlesztés során újra felhasználhatja a meglévő kódot új összetevők létrehozásakor, vagy létrehozhat egy belső fejlesztési keretrendszert a fejlesztési munka csökkentése érdekében. Több technológia használata megakadályozhatja a kód újrafelhasználását.

Vegye figyelembe az alábbi tényezőket:

  • Szolgáltatássablont használ az új szolgáltatásfejlesztés elindításához?
  • Követi a Twelve-Factor alkalmazás módszertanát, és egyetlen kódbázist használ a mikroszolgáltatásokhoz, elkülöníti a függőségeket és külső konfigurációt?
  • Megtartja a bizalmas konfigurációt a kulcstartókban?
  • Tárolóba helyezi a szolgáltatásokat?
  • Ismeri az adatkonzisztencia követelményeit?

Az üzembe helyezési megközelítés értékelése

Az üzembe helyezési módszer az alkalmazás verzióinak különböző üzembehelyezési környezetekben való kiadására szolgáló módszer. A mikroszolgáltatás-alapú rendszerek biztosítják a rugalmasságot a verziók gyorsabb kiadásához, mint a hagyományos alkalmazások esetében.

Az üzembehelyezési terv értékelésekor vegye figyelembe az alábbi tényezőket:

  • Van stratégiája a szolgáltatások üzembe helyezéséhez?
  • Modern eszközöket és technológiákat használ a szolgáltatások üzembe helyezéséhez?
  • Milyen típusú együttműködésre van szükség a csapatok között a szolgáltatások üzembe helyezésekor?
  • Infrastruktúra kiépítése az infrastruktúra kódként (IaC) használatával?
  • DevOps-képességeket használ az üzembe helyezés automatizálásához?
  • Több környezetbe is propagálja ugyanazokat a buildeket a Twelve-Factor alkalmazás módszertana szerint?

Az üzemeltetési platform értékelése

A méretezhetőség a mikroszolgáltatás-architektúrák egyik fő előnye. Ennek az az oka, hogy a mikroszolgáltatások üzleti tartományokra vannak leképezve, így az egyes szolgáltatások egymástól függetlenül méretezhetők. A monolitikus alkalmazás egyetlen egységként van üzembe helyezve egy üzemeltetési platformon, és holisztikusan kell skálázni. Ez állásidőt, üzembe helyezési kockázatot és karbantartást eredményez. A monolitikus alkalmazás jól megtervezhető, az egyes üzleti tartományokhoz kapcsolódó összetevőkkel. A folyamathatárok hiánya miatt azonban az önálló felelősség alapelveinek megsértésének lehetősége nehezebbé válik. Ez végül spagettikódot eredményez. Mivel az alkalmazás egyetlen üzemeltetési folyamatként van összeállítva és üzembe helyezve, a méretezhetőség nehéz.

A mikroszolgáltatások lehetővé teszik a csapatok számára a megfelelő üzemeltetési platform kiválasztását a méretezhetőségi igények támogatására. Különböző üzemeltetési platformok állnak rendelkezésre ezeknek a kihívásoknak a megoldásához olyan képességek biztosításával, mint az automatikus skálázás, a rugalmas kiépítés, a magasabb rendelkezésre állás, a gyorsabb üzembe helyezés és az egyszerű monitorozás.

Vegye figyelembe az alábbi tényezőket:

  • Milyen üzemeltetési platformot használ a szolgáltatások (virtuális gépek, tárolók, kiszolgáló nélküli) üzembe helyezéséhez?
  • Skálázható az üzemeltetési platform? Támogatja az automatikus skálázást?
  • Mennyi ideig tart az üzemeltetési platform skálázása?
  • Ismeri a különböző üzemeltetési platformok által biztosított SLA-kat?
  • Támogatja az üzemeltetési platform a vészhelyreállítást?

Szolgáltatások monitorozásának értékelése

A monitorozás a mikroszolgáltatás-alapú alkalmazások fontos eleme. Mivel az alkalmazás több egymástól független szolgáltatásra van osztva, a hibaelhárítási hibák ijesztőek lehetnek. Ha a szolgáltatások monitorozásához megfelelő szemantikát használ, a csapatok egyszerűen monitorozhatnak, vizsgálhatnak és válaszolhatnak a hibákra.

Vegye figyelembe az alábbi tényezőket:

  • Figyeli az üzembe helyezett szolgáltatásokat?
  • Rendelkezik naplózási mechanizmussal? Milyen eszközöket használ?
  • Rendelkezik elosztott nyomkövetési infrastruktúrával?
  • Rögzít kivételeket?
  • Tart fenn üzleti hibakódokat a problémák gyors azonosításához?
  • Állapotmintákat használ a szolgáltatásokhoz?
  • Szemantikai naplózást használ? Bevezette a főbb metrikákat, küszöbértékeket és mutatókat?
  • Elfedi a bizalmas adatokat a naplózás során?

Korrelációs jogkivonat hozzárendelésének értékelése

A mikroszolgáltatás-architektúrában az alkalmazások különböző, egymástól függetlenül üzemeltetett mikroszolgáltatásokból állnak, amelyek különböző üzleti használati esetek kiszolgálására használják egymást. Amikor egy alkalmazás a háttérszolgáltatásokkal együttműködve hajt végre egy műveletet, hozzárendelhet egy egyedi számot, más néven korrelációs jogkivonatot a kéréshez. Javasoljuk, hogy fontolja meg a korrelációs jogkivonatok használatát, mert ezek segíthetnek a hibák elhárításában. Segítenek a probléma kiváltó okának meghatározásában, a hatás felmérésében és a probléma megoldásának megközelítésében.

A korrelációs jogkivonatokkal lekérheti a kérelem nyomvonalát, ha azonosítja, hogy mely szolgáltatások tartalmazzák a korrelációs jogkivonatot, és melyek nem. Azok a szolgáltatások, amelyek nem rendelkeznek a kérés korrelációs jogkivonatával, meghiúsultak. Ha hiba történik, később újra megpróbálhatja a tranzakciót. Az idempotencia kényszerítéséhez csak azok a szolgáltatások fogják kiszolgálni a kérést, amelyek nem rendelkeznek korrelációs jogkivonattal.

Ha például sok szolgáltatást magában foglaló hosszú műveleti lánccal rendelkezik, a korrelációs jogkivonat szolgáltatásoknak való átadása segíthet a problémák egyszerű kivizsgálásában, ha valamelyik szolgáltatás meghiúsul egy tranzakció során. Minden szolgáltatásnak általában saját adatbázisa van. A korrelációs jogkivonat az adatbázisrekordban van tárolva. Tranzakció visszajátszása esetén azok a szolgáltatások, amelyek az adott korrelációs jogkivonattal rendelkeznek az adatbázisukban, figyelmen kívül hagyják a kérést. Csak azok a szolgáltatások szolgálják ki a kérést, amelyek nem rendelkeznek jogkivonattal.

Vegye figyelembe az alábbi tényezőket:

  • Melyik szakaszban rendeli hozzá a korrelációs jogkivonatot?
  • Melyik összetevő rendeli hozzá a korrelációs jogkivonatot?
  • Menti a korrelációs jogkivonatokat a szolgáltatás adatbázisába?
  • Mi a korrelációs jogkivonatok formátuma?
  • Naplózza a korrelációs jogkivonatokat és más kérésadatokat?

Mikroszolgáltatás-keretrendszer szükségességének felmérése

A mikroszolgáltatás-keretrendszer egy alap keretrendszer, amely lehetővé teszi a horizontális szempontokat, például a naplózást, a kivételkezelést, az elosztott nyomkövetést, a biztonságot és a kommunikációt. A futómű-keretrendszer használata esetén inkább a szolgáltatáshatár megvalósítására összpontosít, mint az infrastruktúra funkcióinak használatára.

Tegyük fel például, hogy egy bevásárlókocsi-felügyeleti szolgáltatást hoz létre. Ellenőrizni szeretné a bejövő jogkivonatot, naplókat szeretne írni a naplózási adatbázisba, és kommunikálni szeretne egy másik szolgáltatással a szolgáltatás végpontjának meghívásával. Ha mikroszolgáltatás-keretrendszert használ, csökkentheti a fejlesztési erőfeszítéseket. A Dapr egy olyan rendszer, amely különböző építőelemeket biztosít a horizontális szempontok megvalósításához.

Vegye figyelembe az alábbi tényezőket:

  • Mikroszolgáltatás-keretrendszert használ?
  • Használja a Dapr-t a keresztirányú aggodalmakra?
  • A váz keretrendszerének nyelve agnosztikus?
  • Általános a váz keretrendszere, így mindenféle alkalmazást támogat? A váz keretrendszerének nem szabad alkalmazásspecifikus logikát tartalmaznia.
  • Biztosít-e a váz keretrendszere egy mechanizmust a kiválasztott összetevők vagy szolgáltatások igény szerinti használatára?

Az alkalmazástesztelés megközelítésének értékelése

A tesztelés hagyományosan a fejlesztés befejezése után történik, és az alkalmazás készen áll a felhasználói elfogadási tesztelés (UAT) és az éles környezetek bevezetésére. Ebben a megközelítésben jelenleg eltolódás tapasztalható, és a tesztelést az alkalmazásfejlesztési életciklus korai szakaszában (balra) helyezi át. A bal oldali váltásos tesztelés növeli az alkalmazások minőségét, mivel a tesztelés az alkalmazásfejlesztési életciklus minden fázisában megtörténik, beleértve a tervezés, a fejlesztés és a fejlesztés utáni fázisokat is.

Például egy alkalmazás létrehozásakor először egy architektúra tervezésével kell kezdenie. A bal oldali váltásos megközelítés használata esetén tesztelheti a biztonsági rések kialakítását olyan eszközökkel, mint a Microsoft Threat Modeling. A fejlesztés megkezdésekor olyan eszközök futtatásával vizsgálhatja a forráskódot, mint a statikus alkalmazásbiztonsági tesztelés (SAST) és más elemzők használata a problémák feltárásához. Az alkalmazás üzembe helyezése után az olyan eszközökkel, mint a dinamikus alkalmazásbiztonsági tesztelés (DAST) segítségével tesztelheti azt, amíg az üzemel. A funkcionális tesztelés, a káosztesztelés, a behatolástesztelés és más típusú tesztelések később történnek.

Vegye figyelembe az alábbi tényezőket:

  • Olyan tesztterveket ír, amelyek a teljes fejlesztési életciklust lefedik?
  • Tesztelőket is bevon a követelményértekezletekbe és az alkalmazásfejlesztés teljes életciklusába?
  • Tesztalapú vagy viselkedésvezérelt kialakítást használ?
  • Teszteli a felhasználói történeteket? Belefoglalja az elfogadási feltételeket a felhasználói történetekbe?
  • Teszteli a tervezést olyan eszközökkel, mint a Microsoft Threat Modeling?
  • Egységteszteket ír?
  • Statikus kódelemzőket vagy más eszközöket használ a kódminőség mérésére?
  • Automatizált eszközöket használ az alkalmazások teszteléséhez?
  • Implementálja a Biztonságos DevOps-eljárásokat ?
  • Végez integrációs tesztelést, teljes körű alkalmazástesztelést, terhelés-/teljesítménytesztelést, behatolástesztelést és káosztesztelést?

Mikroszolgáltatások biztonságának felmérése

A szolgáltatásvédelem, a biztonságos hozzáférés és a biztonságos kommunikáció a mikroszolgáltatás-architektúra legfontosabb szempontjai közé tartozik. Egy több szolgáltatásra kiterjedő és jogkivonat-érvényesítéssel rendelkező mikroszolgáltatás-alapú rendszer például nem járható út. Ez a rendszer hatással lenne a teljes rendszer rugalmasságára, valamint a megvalósítási eltérések bevezetésének lehetőségeire a szolgáltatások között.

A biztonsági problémákat általában az API-átjáró és az alkalmazás tűzfala kezeli. Az átjáró és a tűzfal fogad bejövő kéréseket, érvényesíti a jogkivonatokat, és különböző szűrőket és szabályzatokat alkalmaz, például az OWASP 10 legfontosabb alapelvét alkalmazza a forgalom elfogásához. Végül elküldik a kérést a háttérbeli mikroszolgáltatásoknak. Ez a konfiguráció segít a fejlesztőknek az üzleti igényekre összpontosítani, nem pedig a biztonságra vonatkozó átfogó aggodalmakra.

Vegye figyelembe az alábbi tényezőket:

  • Szükség van hitelesítésre és engedélyezésre a szolgáltatáshoz?
  • API-átjárót használ a jogkivonatok és a bejövő kérések érvényesítéséhez?
  • SSL-t vagy mTLS-t használ a szolgáltatáskommunikáció biztonságának biztosítására?
  • Rendelkezik hálózati biztonsági szabályzatokkal, amelyek lehetővé teszik a szükséges kommunikációt a szolgáltatások között?
  • Adott esetben tűzfalakat (L4, L7) használ a belső és külső kommunikáció biztonságának biztosítására?
  • Biztonsági szabályzatokat használ az API Gatewayben a forgalom szabályozásához?

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

További lépések