A skálázhatóság érdekében minimalizálja a koordinációt az alkalmazásszolgáltatások között.
A legtöbb felhőalapú alkalmazás több alkalmazásszolgáltatásból áll – webes kezelőfelületekből, adatbázisokból, üzleti folyamatokból, jelentéskészítésből és elemzésből stb. A skálázhatóság és megbízhatóság biztosításához mindegyik szolgáltatásnak több példányon kell futnia.
Mi történik, ha két példány néhány megosztott állapotot érintő egyidejű műveletet próbál végrehajtani? Ilyen esetekben koordináció szükséges a csomópontok között, például az ACID megvalósulásának fenntartása érdekében. Ezen az ábrán látható, hogy a Node2 a Node1 csomópontra vár, hogy az feloldja az adatbázis-zárolást:
A koordináció korlátozza a horizontális skálázás előnyeit, és szűk keresztmetszetet hoz létre. Ebben a példában az alkalmazás horizontális felskálázása és további példányok hozzáadása közben megnövekedett zárolási versenyt fog tapasztalni. A legrosszabb esetben az előtérbeli példányok a legtöbb idejüket a zárolásra várva fogják tölteni.
A „pontosan egyszer” szemantika a koordináció egy másik gyakori forrása. Egy megrendelést például pontosan egyszer szabad feldolgozni. Két feldolgozó új megrendelésekre vár. A Worker1 felveszi a feldolgozási kérést. Az alkalmazásnak biztosítania kell, hogy a Worker2 nem ismétli meg a munkát, de ha a Worker1 összeomlik, a megrendelést nem dobja el a rendszer.
A feldolgozók közötti koordinációhoz olyan mintákat is használhat, mint például a Feladatütemező ügynök felügyeleti mintája, de ebben az esetben a munka particionálása jobb módszer lehet. Minden egyes feldolgozóhoz megrendelések bizonyos tartománya van hozzárendelve (például számlázási régiónként). Ha egy feldolgozó összeomlik, egy új példány ott folytatja a feladatot, ahol az előző abbahagyta, de a példányok nem versenyeznek egymással.
Javaslatok
Végső konzisztencia támogatása. Az adatok elosztásakor koordinációra van szükség az erős konzisztencia megvalósulásának kikényszerítésére. Tegyük fel például, hogy egy művelet két adatbázist frissít. Ahelyett, hogy egy tranzakciós hatókörbe helyezné, jobb, ha a rendszer képes végső konzisztenciát használni, például a Kompenzáló tranzakció minta használatával, a hiba utáni logikai visszavonáshoz.
Tartományi események használata az állapot szinkronizálásához. A tartományi esemény egy olyan esemény, amely rögzíti, ha valami fontos történik a tartományban. Az érintett szolgáltatások figyelhetik az eseményt ahelyett, hogy globális tranzakciót használnának az erőforrások közötti koordinációhoz. Ennek a módszernek a használatakor a rendszernek tolerálnia kell a végső konzisztenciát (lásd az előző elemet).
Fontolja meg a CQRS, az Események forráskezelése és hasonló minták használatát. Ez a két minta segíthet a versengés csökkentésében az olvasási és az írási számítási feladatok között.
A CQRS minta elkülöníti az olvasási műveleteket az írási műveletektől. Néhány megvalósítás esetében az adatok olvasása fizikailag is el van különítve az adatok írásától.
Az Események forráskezelése mintában az állapotmódosításokat eseménysorozatként rögzíti a rendszer egy csak hozzáfűzéssel bővíthető adattárban. Egy esemény hozzáfőzése a streamhez atomi művelet, amelyhez minimális zárolásra van szükség.
Ez a két minta kiegészíti egymást. Ha a CQRS-ben található, csak írási engedéllyel rendelkező adattár az Események forráskezelése mintát használja, a csak olvasható adattár figyelheti ugyanazokat az eseményeket egy lekérdezésekhez optimalizált, az aktuális állapotot tartalmazó, olvasható pillanatkép létrehozásához. A CQRS vagy az Események forráskezelése minta alkalmazása előtt vegye figyelembe a módszer kihívást jelentő jellemzőit.
Adatok particionálása. Ne helyezze minden adatát egyetlen, számos alkalmazásszolgáltatás között megosztott adatsémába. A mikroszolgáltatási architektúra úgy kényszeríti ki ezt az alapelvet, hogy minden szolgáltatást a saját adattáráért tesz felelőssé. Egy önálló adatbázison belül az adatok szilánkokba történő particionálása javíthatja az egyidejűséget, mivel az egyik adatszilánkba író szolgáltatás nem befolyásolja a másik adatszilánkba író szolgáltatást.
Tervezzen idempotens műveleteket. Amikor lehetséges, az alkalmazásokat úgy tervezze meg, hogy idempotensek legyenek. Így azok legalább egy szemantikával kezelhetők. Például üzenetsorba helyezheti a munkaelemeket. Ha egy feldolgozó a művelet közepén összeomlik, egy másik feldolgozó egyszerűen folytatja a munkaelemet. Ha a feldolgozónak frissítenie kell az adatokat, és más üzeneteket is ki kell küldenie a logikája részeként, akkor az idempotens üzenetfeldolgozási mintát kell használni.
Használjon optimista egyidejűséget, ha lehetséges. A pesszimista egyidejűség-vezérlés adatbázis-zárolást használ az ütközések megelőzése érdekében. Ez gyenge teljesítményt okozhat és csökkentheti a rendelkezésre állást. Az optimista egyidejűség-vezérléssel minden tranzakció az adat egy pillanatfelvételének másolatát módosítja. A tranzakció véglegesítése után az adatbázismotor érvényesíti a tranzakciót, és visszautasítja az adatbázis konzisztenciáját befolyásoló tranzakciókat.
Az Azure SQL Database és SQL Server pillanatkép-elkülönítéssel támogatja az optimista egyidejűséget. Bizonyos Azure Storage-szolgáltatások (például az Azure Cosmos DB és az Azure Storage) az ETagek használatán keresztül támogatják az optimista egyidejűséget.
Fontolja meg a MapReduce vagy egyéb párhuzamos, elosztott algoritmus használatát. Az adatoktól és az elvégzendő munka típusától függően feloszthatja a munkát független feladatokra, amelyeket párhuzamosan működő csomópontok végezhetnek el. Lásd: Big Compute architektúrastílus.
Használja a vezetőválasztást a koordinációhoz. Olyan esetben, ahol műveleteket kell koordinálnia, győződjön meg arról, hogy a koordinátor ne váljon kritikus meghibásodási ponttá az alkalmazásban. A Vezetőválasztási minta használatával egy példány bármikor vezető lehet, és koordinátorként működhet. Ha a vezető összeomlik, a rendszer egy új példányt választ vezetőnek.