Share via

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

  • Cikk

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

RE:01 Úgy tervezheti meg a számítási feladatot, hogy megfeleljen az üzleti célkitűzéseknek, és elkerülje a szükségtelen bonyolultságot vagy többletterhelést. Gyakorlati és kiegyensúlyozott megközelítéssel olyan tervezési döntéseket hozhat, amelyek a kívánt eredményt hozzák. A hatékonysági hiányosságok és a potenciális problémák csökkentése érdekében adja meg a tervezést.

Ez az útmutató a szükségtelen összetettség és 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 feladat megbízhatóságának optimalizálásához szükséges számítási feladatok elvégzéséhez. 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ásifeladat-architektúrát hozhat létre.

Definíciók

Időszak Definíció
Számítási feladat Különálló képesség vagy számítási feladat, amely logikailag elkülöníthető a többi tevékenységtől.

Kulcsfontosságú tervezési stratégiák

A megbízhatóság tervezésének egyik fő szempontja, hogy a dolgok egyszerűek és hatékonyak legyenek. 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 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 vékony, 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 különböző követelményekkel rendelkezhetnek a rendelkezésre állás, a méretezhetőség, az adatkonzisztencia és a vészhelyreállítás szempontjából.

Minden tervezési döntést meg kell indokolnia üzleti követelményekkel. Ez a tervezési elv nyilvánvalónak tűnhet, de elengedhetetlen a számítási feladatok tervezéséhez. Az alkalmazás több millió felhasználót vagy néhány ezer felhasználót támogat? Nagy forgalomcsúcsok vagy állandó számítási feladatok vannak? Milyen szintű alkalmazáskimaradás elfogadható? Az üzleti követelmények ezeket a kialakítási szempontokat veszik figyelembe.

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 nagyobb koordinációt, kommunikációt és az összetevők kezelését igényli. Alternatív megoldásként előfordulhat, 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ésével.

Együttműködési tervezési gyakorlatok

Az érdekelt felekkel együttműködve:

  • Kritikussági szint meghatározása és hozzárendelése 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 megközelítést 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 is támogatnak. Azonosítsa, hogy az összetevők melyik kihívással foglalkoznak elméletileg, és fontolja meg egy összetevő eltávolításá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éhez.

  • Használjon hibamód-elemzést a meghibásodási pontok és a lehetséges kockázatok azonosításához. Gondolja át, 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át érinti. Költséges, és jelentős kompromisszumokat igényel a nem gyakori kockázatok mérséklése érdekében. Világosan megismerheti a vállalat kockázattűrését. További információ: Javaslatok a hibamód elemzéséhez.

  • 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ásiszint-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őkorlátok (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élkitűzéseknek, és reálisak legyenek. További információ: Javaslatok a megbízhatósági célok meghatározásához.

További tervezési javaslatok

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

  • Törekedjen az egyszerűségre és a világosságra a tervezésben. 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.

  • Tegyük fel, hogy az összes sikeres alkalmazás idővel megváltozik, akár a 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 érdekében.

  • Ha lehetséges, a szolgáltatásként nyújtott 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 (VM-eket) vagy virtuális hálózatokat beállítania. Emellett nem kell karbantartási feladatokat, például javításokat és frissítéseket 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ányi logika 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 inkább a szolgáltatásokat olyan jól definiált felületekkel használja fel, amelyeket a különböző összetevők könnyen haszná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 továbbfejlesztheti a hitelesítési szolgáltatást. Hozzáadhat például egy új hitelesítési folyamatot anélkül, hogy megérintené az azt használó szolgáltatások bármelyikét.

  • Értékelje ki az igényeinek megfelelő gyakori minták és eljárások alkalmasságát . Kerülje az olyan trendek vagy javaslatok követését, 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 esetében a legjobb megoldás, mert összetettségi, többletterhelé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ő által biztosított funkciókat. Fejlessze a folyamatokat, hogy kihasználhassa ezt a funkciót. Vegye figyelembe az alábbi javaslatokat a fejlesztési gyakorlatához:

  • Az üzleti követelményeknek megfelelő platformfunkciók használata. A fejlesztés és felügyelet kiszervezéséhez például 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ódvizsgálati munkameneteket.

  • Implementáljon egy megközelítést a nem elérhető kód azonosításához. Szkeptikusnak kell lennie a kódnak, amelyet az automatizált tesztek nem fednek le.

A legjobb adattár használata az adatokhoz

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 hatással lehet a teljesítményre.

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

Egy nagy megoldásban valószínűleg egyetlen adattár-technológia nem felel meg az összes 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 azt a tárolási technológiát, amely a legjobban illeszkedik az adataihoz, és hogyan használja azokat.

Tárolhat például egy termékkatalógust egy dokumentum-adatbá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ógusra vonatkozó lekérdezések esetén indexelheti a katalógust, és tárolhatja az indexet Azure Cognitive Search. Előfordulhat, hogy a termékleltár bekerül egy SQL-adatbázisba, mert ezek az adatok ACID-garanciákat igényelnek.

Javaslatok

  • Fontolja meg a többi adattárat. A relációs adatbázisok nem mindig megfelelőek. További információ: Az adattármodellek ismertetése.

  • 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ó adattípust. Például tárolja a következőt:

    • Tranzakciós adatok SQL-adatbázisban.

    • JSON-dokumentumok egy dokumentum-adatbázisban.

    • Telemetria egy idősorozat-adatbázisban.

    • Alkalmazásnaplók Azure Cognitive Search.

    • Blobok Azure Blob Storage.

  • Rangsorolja a rendelkezésre állást a konzisztencia alapján. A CAP-tétel azt jelenti, hogy kompromisszumot kell hoznia a rendelkezésre állás és a konzisztencia között egy elosztott rendszerben. 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.

  • Vegye figyelembe 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 képességkészletekre van szükség egy új adattárolási technológia bevezetéséhez. Ahhoz, hogy a lehető legtöbbet hozhassa ki a technológiából, a fejlesztői csapatnak a következőket kell tennie:

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

    • Hangoljon a teljesítményre.

    • A megfelelő használati mintákkal dolgozhat.

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

  • Kompenzáló tranzakciók használata. A poliglot megőrzése esetén egyetlen tranzakció több tárolóba is írhat adatokat. Ha hiba történik, a 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áros környezet egy tartománymodell körüli explicit határ. A kötött 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öbbglobális 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ényeket támaszt a termékek tárolására, frissítésére és lekérdezésére vonatkozóan.

Azure-beli facilitálás

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

  • 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.

  • 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 az MQTT- és HTTP-protokollokat használó rugalmas üzenetfelhasználási mintákat kínál. Az Event Grid használatával adatfolyamatokat hozhat létre eszközadatokkal, eseményvezérelt kiszolgáló nélküli architektúrákat hozhat létre, és integrálhatja az alkalmazásokat.

További információkért lásd:

Példa

Az összetevőket és azok funkcióit a követelmények alapján meghatározó számítási feladatokért lásd: Reliable Web App pattern (Megbízható webalkalmazás-minta).

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

Tekintse meg a javaslatok teljes készletét.

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