Javaslatok az egyszerűség és a hatékonyság kialakításához

Az Azure Well-Architected Framework megbízhatósági ellenőrzőlistájára vonatkozó javaslat:

Ez az útmutató a szükségtelen összetettség és a többletterhelés minimalizálására vonatkozó javaslatokat ismerteti, hogy a számítási feladatok egyszerűek és hatékonyak maradjanak. Válassza ki a legjobb összetevőket a számítási feladatok elvégzéséhez a számítási feladatok megbízhatóságának optimalizálásához. A fejlesztési és felügyeleti terhek csökkentése érdekében használja ki a platform által nyújtott szolgáltatások által kínált hatékonyságot. Ezzel a kialakítással rugalmas, megismételhető, méretezhető és kezelhető számítási feladatarchitektúra hozható létre.

Meghatározások

Főbb tervezési stratégiák

A megbízhatóság tervezésének egyik legfontosabb eleme, hogy a dolgok egyszerűek és hatékonyak maradjanak. A számítási feladatok tervezését az üzleti követelményeknek való megfelelésre összpontosítva csökkentheti a szükségtelen összetettség vagy a többletterhelés kockázatát. Vegye figyelembe a cikkben található javaslatokat, amelyek segítenek a tervezéssel kapcsolatos döntések meghozatalában egy sovány, hatékony és megbízható számítási feladat létrehozása érdekében. A különböző számítási feladatok eltérő követelményekkel rendelkezhetnek a rendelkezésre állásra, a méretezhetőségre, az adatkonzisztenciára és a vészhelyreállításra vonatkozóan.

Minden tervezési döntést üzleti követelményekkel kell indokolnia. Ez a tervezési elv nyilvánvalónak tűnhet, de a számítási feladatok tervezése szempontjából kulcsfontosságú. Az alkalmazás több millió felhasználót vagy néhány ezer felhasználót támogat? Nagy a forgalom, vagy állandó a számítási feladat? Milyen szintű alkalmazáskimaradás elfogadható? Az üzleti követelmények ezeket a tervezési szempontokat hajtják.

Kompromisszum: Egy összetett megoldás több funkciót és rugalmasságot kínálhat, de hatással lehet a számítási feladat megbízhatóságára, mivel több koordinációt, kommunikációt és az összetevők kezelését igényli. Alternatív megoldás lehet, hogy egy egyszerűbb megoldás nem felel meg teljes mértékben a felhasználói elvárásoknak, vagy negatív hatással lehet a méretezhetőségre és a bővíthetőségre a számítási feladat fejlődése során.

Együttműködés az érdekelt felekkel a tervezési gyakorlatokon

Együttműködés az érdekelt felekkel a következőkkel:

• Definiáljon és rendeljen hozzá egy kritikussági szintet a számítási feladat felhasználói folyamataihoz és rendszerfolyamataihoz. A tervezést a kritikus folyamatokra összpontosítva meghatározhatja a szükséges összetevőket és a legjobb módszert a szükséges rugalmassági szint eléréséhez.

• Funkcionális és nem funkcionális követelmények meghatározása. Fontolja meg a funkcionális követelményeket annak meghatározásához, hogy egy alkalmazás végrehajt-e egy feladatot. Fontolja meg a nem funkcionális követelményeket annak meghatározásához, hogy az alkalmazás milyen jól hajt végre egy feladatot. Győződjön meg arról, hogy ismeri a nem funkcionális követelményeket, például a méretezhetőséget, a rendelkezésre állást és a késést. Ezek a követelmények befolyásolják a tervezési döntéseket és a technológiai döntéseket.

• Bontsa le a számítási feladatokat összetevőkre. Fontossági sorrendbe helyezi az egyszerűséget, a hatékonyságot és a megbízhatóságot a tervezés során. Határozza meg a folyamatok támogatásához szükséges összetevőket. Egyes összetevők több folyamatot támogatnak. Határozza meg, hogy az összetevők melyik kihívással foglalkoznak elméletileg, és fontolja meg, hogy eltávolítson egy összetevőt az egyes folyamatokból, hogy egyszerűbbé tegye a teljes kialakítást, miközben továbbra is teljes funkcionalitást biztosít. További információ: Javaslatok a hibamód-elemzés végrehajtásához.

• Hibamód-elemzéssel azonosíthatja a meghibásodás egyes pontjait és a lehetséges kockázatokat. Fontolja meg, hogy figyelembe kell-e vennie a valószínűtlen helyzeteket, például egy olyan földrajzi területet, amely jelentős természeti katasztrófát tapasztal, amely a régió összes rendelkezésre állási zónájára hatással van. Ez költséges, és jelentős kompromisszumokat igényel ezeknek a nem gyakori kockázatoknak a mérséklése érdekében. Világosan megismerheti vállalkozása kockázattűrését. További információ: Javaslatok a hibamód-elemzés végrehajtásához.

• A folyamatok rendelkezésre állási és helyreállítási céljainak meghatározása a számítási feladat architektúrájának tájékoztatása érdekében. Az üzleti metrikák közé tartoznak a szolgáltatási szintű célkitűzések (SLO-k), a szolgáltatásiszint-szerződések (SLA-k), a helyreállítás átlagos ideje (MTTR), a hibák közötti átlagos idő (MTBF), a helyreállítási idő célkitűzései (KPO-k) és a helyreállítási pont célkitűzései (RPO-k). Célértékek meghatározása ezekhez a metrikákhoz. Ez a gyakorlat kompromisszumot és kölcsönös megértést igényelhet a technológia és az üzleti csapatok között annak biztosítása érdekében, hogy az egyes csapatok céljai megfeleljenek az üzleti céloknak, és reálisak legyenek. További információkért tekintse meg a megbízhatósági célok meghatározására vonatkozó javaslatokat.

Egyszerűbb tervezési lehetőségek előnyben részesítése

Az alábbi javaslatokat az érdekelt felek bevonása nélkül hajthatja végre:

• Törekedjen az egyszerűségre és a világosságra a tervezés során. Használja az összetevők és szolgáltatások absztrakciójának és részletességének megfelelő szintjét. Kerülje a megoldás túltervezését vagy alultervezését. Ha például több kisebb függvényre bontja a kódot, nehéz megérteni, tesztelni és karbantartani.

• Elismerheti, hogy az összes sikeres alkalmazás idővel megváltozik, akár hibák kijavítása, új funkciók vagy technológiák implementálása, akár a meglévő rendszerek méretezhetőbbé és rugalmasabbá tétele.

• Lehetőség szerint az infrastruktúra (IaaS) helyett használja a platformszolgáltatás (PaaS) beállításait . Az IaaS olyan, mintha egy doboznyi alkatrész lenne. Bármit létrehozhat, de saját magának kell összeállítania. A PaaS-beállítások egyszerűbben konfigurálhatók és felügyelhetők. Nem kell virtuális gépeket (virtuális gépeket) vagy virtuális hálózatokat beállítania. Emellett nem kell karbantartási feladatokat végeznie, például javításokat és frissítéseket kell telepítenie.

• Az aszinkron üzenetkezeléssel leválaszthatja az üzenetkészítőt a fogyasztótól.

• Infrastruktúra elválasztása az üzleti logikától. Győződjön meg arról, hogy a tartománylogika nem zavarja az infrastruktúrával kapcsolatos funkciókat, például az üzenetküldést vagy az adatmegőrzést.

• Azonos szerepet betöltő funkciók külön szolgáltatásba foglalása. Minimalizálja a kód különböző függvények közötti duplikálásának szükségességét, és a szolgáltatásokat olyan jól definiált felületekkel használja fel, amelyeket a különböző összetevők könnyen felhasználhatnak. Ha például több szolgáltatásnak is hitelesítenie kell a kéréseket, áthelyezheti ezt a funkciót a saját szolgáltatásába. Ezután fejlesztheti a hitelesítési szolgáltatást. Hozzáadhat például egy új hitelesítési folyamatot anélkül, hogy az azt használó szolgáltatások bármelyikét érintenie kéne.

• Értékelje ki az igényeinek megfelelő gyakori minták és eljárások megfelelőségét. Ne kövesse azokat a trendeket vagy javaslatokat, amelyek nem feltétlenül a legjobbak a környezethez vagy a követelményekhez. A mikroszolgáltatások például nem minden alkalmazás számára a legjobb megoldás, mert összetettségi, terhelési és függőségi problémákat okozhatnak.

Elég kód fejlesztése

Az egyszerűség, a hatékonyság és a megbízhatóság alapelvei a fejlesztési gyakorlatokra is érvényesek. Egy lazán összekapcsolt, összetevővel rendelkező számítási feladatban határozza meg az összetevők által biztosított funkciókat. A folyamatok fejlesztése a funkció előnyeinek kihasználásához. Vegye figyelembe az alábbi javaslatokat a fejlesztési gyakorlatokhoz:

• Az üzleti követelményeknek való megfeleléshez használjon platformfunkciókat. Például a fejlesztés és a felügyelet kiszervezéséhez használjon alacsony kódú, kód nélküli vagy kiszolgáló nélküli megoldásokat, amelyeket a felhőszolgáltató kínál.

• Kódtárak és keretrendszerek használata.

• Fejlesztési gyakorlatként be kell vezetni a párok programozását vagy a dedikált kódkontraszt-munkameneteket.

• A halott kód azonosítására szolgáló megközelítés implementálása. Szkeptikusnak kell lennie a kódnak, amelyet az automatizált tesztek nem fednek le.

Válassza ki a megfelelő adattárat

Korábban számos szervezet nagy relációs SQL-adatbázisokban tárolta az összes adatát. A relációs adatbázisok atomi, konzisztens, izolált és tartós (ACID) garanciákat biztosítanak a relációs adattranzakciókhoz. Ezek az adatbázisok azonban hátrányokkal járnak:

• A lekérdezések költséges illesztést igényelhetnek.

• Normalizálnia kell az adatokat, és át kell strukturálnia azokat az írási sémához.

• A zárolási versengés befolyásolhatja a teljesítményt.

A relációs adatbázisok alternatívái

Egy nagy megoldásban egy adattár-technológia valószínűleg nem felel meg minden igényének. A relációs adatbázisok alternatívái a következők:

• Kulcs-érték tárolók

• Dokumentum-adatbázisok

• Keresőmotor-adatbázisok

• Idősorozat-adatbázisok

• Oszlopcsalád-adatbázisok

• Gráfadatbázisok

Minden lehetőségnek vannak előnyei és hátrányai. A különböző adattípusok jobban megfelelnek a különböző adattártípusoknak. Válassza ki az adatokhoz leginkább illő tárolási technológiát és azok használatát.

Tárolhat például egy termékkatalógust egy dokumentumadatbázisban, például az Azure Cosmos DB-ben, amely támogatja a rugalmas sémát. Minden termékleírás egy önálló dokumentum. A teljes katalógus lekérdezései esetén indexelheti a katalógust, és tárolhatja az indexet az Azure Cognitive Searchben. Előfordulhat, hogy a termékleltár bekerül egy SQL-adatbázisba, mert ezek az adatok acid-garanciákat igényelnek.

Ajánlások

• Fontolja meg a többi adattárat. A relációs adatbázisok nem mindig megfelelőek. További információt az adattármodellek ismertetése című témakörben talál.

• Ne feledje, hogy az adatok nem csak a tárolt alkalmazásadatokat tartalmazzák. Ide tartoznak az alkalmazásnaplók, események, üzenetek és a gyorsítótárak is.

• Használja a többplatformos adatmegőrzést vagy az adattártechnológiák kombinációját használó megoldásokat.

• Vegye figyelembe a rendelkezésére álló adatok típusát. Például:

  • Tranzakciós adatok SQL-adatbázisban.

  • JSON-dokumentumok egy dokumentumadatbázisban.

  • Telemetria egy idősorozat-adatbázisban.

  • Alkalmazásnaplók az Azure Cognitive Searchben.

  • Blobok az Azure Blob Storage-ban.

• A rendelkezésre állás rangsorolása a konzisztencia felett. A CAP-tétel azt jelenti, hogy kompromisszumot kell hoznia az elosztott rendszerek rendelkezésre állása és konzisztenciája között. Nem kerülheti el teljesen a hálózati partíciókat, ami a CAP-tétel másik összetevője. De egy végleges konzisztenciamodellt is alkalmazhat a magasabb rendelkezésre állás érdekében.

• Fontolja meg a fejlesztői csapat készségkészletét. Habár a többnyelvű adatmegőrzés használata előnyökkel jár, túlzásokba lehet esni. Új adattárolási technológia bevezetéséhez új képességkészletekre van szükség. Ahhoz, hogy a lehető legtöbbet hozhassa ki a technológiából, a fejlesztői csapatnak a következőt kell tennie:

  • Lekérdezések optimalizálása.

  • Hangoljon a teljesítményre.

  • A megfelelő használati minták használata.

A tárolási technológia kiválasztásakor vegye figyelembe ezeket a tényezőket:

• Kompenzáló tranzakciók használata. A többplatformos adatmegőrzéssel egyetlen tranzakció több tárolóba is írhat adatokat. Ha hiba történt, kompenzáló tranzakciók használatával visszavonhatja a befejezett lépéseket.

• Fontolja meg a kötött környezeteket, ami egy tartományalapú tervezési koncepció. A határolt környezet egy tartománymodell körüli explicit határ. A határolt környezet határozza meg a tartomány azon részeit, amelyekre a modell vonatkozik. A körülhatárolt kontextus ideális esetben az üzleti szakterület egy részterületét képezi le. Fontolja meg a többplatformos adatmegőrzést a rendszer kötött környezeteihez. Előfordulhat például, hogy a termékek megjelennek a termékkatalógus altartományában és a termékleltár altartományában. Ez a két altartomány azonban valószínűleg eltérő követelményekkel rendelkezik a termékek tárolására, frissítésére és lekérdezésére.

Az Azure megkönnyítése

Az Azure a következő szolgáltatásokat kínálja:

• Az Azure Functions egy kiszolgáló nélküli számítási szolgáltatás, amellyel minimális kóddal hozhat létre vezénylést.

• Az Azure Logic Apps egy kiszolgáló nélküli munkafolyamat-integrációs platform, amellyel vezénylést hozhat létre grafikus felhasználói felülettel vagy konfigurációs fájl szerkesztésével.

• Az Azure Event Grid egy nagymértékben skálázható, teljes mértékben felügyelt közzétételi-feliratkozási üzenetterjesztési szolgáltatás, amely rugalmas üzenethasználati mintákat kínál, amelyek az MQTT- és HTTP-protokollokat használják. Az Event Grid segítségével adatfolyamatokat hozhat létre eszközadatokkal, eseményvezérelt kiszolgáló nélküli architektúrákat hozhat létre, és alkalmazásokat integrálhat.

További információk:

• Azure számítási szolgáltatás kiválasztása
• Számítási lehetőség kiválasztása mikroszolgáltatásokhoz
• Az adatbeállítások áttekintése

Példa

Az összetevőket és azok funkcióit követelmények alapján meghatározó számítási feladat például a Reliable Web App minta.

Kapcsolódó hivatkozások

• Azure kiszolgáló nélküli
• Natív felhőbeli alkalmazások
• Az Azure-beli adatbázisok típusai

Megbízhatósági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.