Microservices architecture on Azure Service Fabric

Ez a referenciaarchitektúra az Azure Service Fabricben üzembe helyezett mikroszolgáltatás-architektúrát mutatja be. Egy alapszintű fürtkonfigurációt jelenít meg, amely a legtöbb üzembe helyezés kiindulópontja lehet.

Az architektúra referencia-implementációja elérhető a GitHubon.

Felépítés

Töltse le az architektúra Visio-fájlját.

Munkafolyamat

Az architektúra a következőkben leírt összetevőkből áll. Egyéb kifejezésekért tekintse meg a Service Fabric terminológiájának áttekintését.

• Service Fabric-fürt. A fürtök olyan virtuális gépek (VM-ek) hálózattal összekapcsolt készletei, amelyekbe üzembe helyezi és felügyeli a mikroszolgáltatásokat.

• Virtuálisgép-méretezési csoportok. A virtuálisgép-méretezési csoportok lehetővé teszik az azonos, terheléselosztásos és automatikus skálázású virtuális gépek csoportjának létrehozását és kezelését. Ezek a számítási erőforrások a tartalék és a frissítési tartományokat is biztosítják.

• Csomópontok. A csomópontok a Service Fabric-fürthöz tartozó virtuális gépek.

• Csomóponttípusok. A csomóponttípusok egy csomópontgyűjteményt üzembe helyező virtuálisgép-méretezési csoportot jelölnek. Egy Service Fabric-fürt legalább egy csomóponttípussal rendelkezik.

  Több csomóponttípusú fürtben az elsődleges csomóponttípust kell deklarálni. A fürt elsődleges csomóponttípusa a Service Fabric rendszerszolgáltatásokat futtatja. Ezek a szolgáltatások a Service Fabric platformképességeit biztosítják. Az elsődleges csomóponttípus a magcsomópontokként is működik, amelyek az alapul szolgáló fürt rendelkezésre állását karbantartó csomópontok.

  Konfiguráljon további csomóponttípusokat a szolgáltatások futtatásához.

• Szolgáltatások. A szolgáltatás önálló függvényt hajt végre, amely más szolgáltatásoktól függetlenül indítható és futtatható. A szolgáltatások példányai üzembe lesznek helyezve a fürt csomópontjaiban. A Service Fabricben kétféle szolgáltatás érhető el:

  • Állapot nélküli szolgáltatás. Az állapot nélküli szolgáltatások nem tartják fenn az állapotot a szolgáltatáson belül. Ha állapotmegőrzésre van szükség, akkor az állapotot egy külső tárolóba, például az Azure Cosmos DB-be írja és kéri le.
  • Állapotalapú szolgáltatás. A szolgáltatás állapota a szolgáltatáson belül marad. A legtöbb állapotalapú szolgáltatás ezt a Service Fabric megbízható gyűjteményeinek használatával valósítja meg.

• Service Fabric Explorer. A Service Fabric Explorer egy nyílt forráskódú eszköz a Service Fabric-fürtök vizsgálatához és kezeléséhez.

• Azure Pipelines. Az Azure Pipelines az Azure DevOps Services része, és automatizált buildeket, teszteket és üzembe helyezéseket futtat. Használhat külső féltől származó folyamatos integrációs és folyamatos kézbesítési (CI/CD) megoldásokat is, például a Jenkinst.

• Azure Monitor. Az Azure Monitor metrikákat és naplókat gyűjt és tárol, beleértve a megoldásban és az alkalmazástelemetria Azure-szolgáltatásainak platformmetrikáit is. Ezekkel az adatokkal figyelheti az alkalmazást, riasztásokat és irányítópultokat állíthat be, és elvégezheti a hibák kiváltó okainak elemzését. Az Azure Monitor integrálva van a Service Fabricdel, hogy metrikákat gyűjtsön a vezérlőkből, csomópontokból és tárolókból, valamint tároló- és csomópontnaplókból.

• Azure Key Vault. A Key Vault használatával tárolhatja a mikroszolgáltatások által használt alkalmazáskulcsokat, például kapcsolati sztring.

• Azure API Management. Ebben az architektúrában az API Management API-átjáróként működik, amely fogadja az ügyfelektől érkező kéréseket, és átirányítja őket a szolgáltatásokhoz.

Considerations

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javításához szükséges alapvető szempontok halmaza.

Design considerations

Ez a referenciaarchitektúra a mikroszolgáltatás-architektúrákra összpontosít. A mikroszolgáltatások egy kis, egymástól független verziójú kódegységek. Szolgáltatásfelderítési mechanizmusokon keresztül felderíthető, és api-kon keresztül kommunikálhat más szolgáltatásokkal. Mindegyik szolgáltatás önálló, és egyetlen üzleti képességet valósít meg. Az alkalmazástartomány mikroszolgáltatásokra való lebontásáról további információt a Mikroszolgáltatások modellezése tartományelemzéssel című témakörben talál.

A Service Fabric egy infrastruktúrát biztosít a mikroszolgáltatások hatékony létrehozásához, üzembe helyezéséhez és frissítéséhez. Emellett lehetőséget biztosít az automatikus skálázásra, az állapot kezelésére, az állapot monitorozására és a szolgáltatások meghibásodás esetén történő újraindítására.

A Service Fabric egy olyan alkalmazásmodellt követ, amelyben az alkalmazás mikroszolgáltatások gyűjteménye. Az alkalmazást egy alkalmazásjegyzékfájl ismerteti. Ez a fájl határozza meg az alkalmazás által tartalmazott szolgáltatások típusait, valamint a független szolgáltatáscsomagokra mutató hivatkozásokat.

Az alkalmazáscsomag általában olyan paramétereket is tartalmaz, amelyek felülírják a szolgáltatások által használt bizonyos beállításokat. Minden szolgáltatáscsomag rendelkezik egy jegyzékfájllal, amely leírja a szolgáltatás futtatásához szükséges fizikai fájlokat és mappákat, beleértve a bináris fájlokat, a konfigurációs fájlokat és az írásvédett adatokat. A szolgáltatások és alkalmazások egymástól függetlenül verziószámozottak és frissíthetők.

Az alkalmazásjegyzék opcionálisan leírhatja azokat a szolgáltatásokat, amelyek automatikusan ki vannak építve az alkalmazás egy példányának létrehozásakor. Ezeket alapértelmezett szolgáltatásoknak nevezzük. Ebben az esetben az alkalmazásjegyzék azt is ismerteti, hogyan kell létrehozni ezeket a szolgáltatásokat. Ezek az információk tartalmazzák a szolgáltatás nevét, a példányok számát, a biztonsági vagy elkülönítési szabályzatot, valamint az elhelyezési korlátozásokat.

További információ: Így szeretne többet megtudni a Service Fabricről?.

Alkalmazások közötti csomagolási modell

A mikroszolgáltatások nagy része az, hogy minden szolgáltatás egymástól függetlenül telepíthető. A Service Fabricben, ha az összes szolgáltatást egyetlen alkalmazáscsomagba csoportosítja, és egy szolgáltatás nem frissíthető, a teljes alkalmazásfrissítés vissza lesz állítva. Ez a visszaállítás megakadályozza más szolgáltatások frissítését.

Ezért a mikroszolgáltatás-architektúrában több alkalmazáscsomag használatát javasoljuk. Helyezzen egy vagy több szorosan kapcsolódó szolgáltatástípust egyetlen alkalmazástípusba. Tegyük fel például, hogy a szolgáltatástípusok ugyanabban az alkalmazástípusban vannak elhelyezve, ha a csapat felelős az alábbi attribútumokkal rendelkező szolgáltatásokért:

• Ugyanazon időtartamig futnak, és egyszerre kell frissíteni őket.
• Ugyanolyan életciklusuk van.
• Olyan erőforrásokat osztanak meg, mint a függőségek vagy a konfiguráció.

A Service Fabric programozási modelljei

Amikor mikroszolgáltatást ad hozzá egy Service Fabric-alkalmazáshoz, döntse el, hogy rendelkezik-e olyan állapottal vagy adatokkal, amelyeket magas rendelkezésre állásúvá és megbízhatóvá kell tenni. Ha igen, tárolhat-e adatokat külsőleg, vagy az adatokat a szolgáltatás részeként tárolja? Válasszon állapot nélküli szolgáltatást, ha nincs szüksége adatok tárolására, vagy ha külső tárolóban szeretné tárolni az adatokat. Fontolja meg az állapotalapú szolgáltatás kiválasztását, ha az alábbi utasítások valamelyike érvényes:

• Állapotot vagy adatokat szeretne fenntartani a szolgáltatás részeként. Az adatoknak például a kódhoz közeli memóriában kell elhelyezkedniük.
• Nem tolerálhatja a külső tárolóktól való függőséget.

Ha rendelkezik olyan kóddal, amelyet a Service Fabricen szeretne futtatni, futtathatja vendég végrehajthatóként: tetszőleges végrehajthatóként, amely szolgáltatásként fut. Másik lehetőségként csomagolhatja a végrehajtható fájlt egy olyan tárolóba, amely rendelkezik az üzembe helyezéshez szükséges összes függőségsel.

A Service Fabric állapot nélküli szolgáltatásként modellezi a tárolókat és a vendég végrehajtható fájlokat is. A modell kiválasztásával kapcsolatos útmutatásért tekintse meg a Service Fabric programozási modell áttekintését.

Ön a felelős azért, hogy fenntartsa azt a környezetet, amelyben egy vendég végrehajtható futtatható. Tegyük fel például, hogy egy vendég végrehajtható fájlhoz Python szükséges. Ha a végrehajtható fájl nem önálló, győződjön meg arról, hogy a Python szükséges verziója előre telepítve van a környezetben. A Service Fabric nem kezeli a környezetet. Az Azure több mechanizmust is kínál a környezet beállításához, beleértve az egyéni virtuálisgép-rendszerképeket és -bővítményeket.

Ha egy fordított proxyn keresztül végrehajtható vendéghez szeretne hozzáférni, győződjön meg arról, hogy hozzáadta az UriScheme attribútumot a Endpoint vendég végrehajtható szolgáltatásjegyzékében szereplő elemhez.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Ha a szolgáltatás további útvonalakat is biztosít, adja meg az útvonalakat az PathSuffix értékben. Az értéket nem szabad előtaggal vagy perjellel (/) utótaggal utótagként megadni. Egy másik módszer az útvonal hozzáadása a szolgáltatásnévhez.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

For more information, see:

• Alkalmazás becsomagolása
• Meglévő végrehajtható fájl csomagolása és üzembe helyezése a Service Fabricben

API-átjáró

Egy API-átjáró (bejövő forgalom) a külső ügyfelek és a mikroszolgáltatások között helyezkedik el. Fordított proxyként működik, amely az ügyfelektől a mikroszolgáltatásokhoz irányuló kéréseket irányítja át. Emellett olyan átfogó feladatokat is végrehajthat, mint a hitelesítés, az SSL-lezárás és a sebességkorlátozás.

A legtöbb forgatókönyvhöz az Azure API Managementet javasoljuk, de a Traefik egy népszerű nyílt forráskódú alternatíva. Mindkét technológiai lehetőség integrálva van a Service Fabricdel.

• API Management. Nyilvános IP-címet tesz elérhetővé, és átirányítja a forgalmat a szolgáltatásokhoz. Egy dedikált alhálózaton fut ugyanabban a virtuális hálózaton, mint a Service Fabric-fürt.

  Az API Management olyan csomóponttípusú szolgáltatásokat érhet el, amelyek privát IP-címmel rendelkező terheléselosztón keresztül érhetők el. Ez a lehetőség csak az API Management prémium és fejlesztői szintjeiben érhető el. Éles számítási feladatokhoz használja a Prémium szintet. A díjszabási információkat az API Management díjszabása ismerteti.

  További információ: Service Fabric és Azure API Management – áttekintés.

• Traefik. Olyan funkciókat támogat, mint az útválasztás, a nyomkövetés, a naplók és a metrikák. A Traefik állapot nélküli szolgáltatásként fut a Service Fabric-fürtben. A szolgáltatás verziószámozása útválasztással támogatott.

  A Traefik szolgáltatásbemenethez való beállításáról és a fürt fordított proxyjaként való beállításáról az Azure Service Fabric Provider a Traefik webhelyén tájékozódhat. A Traefik Service Fabrictel való használatáról további információt az Intelligens útválasztás a Service Fabric és a Traefik között című blogbejegyzésben talál.

A Traefik az Azure API Managementtel ellentétben nem rendelkezik olyan funkcióval, amellyel feloldható egy állapotalapú szolgáltatás (több partícióval) partíciója, amelyhez a kérés átirányítva van. További információ: Egyező hozzáadása particionálási szolgáltatásokhoz.

Más API-kezelési lehetőségek közé tartozik az Azure-alkalmazás Gateway és az Azure Front Door. Ezeket a szolgáltatásokat az API Managementtel együtt használhatja olyan feladatok végrehajtására, mint az útválasztás, az SSL-leállítás és a tűzfal.

Szolgáltatások közötti kommunikáció

A szolgáltatások közötti kommunikáció megkönnyítése érdekében vegye figyelembe a következő javaslatokat:

• Kommunikációs protokoll. A mikroszolgáltatás-architektúrában a szolgáltatásoknak futásidőben minimális összekapcsolással kell kommunikálniuk egymással. A nyelvi kommunikáció engedélyezéséhez a HTTP egy iparági szabvány, amely számos különböző nyelven elérhető eszközt és HTTP-kiszolgálót kínál. A Service Fabric támogatja ezeket az eszközöket és kiszolgálókat.

  A legtöbb számítási feladat esetében azt javasoljuk, hogy a Service Fabricbe beépített szolgáltatás-átnevezés helyett a HTTP-t használja.

• Szolgáltatásfelderítés. A fürt más szolgáltatásaival való kommunikációhoz az ügyfélszolgáltatásnak fel kell oldania a célszolgáltatás aktuális helyét. A Service Fabricben a szolgáltatások a csomópontok között mozoghatnak, és a szolgáltatásvégpontok dinamikusan változhatnak.

  Az elavult végpontokkal való kapcsolatok elkerülése érdekében a Service Fabric elnevezési szolgáltatásával lekérheti a frissített végpontadatokat. A Service Fabric azonban egy beépített fordított proxyszolgáltatást is biztosít, amely absztrakciót biztosít az elnevezési szolgáltatáson. Ezt a lehetőséget a legtöbb forgatókönyv alapkonfigurációjaként javasoljuk a szolgáltatásfelderítéshez, mivel egyszerűbben használható és egyszerűbb kódot eredményez.

A szolgáltatásközi kommunikáció egyéb lehetőségei a következők:

• Traefik a speciális útválasztáshoz.
• DNS kompatibilitási forgatókönyvekhez, ahol a szolgáltatás a DNS használatát várja.
• A ServicePartitionClient<TCommunicationClient> osztály, amely gyorsítótárazza a szolgáltatásvégpontokat. Ez jobb teljesítményt tud lehetővé tenni, mivel a hívások közvetlenül a szolgáltatások között, közvetítők vagy egyéni protokollok nélkül mennek.

Méretezhetőség

A Service Fabric támogatja a fürt entitásainak skálázását:

• Csomópontok számának skálázása az egyes csomóponttípusokhoz
• Skálázási szolgáltatások

Ez a szakasz az automatikus skálázásra összpontosít. Dönthet úgy, hogy manuálisan méretez olyan helyzetekben, amikor ez a megfelelő. Előfordulhat például, hogy manuális beavatkozásra van szükség a példányok számának beállításához.

Kezdeti fürtkonfiguráció a méretezhetőség érdekében

Service Fabric-fürt létrehozásakor hozza létre a csomóponttípusokat a biztonsági és méretezhetőségi igények alapján. Minden csomóponttípus egy virtuálisgép-méretezési csoporthoz van rendelve, és egymástól függetlenül skálázható.

• Hozzon létre egy csomóponttípust minden olyan szolgáltatáscsoporthoz, amely különböző méretezhetőségi vagy erőforrás-követelményekkel rendelkezik. Először kiépíti a Service Fabric rendszerszolgáltatások csomóponttípusát (amely az elsődleges csomóponttípus lesz). Hozzon létre külön csomóponttípusokat a nyilvános vagy előtérbeli szolgáltatások futtatásához. Szükség szerint hozzon létre más csomóponttípusokat a háttér- és magán- vagy izolált szolgáltatásokhoz. Adja meg az elhelyezési korlátozásokat , hogy a szolgáltatások csak a kívánt csomóponttípusokra legyenek üzembe helyezve.
• Adja meg az egyes csomóponttípusok tartóssági szintjét . A tartóssági szint azt jelenti, hogy a Service Fabric képes befolyásolni a virtuálisgép-méretezési csoportok frissítési és karbantartási műveleteit. Éles számítási feladatokhoz válasszon ezüst vagy magasabb tartóssági szintet. Az egyes szintekről további információt a fürt tartóssági jellemzőiben talál.
• Ha a Bronz tartóssági szintet használja, bizonyos műveletek manuális lépéseket igényelnek. A Bronz tartóssági szinttel rendelkező csomóponttípusok további lépéseket igényelnek a méretezés során. A skálázási műveletekkel kapcsolatos további információkért tekintse meg ezt az útmutatót.

Csomópontok méretezése

A Service Fabric támogatja az automatikus méretezést a vertikális felskálázáshoz és a vertikális felskálázáshoz. Az egyes csomóponttípusok egymástól függetlenül konfigurálhatók az automatikus skálázáshoz.

Minden csomóponttípus legfeljebb 100 csomópontot tartalmazhat. Kezdjen kisebb csomópontkészlettel, és adjon hozzá további csomópontokat a terheléstől függően. Ha több mint 100 csomópontra van szüksége egy csomóponttípusban, több csomóponttípust kell hozzáadnia. További részletekért tekintse meg a Service Fabric-fürt kapacitástervezési szempontjait. A virtuálisgép-méretezési csoportok nem skálázhatók azonnal, ezért ezt a tényezőt érdemes figyelembe venni az automatikus méretezési szabályok beállításakor.

Az automatikus méretezés támogatásához konfigurálja úgy a csomóponttípust, hogy a Silver vagy Gold tartóssági szinttel rendelkezzen. Ez a konfiguráció gondoskodik arról, hogy a skálázás késleltetve legyen, amíg a Service Fabric nem fejezi be a szolgáltatások áthelyezését. Arról is gondoskodik, hogy a virtuálisgép-méretezési csoportok tájékoztassák a Service Fabricet arról, hogy a virtuális gépek el lettek távolítva, nem csak ideiglenesen.

További információ a csomópont- vagy fürtszintű skálázásról: Azure Service Fabric-fürtök skálázása.

Skálázási szolgáltatások

Az állapot nélküli és állapotalapú szolgáltatások a skálázás különböző megközelítéseit alkalmazzák.

Állapot nélküli szolgáltatás esetén (automatikus skálázás):

• Használja az átlagos partícióbetöltési eseményindítót. Ez az eseményindító határozza meg, hogy a skálázási szabályzatban megadott terhelési küszöbérték alapján mikor skálázható fel vagy skálázható ki a szolgáltatás. Azt is beállíthatja, hogy milyen gyakran legyen bejelölve az eseményindító. Lásd: Átlagos partícióbetöltési eseményindító példányalapú skálázással. Ezzel a módszerrel felskálázhatja az elérhető csomópontok számát.
• Állítsa InstanceCount -1 értékre a szolgáltatásjegyzékben, amely arra utasítja a Service Fabricet, hogy minden csomóponton futtassa a szolgáltatás egy példányát. Ez a megközelítés lehetővé teszi, hogy a szolgáltatás dinamikusan skálázható legyen a fürt skálázása során. A fürt csomópontjainak száma megváltozik, a Service Fabric automatikusan létrehozza és törli az egyező szolgáltatáspéldányokat.

Állapotalapú szolgáltatás esetén a skálázást a partíciók száma, az egyes partíciók mérete és a gépen futó partíciók vagy replikák száma szabályozza:

• Particionált szolgáltatások létrehozásakor győződjön meg arról, hogy minden csomópont megfelelő replikákat kap a számítási feladat egyenletes elosztásához erőforrás-versengés nélkül. Ha további csomópontokat ad hozzá, a Service Fabric alapértelmezés szerint elosztja a számítási feladatokat az új gépekre. Ha például 5 csomópont és 10 partíció van, a Service Fabric alapértelmezés szerint két elsődleges replikát helyez el az egyes csomópontokon. Ha felskálázza a csomópontokat, nagyobb teljesítményt érhet el, mert a munka egyenletesen oszlik el több erőforrás között.

  A stratégia előnyeit kihasználó forgatókönyvekről további információt a Service Fabric skálázása című témakörben talál.

• A partíciók hozzáadása vagy eltávolítása nem támogatott. A skálázáshoz gyakran használt másik lehetőség a szolgáltatások vagy a teljes alkalmazáspéldányok dinamikus létrehozása vagy törlése. Erre a mintára egy példát a skálázás az új nevesített szolgáltatások létrehozásával vagy eltávolításával ismertet.

For more information, see:

• Service Fabric-fürt méretezése automatikus skálázási szabályokkal vagy manuálisan
• Service Fabric-fürt programozott skálázása
• Service Fabric-fürt vertikális felskálázása virtuálisgép-méretezési csoport hozzáadásával

Metrikák használata a terheléselosztáshoz

A partíció tervezésétől függően előfordulhat, hogy a replikákkal rendelkező csomópontok nagyobb forgalmat bonyolítanak le, mint mások. A helyzet elkerülése érdekében particionálja a szolgáltatás állapotát úgy, hogy az az összes partíció között el legyen osztva. Használja a tartományparticionálási sémát egy jó kivonatoló algoritmussal. Lásd a particionálás első lépéseit.

A Service Fabric metrikákkal tudja, hogyan helyezheti el és egyensúlyozza ki a szolgáltatásokat a fürtön belül. A szolgáltatás létrehozásakor megadhat egy alapértelmezett terhelést a szolgáltatáshoz társított egyes metrikákhoz. A Service Fabric ezután figyelembe veszi ezt a terhelést a szolgáltatás elhelyezésekor, vagy amikor a szolgáltatásnak át kell lépnie (például a frissítések során), hogy kiegyensúlyozza a fürt csomópontjait.

A szolgáltatás eredetileg megadott alapértelmezett terhelése nem változik a szolgáltatás élettartama alatt. Egy szolgáltatás változó metrikáinak rögzítéséhez javasoljuk, hogy figyelje a szolgáltatást, majd jelentse a terhelést dinamikusan. Ez a módszer lehetővé teszi, hogy a Service Fabric az adott időpontban jelentett terhelés alapján módosítsa a foglalást. Az egyéni metrikák jelentéséhez használja az IServicePartition.ReportLoad metódust. További információ: Dinamikus terhelés.

Elérhetőség

Helyezze a szolgáltatásokat az elsődleges csomóponttípustól eltérő csomóponttípusba. A Service Fabric rendszerszolgáltatásai mindig az elsődleges csomóponttípuson vannak üzembe helyezve. Ha a szolgáltatások az elsődleges csomóponttípuson vannak üzembe helyezve, az erőforrások rendszerszolgáltatásaival versenyezhetnek (és zavarhatják őket). Ha egy csomóponttípus várhatóan állapotalapú szolgáltatásokat fog üzemeltetni, győződjön meg arról, hogy legalább öt csomópontpéldány van, és a Silver vagy Gold tartóssági szintet választja.

Fontolja meg a szolgáltatások erőforrásainak korlátozását. Lásd: Erőforrás-szabályozási mechanizmus.

Íme néhány gyakori szempont:

• Ne keverje az erőforrás által szabályozott szolgáltatásokat és azokat a szolgáltatásokat, amelyek nem ugyanazon a csomóponttípuson vannak szabályozva. Előfordulhat, hogy a nem szabályozott szolgáltatások túl sok erőforrást használnak fel, és hatással vannak a szabályozott szolgáltatásokra. Adjon meg elhelyezési korlátozásokat annak érdekében, hogy ezek a szolgáltatások ne fussanak ugyanazon a csomópontkészleten. (Ez egy példa a Válaszfal minta.)
• Adja meg a szolgáltatáspéldány számára lefoglalni kívánt processzormagokat és memóriát. Az erőforrás-szabályozási szabályzatok használatával és korlátozásával kapcsolatos információkért lásd: Erőforrás-szabályozás.

Egyetlen hibapont (SPOF) elkerülése érdekében győződjön meg arról, hogy minden szolgáltatás célpéldánya vagy replikaszáma nagyobb egynél. A szolgáltatáspéldányként vagy replikaszámként használható legnagyobb szám megegyezik a szolgáltatást korlátozó csomópontok számával.

Győződjön meg arról, hogy minden állapotalapú szolgáltatás legalább két aktív másodlagos replikával rendelkezik. Az éles számítási feladatokhoz öt replikát ajánlunk.

További információ: Service Fabric-szolgáltatások elérhetősége.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.

Az alábbiakban néhány fontos pontot talál az alkalmazás Service Fabricen való biztonságossá tételéhez.

Virtuális hálózat

Fontolja meg az alhálózatok határainak meghatározását az egyes virtuálisgép-méretezési csoportokhoz a kommunikáció folyamatának szabályozásához. Minden csomóponttípus saját virtuálisgép-méretezési csoporttal rendelkezik a Service Fabric-fürt virtuális hálózatán belüli alhálózatban. A hálózati forgalom engedélyezéséhez vagy elutasításához hálózati biztonsági csoportokat (NSG-ket) adhat hozzá az alhálózatokhoz. Előtér- és háttércsomópont-típusok esetén például hozzáadhat egy NSG-t a háttér-alhálózathoz, hogy csak az előtér-alhálózatról fogadja el a bejövő forgalmat.

Ha külső Azure-szolgáltatásokat hív meg a fürtből, használjon virtuális hálózati szolgáltatásvégpontokat , ha az Azure-szolgáltatás támogatja azt. A szolgáltatásvégpont használata csak a fürt virtuális hálózatára védi a szolgáltatást.

Ha például az Azure Cosmos DB-t használja az adatok tárolására, konfigurálja az Azure Cosmos DB-fiókot egy szolgáltatásvégponttal, hogy csak egy adott alhálózatról engedélyezze a hozzáférést. Lásd: Azure Cosmos DB-erőforrások elérése virtuális hálózatokból.

Végpontok és szolgáltatások közötti kommunikáció

Ne hozzon létre nem biztonságos Service Fabric-fürtöt. Ha a fürt felügyeleti végpontokat tesz elérhetővé a nyilvános interneten, a névtelen felhasználók csatlakozhatnak hozzá. A nem biztonságos fürtök nem támogatottak éles számítási feladatokhoz. Lásd a Service Fabric-fürt biztonsági forgatókönyveit.

A szolgáltatásközi kommunikáció biztonságossá tételéhez:

• Fontolja meg a HTTPS-végpontok engedélyezését a ASP.NET Core- vagy Java-webszolgáltatásokban.
• Hozzon létre biztonságos kapcsolatot a fordított proxy és a szolgáltatások között. További részletekért tekintse meg a biztonságos szolgáltatáshoz való Csatlakozás.

API-átjáró használata esetén ki lehet kapcsolni a hitelesítést az átjáróra. Győződjön meg arról, hogy az egyes szolgáltatások nem érhetőek el közvetlenül (az API-átjáró nélkül), kivéve, ha további biztonság van érvényben az üzenetek hitelesítéséhez.

Ne tegye közzé nyilvánosan a Service Fabric fordított proxyját. Ennek hatására a HTTP-végpontokat elérhetővé tevő összes szolgáltatás címezhető lesz a fürtön kívülről. Ez biztonsági réseket fog bevezetni, és szükségtelenül további információkat tesz elérhetővé a fürtön kívül. Ha nyilvánosan szeretne hozzáférni egy szolgáltatáshoz, használjon EGY API-átjárót. A cikk későbbi, API-átjáró szakasza néhány lehetőséget említ.

A Távoli asztal diagnosztikához és hibaelhárításhoz hasznos, de mindenképpen zárja be. Ha nyitva hagyja, biztonsági rést okoz.

Titkos kódok és tanúsítványok

Titkos kulcsokat( például kapcsolati sztring) tárolhat egy kulcstartóban. A kulcstartónak ugyanabban a régióban kell lennie, mint a virtuálisgép-méretezési csoportnak. Kulcstartó használata:

1. Hitelesítse a szolgáltatás kulcstartóhoz való hozzáférését.

   Engedélyezze a felügyelt identitást a szolgáltatást üzemeltető virtuálisgép-méretezési csoportban.

2. A titkos kulcsokat a kulcstartóban tárolhatja.

   Titkos kulcsok hozzáadása kulcs/érték párra lefordítható formátumban. Használja például a következőt CosmosDB--AuthKey: . A konfiguráció létrehozásakor a kettős kötőjel (--) kettőspont () kettősponttá (:) alakul.

3. Hozzáférés ezekhez a titkos kódokhoz a szolgáltatásban.

   Adja hozzá a key vault URI-t az alkalmazáshoz Gépház.json fájlhoz. A szolgáltatásban adja hozzá a kulcstartóból beolvasott konfigurációszolgáltatót, létrehozza a konfigurációt, és hozzáfér a titkos kódhoz a beépített konfigurációból.

Íme egy példa, amelyben a Munkafolyamat szolgáltatás egy titkos kulcsot tárol a kulcstartóban a formátumban CosmosDB--Database.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

A titkos kód eléréséhez adja meg a titkos kód nevét a beépített konfigurációban.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

Ne használjon ügyféltanúsítványokat a Service Fabric Explorer eléréséhez. Ehelyett használja a Microsoft Entra-azonosítót. Tekintse meg a Microsoft Entra-hitelesítést támogató Azure-szolgáltatásokat.

Ne használjon önaláírt tanúsítványokat éles környezetben.

Inaktív adatok védelme

Ha adatlemezeket csatolt a Service Fabric-fürt virtuálisgép-méretezési csoportjaihoz, és a szolgáltatások adatokat mentenek ezeken a lemezeken, titkosítania kell a lemezeket. További információ: Operációs rendszer és csatolt adatlemezek titkosítása egy virtuálisgép-méretezési csoportban az Azure PowerShell használatával (előzetes verzió).

A Service Fabric biztonságossá tételével kapcsolatos további információkért lásd:

• Az Azure Service Fabric biztonsági áttekintése
• Az Azure Service Fabric biztonsági ajánlott eljárásai
• Azure Service Fabric biztonsági ellenőrzőlista

Resiliency

A hibákból való helyreállításhoz és a teljes mértékben működőképes állapot fenntartásához az alkalmazásnak bizonyos rugalmassági mintákat kell implementálnia. Íme néhány gyakori minta:

• Újrapróbálkozás: Az átmenetinek várt hibák, például az ideiglenesen nem elérhető erőforrások kezelése.
• Megszakító: Olyan hibák elhárítása, amelyek kijavítása hosszabb időt vehet igénybe.
• Válaszfal: Az egyes szolgáltatások erőforrásainak elkülönítése.

Ez a referencia-implementáció a Pollyt, egy nyílt forráskódú lehetőséget használja az összes ilyen minta implementálásához.

Figyelés

A figyelési lehetőségek megismerése előtt javasoljuk, hogy olvassa el ezt a cikket a Service Fabric gyakori forgatókönyveinek diagnosztizálásáról. Az alábbi csoportokban figyelheti az adatokat:

• Alkalmazásmetrikák és naplók
• Service Fabric állapot- és eseményadatok
• Infrastruktúra-metrikák és naplók
• Metrikák és naplók függő szolgáltatásokhoz

Az adatok elemzésének két fő lehetősége:

• Application Insights
• Log Analytics

Az Azure Monitor használatával irányítópultokat állíthat be a monitorozáshoz, és riasztásokat küldhet az operátoroknak. Egyes külső monitorozási eszközök is integrálva vannak a Service Fabricdel, például a Dynatrace-nal. További részletekért tekintse meg az Azure Service Fabric monitorozási partnereit.

Alkalmazásmetrikák és naplók

Az alkalmazástelemetria olyan adatokat biztosít, amelyek segíthetnek a szolgáltatás állapotának monitorozásában és a problémák azonosításában. Nyomkövetések és események hozzáadása a szolgáltatásban:

• Használja a Microsoft.Extensions.Logging szolgáltatást, ha a szolgáltatást a ASP.NET Core-nal fejleszti. Más keretrendszerekhez használjon egy tetszőleges naplózási kódtárat, például a Serilogot.
• Adja hozzá saját rendszerállapotát az SDK TelemetryClient osztályával, és tekintse meg az adatokat az Alkalmazás Elemzések. Lásd: Egyéni rendszerállapot hozzáadása az alkalmazáshoz.
• Eseménykövetés naplózása Windows -eseményekhez (ETW) az EventSource használatával. Ez a lehetőség alapértelmezés szerint elérhető egy Visual Studio Service Fabric-megoldásban.

Az alkalmazás Elemzések számos beépített telemetriát biztosít: kéréseket, nyomkövetéseket, eseményeket, kivételeket, metrikákat, függőségeket. Ha a szolgáltatás HTTP-végpontokat tesz elérhetővé, engedélyezze az Alkalmazás Elemzések a UseApplicationInsights Microsoft.AspNetCore.Hosting.IWebHostBuilder bővítménymetódusának meghívásával. Az Alkalmazás Elemzések szolgáltatásának rendszerezésével kapcsolatos információkért tekintse meg az alábbi cikkeket:

• Oktatóanyag: ASP.NET Core-alkalmazás monitorozása és diagnosztizálása a Service Fabricen az Alkalmazás Elemzések használatával
• Az ASP.Net Core-hoz készült Application Insights
• Alkalmazás Elemzések .NET SDK
• Application Elemzések SDK for Service Fabric

A nyomkövetések és az eseménynaplók megtekintéséhez használja az Application Elemzések-t a strukturált naplózás egyik fogadójaként. Konfigurálja az alkalmazás Elemzések a rendszerállapot-kulccsal a bővítmény metódusának AddApplicationInsights meghívásával. Ebben a példában a rendszerállapotkulcs titkos kulcsként van tárolva a kulcstartóban.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

Ha a szolgáltatás nem tesz elérhetővé HTTP-végpontokat, egyéni bővítményt kell írnia, amely nyomkövetéseket küld az Alkalmazás Elemzések. Példaként tekintse meg a Munkafolyamat szolgáltatást a referencia-implementációban.

ASP.NET Core-szolgáltatások az ILogger felületet használják az alkalmazásnaplózáshoz. Ha elérhetővé szeretné tenni ezeket az alkalmazásnaplókat az Azure Monitorban, küldje el az eseményeket az ILogger Application Elemzések. Az alkalmazás Elemzések korrelációs tulajdonságokat adhat az eseményekhezILogger, ami hasznos lehet az elosztott nyomkövetés vizualizációjához.

For more information, see:

• Alkalmazásnaplózás
• Naplózás hozzáadása Service Fabric-alkalmazáshoz

Service Fabric állapot- és eseményadatok

A Service Fabric-telemetria állapotmetrikákat és eseményeket tartalmaz a Service Fabric-fürt és az entitások működéséről és teljesítményéről: csomópontjairól, alkalmazásairól, szolgáltatásairól, partícióiról és replikáiról. Az állapot- és eseményadatok az alábbiakból származhatnak:

• EventStore. Ez az állapotalapú rendszerszolgáltatás összegyűjti a fürthöz és annak entitásaihoz kapcsolódó eseményeket. A Service Fabric az EventStore használatával írja meg a Service Fabric-eseményeket , hogy információkat nyújtson a fürtről az állapotfrissítésekhez, a hibaelhárításhoz és a figyeléshez. Az EventStore egy adott időpontban különböző entitásokból származó eseményeket is korrelálhat a fürt problémáinak azonosítása érdekében. A szolgáltatás ezeket az eseményeket egy REST API-val teszi elérhetővé.

  Az EventStore API-k lekérdezéséről további információt az EventStore API-k lekérdezése fürteseményekhez című témakörben talál. Az eseményeket az EventStore-ból tekintheti meg a Log Analyticsben, ha konfigurálja a fürtöt a WindowsHoz készült Azure Diagnostics-bővítménysel (WAD).

• HealthStore. Ez az állapotalapú szolgáltatás pillanatképet biztosít a fürt aktuális állapotáról. Összesíti a hierarchiában lévő entitások által jelentett összes állapotadatot. Az adatok vizualizációja a Service Fabric Explorerben történik. A HealthStore az alkalmazásfrissítéseket is figyeli. Állapot-lekérdezéseket használhat a PowerShellben, a .NET-alkalmazásban vagy a REST API-kban. Lásd: Bevezetés a Service Fabric állapotmonitorozásába.

• Egyéni állapotjelentések. Fontolja meg olyan belső watchdog-szolgáltatások implementálását, amelyek rendszeres időközönként jelenthetik az egyéni állapotadatokat, például a futó szolgáltatások hibás állapotát. Az állapotjelentéseket a Service Fabric Explorerben olvashatja el.

Infrastruktúra-metrikák és naplók

Az infrastruktúra-metrikák segítenek megérteni a fürt erőforrás-lefoglalását. Az információk gyűjtésének fő lehetőségei a következők:

• WAD. Naplók és metrikák gyűjtése csomópontszinten a Windowsban. A WAD-t úgy használhatja, hogy konfigurálja az IaaSDiagnostics virtuálisgép-bővítményt bármely olyan virtuálisgép-méretezési csoporton, amely csomóponttípusra van leképezve a diagnosztikai események gyűjtéséhez. Ezek az események tartalmazhatnak Windows-eseménynaplókat, teljesítményszámlálókat, ETW/jegyzékrendszert és működési eseményeket, valamint egyéni naplókat.
• Log Analytics-ügynök. Konfigurálja a MicrosoftMonitoringAgent virtuálisgép-bővítményt Windows-eseménynaplók, teljesítményszámlálók és egyéni naplók Log Analyticsbe való küldéséhez.

Az előző mechanizmusokon keresztül gyűjtött metrikák típusai, például a teljesítményszámlálók átfedésben vannak. Ahol átfedés van, javasoljuk a Log Analytics-ügynök használatát. Mivel a Log Analytics-ügynök nem használja az Azure Storage-t, a késés alacsony. Az IaaSDiagnostics teljesítményszámlálóit nem lehet könnyen betáplálni a Log Analyticsbe.

A virtuálisgép-bővítmények használatáról további információt az Azure-beli virtuálisgép-bővítmények és -szolgáltatások című témakörben talál.

Az adatok megtekintéséhez konfigurálja a Log Analyticset a WAD-on keresztül gyűjtött adatok megjelenítésére. A Log Analytics storage-fiókból való olvasására való konfigurálásáról további információt a Log Analytics beállítása fürthöz című témakörben talál.

Megtekintheti a Service Fabric-fürthöz, számítási feladatokhoz, hálózati forgalomhoz, függőben lévő frissítésekhez és egyebekhez kapcsolódó teljesítménynaplókat és telemetriai adatokat is. Tekintse meg a Log Analytics teljesítménymonitorozását.

A Log Analytics szolgáltatástérkép-megoldása információt nyújt a fürt topológiájáról (vagyis az egyes csomópontokban futó folyamatokról). Küldje el a tárfiókban lévő adatokat az Application Elemzések. Előfordulhat, hogy az adatok az Alkalmazás Elemzések való beolvasása némi késéssel jár. Ha valós időben szeretné megtekinteni az adatokat, fontolja meg az Event Hubs konfigurálását fogadók és csatornák használatával. További információ: Eseményösszesítés és gyűjtemény WAD használatával.

Függő szolgáltatásmetrikák

• Az Application Elemzések alkalmazástérképe a szolgáltatások közötti HTTP-függőségi hívások és a telepített Alkalmazás Elemzések SDK használatával biztosítja az alkalmazás topológiáját.
• A Log Analytics szolgáltatástérképe információkat nyújt a külső szolgáltatásokból érkező és kimenő forgalomról. A Service Map integrálható más megoldásokkal, például frissítésekkel vagy biztonsággal.
• Az egyéni figyelők jelenthetik a külső szolgáltatások hibafeltételeit. A szolgáltatás például akkor tud hibaállapot-jelentést adni, ha nem fér hozzá egy külső szolgáltatáshoz vagy adattárolóhoz (Azure Cosmos DB).

Elosztott nyomkövetés

A mikroszolgáltatás-architektúrában számos szolgáltatás gyakran részt vesz egy feladat elvégzéséhez. Az egyes szolgáltatások telemetriai adatai egy elosztott nyomkövetésben lévő környezeti mezők (például műveletazonosító és kérelemazonosító) alapján vannak korrelálva.

Az Application Map alkalmazás-Elemzések használatával létrehozhatja az elosztott logikai műveletek nézetét, és megjelenítheti az alkalmazás teljes szolgáltatási gráfját. Az Application Elemzések tranzakciódiagnosztika használatával is korrelálhatja a kiszolgálóoldali telemetriát. További információ: Egyesített, összetevők közötti tranzakciók diagnosztikái.

Fontos továbbá, hogy az aszinkron módon feladott feladatokat egy üzenetsor használatával korrelálja. A korrelációs telemetria üzenetben való küldésével kapcsolatos részletekért lásd : Üzenetsor-rendszerállapot.

For more information, see:

• Lekérdezés végrehajtása több erőforrás között
• Telemetriai korreláció az Application Insightsban

Riasztások és irányítópultok

Az alkalmazás Elemzések és a Log Analytics széles körű lekérdezési nyelvet (Kusto lekérdezési nyelvet) támogat, amely lehetővé teszi a naplóadatok lekérését és elemzését. A lekérdezésekkel adatkészleteket hozhat létre és jeleníthet meg a diagnosztikai irányítópultokon.

Az Azure Monitor-riasztásokkal értesítheti a rendszergazdákat, ha bizonyos feltételek adott erőforrásokban fordulnak elő. Az értesítés lehet például e-mail, Azure-függvény vagy webhook. További információ: Riasztások az Azure Monitorban.

A naplókeresési riasztási szabályok lehetővé teszik Egy Kusto-lekérdezés definiálásához és futtatásához egy Log Analytics-munkaterületen rendszeres időközönként. A rendszer riasztást hoz létre, ha a lekérdezés eredménye megfelel egy bizonyos feltételnek.

Költségoptimalizálás

Az Azure díjkalkulátorával megbecsülheti költségeit. Egyéb szempontokat a Microsoft Azure Well-Architected Framework költségoptimalizálási pillére ismertet.

Az alábbi szempontokat érdemes figyelembe venni az architektúra egyes szolgáltatásaival kapcsolatban.

Azure Service Fabric

A Service Fabric-fürt létrehozásakor kiválasztott számítási példányokért, tárterületért, hálózati erőforrásokért és IP-címekért díjat számítunk fel. A Service Fabric üzembehelyezési díjai vannak.

Virtuálisgép-méretezési csoportok

Ebben az architektúrában a mikroszolgáltatások virtuálisgép-méretezési csoportokba vannak üzembe helyezve. A fürt részeként üzembe helyezett Azure-beli virtuális gépekért és a mögöttes infrastruktúra-erőforrásokért, például a tárolásért és a hálózatkezelésért kell fizetnie. Maguknak a virtuálisgép-méretezési csoportoknak nincsenek növekményes költségei.

Azure API Management

Az Azure API Management egy átjáró, amely átirányítja az ügyfelektől érkező kéréseket a fürt szolgáltatásaihoz.

Különböző díjszabási lehetőségek állnak rendelkezésre. A használatalapú használati mód egy átjáróösszetevőt is tartalmaz. A számítási feladat alapján válasszon egy, az API Management díjszabásában leírt lehetőséget.

Application Insights

Az Application Elemzések használatával telemetriát gyűjthet az összes szolgáltatáshoz, és strukturált módon tekintheti meg a nyomkövetéseket és az eseménynaplókat. Az Alkalmazás Elemzések díjszabása használatalapú fizetéses modell, amely a betöltött adatmennyiségen és az adatmegőrzési lehetőségeken alapul. További információ: Az alkalmazás Elemzések használatának és költségeinek kezelése.

Azure Monitor

Az Azure Monitor Log Analytics esetében az adatok betöltéséért és megőrzéséért díjat kell fizetnie. További információkért tekintse meg az Azure Monitor díjszabását.

Azure Key Vault

Az Azure Key Vault használatával titkos kulcsként tárolhatja az Alkalmazás Elemzések eszközkulcsát. Az Azure két szolgáltatási szinten kínálja a Key Vaultot. Ha nincs szüksége HSM által védett kulcsokra, válassza a Standard szintet. Az egyes szintek funkcióival kapcsolatos információkért lásd a Key Vault díjszabását.

Azure DevOps Services

Ez a referenciaarchitektúra az Azure Pipelinest használja az üzembe helyezéshez. Az Azure Pipelines szolgáltatás havi 1800 percnyi ingyenes Microsoft-feladatot tesz lehetővé CI/CD esetén, valamint egy saját üzemeltetésű feladatot, havonta korlátlan percekkel. A többletfeladatok díjjal rendelkeznek. További információkért tekintse meg az Azure DevOps Services díjszabását.

A mikroszolgáltatás-architektúrák DevOps-szempontjaiért lásd a CI/CD-t a mikroszolgáltatásokról.

Ebből az oktatóanyagból megtudhatja, hogyan helyezhet üzembe tárolóalkalmazásokat CI/CD-vel egy Service Fabric-fürtben.

A forgatókönyv üzembe helyezése

Az architektúra referencia-implementációjának üzembe helyezéséhez kövesse a GitHub-adattár lépéseit.

További lépések

• Oktatás: Az Azure Service Fabric bemutatása
• Az Azure Service Fabric áttekintése
• API Management – dokumentáció
• Mi az Az Azure Pipelines?

Kapcsolódó erőforrások

• Mikroszolgáltatások modellezése tartományelemzéssel
• Mikroszolgáltatási architektúra tervezése