castomFLOW
castomFLOW megnyitása

Megbízható futások

Senki nem vesz észre egy automatizálást, amíg nem küld el valamit kétszer

Aztán mindenki észreveszi. Az ezen az oldalon szereplő négy mechanizmus azért létezik, mert az ilyen szoftverek hibái mindig ugyanaz a négy hiba, és mind elkerülhetők tervezéssel, nem pedig gondossággal.

Szimuláljon közzététel előtt

Toljon át egy valódi rekordot egy kikapcsolt munkafolyamaton, és olvassa vissza pontosan, mi történt volna: a megtett utat, minden értéket minden lépésben, minden üzenet megfogalmazását, és azt a kérést, amely minden külső rendszerhez ment volna.

Semmi nem hagyja el az épületet. Nem megy ki e-mail, nem keletkezik számla, nem történik terhelési kísérlet, nem íródik sor. A külső hívások szándékként rögzülnek a küldendő hasznos teherrel együtt, így még azelőtt láthatja, hogy a leképezés helyes-e, mielőtt valakinek problémává válna.

A szimulációkkal válaszolható meg az a kérdés, amely miatt az emberek nem kapcsolnak be egy automatizálást: mit tenne ez valójában?

Szimuláció · 88 214-es rendelésSemmi sem ment el
  • 1Cím ellenőrzéseEgyezett. 6 mezőt írtunk volna.
  • ?Feltétel1 000 zł-t meghaladó rendelés? Nem — 289,00 zł. Rövid útvonal futott.
  • 3SzámlaPOST a számlázó rendszer felé. A teljes hasznos teher látható.
  • !Itt kapta elAz ÁFA-kulcs a rossz mezőből került leképezésre. Szimulációban találtuk meg, nem egy könyvelő postafiókjában.

Elküldve: semmiTerhelve: semmi

Egy futás azon a verzión halad végig, amelyre belépett

Egy munkafolyamat módosításának közzététele nem érinti a már benne lévő futásokat. Minden futás ahhoz a verzióhoz van rögzítve, amelyen elindult, és azt a verziót fejezi be, akármeddig tart és akármit ír át Ön közben.

Így átalakíthat egy munkafolyamatot, miközben tízezer ember éppen félúton jár benne, és mindegyikük befejezi azt a folyamatot, amelyet ígértek neki. A másik megoldás — amikor a teljes lefelé vezető útvonal a belépéskor anyagiasítódik — az oka annak, hogy a legtöbb eszközben veszélyesnek érződik egy élő automatizmus szerkesztése. Itt ez nem különleges.

Az új futások a közzététel pillanatától az új verziót kapják. Az, hogy egy futás melyik verzión áll, rá van írva a futásra, így a márciusi viselkedésre vonatkozó kérdésre szeptemberben is van válasz.

Szerkesztés élőbenv4 → v5
  • 1Előtte2 918 futás folyamatban, mind v4-en. Néhányuk két napos várakozásban.
  • 2v5 közzétételeKét lépés átrendezve, egy üzenet átírva.
  • 3UtánaAzok a 2 918 befejezik a v4-et. Minden, 11:40-től induló futás v5-öt fut.
  • §Senkinem kapta meg az egyik munkafolyamat felét és a másiké felét.

Verzió rögzítve minden futásonRégi verziók megőrizve

Újraküldések, amelyek nem küldhetnek kétszer

Egy lépés a bemeneteinek tiszta függvénye, és hatásai együtt íródnak rögzítésre a futás következő lépésre való előrehaladásával. Nincs olyan ablak, amelyben az üzenet már elment, de a futás nem tud róla.

Ez az egész trükk, és ez szerkezeti tulajdonság, nem ígéret. Egy lépés közepén megszakított munkavégző — telepítés, összeomlás, eltűnő gép — a futást pontosan ott hagyja, ahol volt. Egy másik munkavégző felveszi, és újrafuttatja a lépést. Mivel a hatás és az előrehaladás együtt rögzül, vagy mindkettő megtörtént, vagy egyik sem.

A kimenő hívások azokba a rendszerekbe, amelyek támogatják az idempotencia-kulcsokat, egyet hordanak magukkal, amely a futásból és a lépésből származik, így a másik fél is felismeri az ismétlést.

Munkavégző megszakadt küldés közbenHelyreállítva
  • 15. lépés indulKüldje el a szállítási értesítést.
  • ✕A munkavégző leállTelepítés. Semmi nem rögzült.
  • 2FelveszveEgy másik munkavégző úgy találja, hogy a futás még mindig az 5. lépésen áll.
  • ✓Egyszer elküldveAz ügyfél egy e-mailt kapott, nem kettőt.

A hatások az előrehaladással együtt rögzülnekIdempotencia-kulcs futásonként és lépésenként

Ember által olvashatóra írt napló

Minden futás, minden lépés, a választott elágazás és a döntő érték. Időzítések lépésenként. Minden külső hívás kérése és válasza, a hitelesítő adatok kitakarva. A futás verziója. Hol vár egy futás, és meddig.

Ha valaki rákérdez, mi történt a tizennegyedikén leadott rendeléssel, van válasz, és megtalálása egy percbe telik, nem egy délutánba, három rendszer naplóinak összevetésébe.

A sikertelen futások egy helyen gyűlnek össze, okuk szerint csoportosítva, így a „negyvenegy sikertelen éjszaka” abból lesz, hogy „egy szolgáltató kilenc percen át 503-at adott vissza”, nem pedig negyvenegy külön vizsgálatból.

Éjszaka, csoportosítva41 sikertelen futás
  • 1Egy okA szolgáltató API-ja 503-at adott vissza 02:41 és 02:50 között.
  • 2Mi történtMind a 41 újrapróbálva; 39 második próbálkozásra sikerült.
  • 3MegmaradtKettő leállt, és emberi közreműködésre vár. Mindkettő fel van sorolva a hibás sorral együtt.
  • §Nem negyvenegyvizsgálat. Egy, és egy döntés két rekordról.

Hitelesítési adatok kitakarvaVerzió rögzítve

Amit nem állítunk

Nem teszünk közzé rendelkezésre állási számot marketingoldalon, mert egy mérési időablak és a „működik” definíciója nélküli szám csak díszítés. Ha szerződésben van rá szüksége, kérje, és megbeszéljük, mire tudunk valójában vállalni.

Emellett nem tudjuk megbízhatóvá tenni mások API-ját. Ha egy szolgáltató leáll, az attól függő munkafolyamat vár, újrapróbálkozik, és végül világos indokkal leáll. Amit ígérhetünk: a hiba látható, semmit nem rongál meg, és a folytatás nem küldi el az üzenetet másodszor.

A várakozásról: a két napja várakozó futás egy wake_at a futáson, nem egy sorban ülő feladat. Ezért tud egy munkafolyamat százezer futást tartani háromhetes várakozásban anélkül, hogy bármibe kerülne, és ezért nem kell a jelenleg várakozó futások számán gondolkodnia.

A futás, amelyre sosem gondol, az, amelyik sikerült.