Orleans architektúratervezési alapelvek

Orleans nyílt forráskódú projekt, és fontos tisztázni a célokat és alapelveket. Ezek a célok és alapelvek motiválták a mögöttük lévő Orleans tervezési döntéseket, hogy az új változások vagy beleférjenek ebbe a keretbe, vagy explicit módon és szándékosan felülvizsgálják ezeket a célokat és alapelveket.

A projekt célja Orleans egy olyan keretrendszer létrehozása volt, amely lehetővé teszi a fő fejlesztők számára, hogy könnyen skálázható elosztott (felhőbeli) alkalmazásokat építsenek. Ezt egy kicsit részletesebben megvizsgálva:

• A célközönség nem zárhatja ki azokat a programozókat, akik nem végeztek elosztott rendszerfejlesztést. Lehetővé szeretnénk tenni, hogy minden fejlesztő, akár felhőszakértő, akár kezdő felhőbeli, az alkalmazáslogikára és -funkciókra összpontosítson – vagyis az üzleti értéket biztosító funkciókra –, ne pedig az általános elosztott rendszerek problémáira.

• A cél az, hogy a fő fejlesztők könnyen építhessenek felhőalkalmazásokat. Egyszerűen azt jelenti, hogy nem kell a szükségesnél többet gondolniuk az elosztásra. Az egyszerűség azt is jelenti, hogy Orleans a lehető legszokottabb homlokzatot kell bemutatnia a fejlesztőnek; .NET-környezetben ez C# objektumokat és interfészeket jelent.

• Ezeknek az alkalmazásoknak alapértelmezés szerint méretezhetőnek kell lenniük. Mivel a célfelhasználók nem feltétlenül elosztott rendszerszakértők, olyan keretrendszert szeretnénk biztosítani számukra, amely skálázható alkalmazások létrehozásához vezet anélkül, hogy kifejezetten gondolna rá. Ez azt jelenti, hogy a keretrendszernek sok döntést kell hoznia, hogy elfogadható szintű méretezhetőséget garantáljon, még akkor is, ha ez azt jelenti, hogy a méretezhetőség nem optimális minden alkalmazáshoz.

Ezt a célt az architektúra alapelveinek halmazával egészítettük ki:

• A 80% ügyre koncentrálunk. Vannak olyan alkalmazások, amelyek Orleans nem megfelelőek; ez rendben van. Vannak olyan alkalmazások, amelyek Orleans megfelelőek, de ahol valamivel jobb teljesítményt érhet el egy csomó olyan kézi finomhangolással, amely Orleans nem teszi lehetővé; ez is rendben van. A 80%, hogy Orleans jól illeszkedik és elég jól teljesít, sok érdekes alkalmazást lefed, és inkább végeznénk nagyszerű munkát 80%-en, mint pocsék munkát 99%-en.

• A méretezhetőség a legfontosabb. Ha ez jobb skálázást ad nekünk, a nyers teljesítményt is le kell cserélnünk.

• A rendelkezésre állás a legfontosabb. A felhőalkalmazásnak olyannak kell lennie, mint egy segédprogram: mindig ott kell lennie, amikor szeretné.

• Észlelheti és kijavíthatja a problémákat, ne feltételezze, hogy 100% előzheti meg őket. Felhőbeli méretekben a rossz dolgok gyakran történnek, és még a lehetetlen rossz dolgok is előfordulnak, csak ritkábban. Ez vezetett minket a gyakran "helyreállítási orientált számítástechnikának" is nevezhető számítástechnikához, ahelyett, hogy hibatűrőnek próbálnánk lenni. A tapasztalatok azt mutatják, hogy a hibatűrés törékeny és gyakran illuzórikus. Még a matematikailag bizonyított protokollok sem védenek a memória vagy a lemezvezérlők véletlenszerű bitfordításai ellen, amelyek sikeres jelentéskészítés közben meghiúsulnak – mindkét példa a való világban történt.

Az előző alapelvek bizonyos gyakorlatokhoz vezettek:

• API-első kialakítás: ha nem tudjuk, hogyan fogjuk elérhetővé tenni a funkciót a fejlesztőnek, akkor nem építjük fel. Természetesen a legjobb módszer az, ha egy funkció egyáltalán nem rendelkezik fejlesztői expozícióval.

• Tegye egyszerűvé a helyes dolgot: tartsa a dolgokat a lehető legegyszerűbben (de mégse egyszerűbb); ne adjon kalapácsot, ha a csavarhúzó a megfelelő eszköz. Ahogy egyik korai alkalmazónk fogalmazott, megpróbáljuk segíteni ügyfeleinket abban, hogy "a siker gödrébe essenek". Ha van egy szabványos minta, amely jól működik 80% az alkalmazások odakint, akkor ne aggódjon, hogy lehetővé teszi minden lehetséges alternatívát. Orleans' aszinkron elfogadása egy jó példa erre.

• A fejlesztők egyszerűen bővíthetik a keretrendszert anélkül, hogy feltörik. Erre néhány példa az egyéni szerializálási és adatmegőrzési szolgáltatók. Egy egyéni feladatütemezési bővítmény ellenpélda lenne.

• Kövesse a legkisebb meglepetés elvét: amennyire csak lehetséges, a dolgoknak ismerősnek kell lenniük, de mindennek úgy kell viselkednie, ahogy néz ki.