Elkülönített, adott előtérbeli alkalmazások vagy felületek által használt háttérszolgáltatásokat hozhat létre. Ez a minta akkor hasznos, ha el szeretné kerülni, hogy egyetlen háttérkiszolgálót több felülethez is testre kelljen szabnia. A mintát először Sam Newman írta le.
Kontextus és probléma
Egy alkalmazás kezdetben egy asztali webes felhasználói felületet célozhat. Általában ezzel párhuzamosan fejlesztik a háttérszolgáltatást, amely az adott felhasználói felület szolgáltatásait biztosítja. Az alkalmazás felhasználói bázisának növekedésével idővel fejlesztenek egy mobilalkalmazást is, amelynek ugyanazzal a háttérrendszerrel kell együttműködnie. A háttérszolgáltatás általános célú háttérrendszerré válik, amely az asztali és a mobilfelületek igényeit egyaránt kiszolgálja.
A mobileszköz képességei azonban jelentősen eltérnek az asztali böngészőtől a képernyőméret, a teljesítmény és a megjelenítés korlátai tekintetében. Ennek eredményeképpen a mobilalkalmazások háttérrendszereinek követelményei eltérnek az asztali webes felhasználói felületekéitől.
Ezeknek a különbségeknek köszönhetően a háttérkiszolgálóra egymással versengő követelmények vonatkoznak. A háttérrendszert rendszeresen és jelentős mértékben módosítani szükséges, hogy az asztali webes felhasználói felületet és a mobilalkalmazást egyaránt ki tudja szolgálni. Gyakran külön felületfejlesztő csapatok dolgoznak ez egyes előtérrendszereken, így a háttérrendszer szűk keresztmetszetté válik a fejlesztési folyamatban. Az egymással ütköző frissítési követelmények és a szolgáltatás mindkét előtérrendszeren való működőképessége iránti elvárások miatt esetleg rengeteg erőfeszítést kell fektetni egyetlen üzembe helyezhető erőforrásra.
Ahogy a fejlesztés a háttérszolgáltatásra összpontosít, esetleg egy külön csapat alakul a háttérrendszer kezelésére és karbantartására. Ez végül azt eredményezi, hogy megszakad a kapcsolat a felületet és a háttérrendszert fejlesztő csapatok közt, és nő a teher háttérfejlesztő csapaton, hogy megfeleljenek a különböző felületfejlesztő csapatok egymással versengő elvárásainak. Ha valamelyik felületfejlesztő csapat a háttérrendszer módosítását igényli, a változásokat érvényesíttetni kell a többi felületfejlesztő csapattal is, mielőtt integrálhatóak lennének a háttérrendszerbe.
Megoldás
Felhasználói felületenként egy háttérrendszert hozzon létre. Az egyes háttérrendszerek viselkedésének és teljesítményének finomhangolása a legjobban megfelel az előtérbeli környezet igényeinek, anélkül, hogy más előtérbeli élmények befolyásolásával kellene foglalkoznia.
Mivel mindegyik háttérrendszer egy adott felülethez tartozik, optimalizálható is hozzá. Ennek eredményeképpen kisebb, kevésbé összetett és valószínűleg gyorsabb lesz, mint egy olyan általános háttérrendszer lenne, amely az összes felület követelményeinek megpróbál megfelelni. Minden felületfejlesztő csapat autonóm módon meghatározhatja a saját háttérrendszerét, és nem függ a központi háttérrendszer-fejlesztő csapattól. Így a felületfejlesztő csapat rugalmasan határozhatja meg a nyelvválasztást, a kiadási ütemezést, a számítási feladatok prioritását és a háttérrendszerbe integrált szolgáltatásokat.
További információkért lásd: Minta: Háttérrendszerek és előtérrendszerek.
Problémák és megfontolandó szempontok
- Vegye számba, hogy hány háttérrendszert kell telepíteni.
- Ha a különböző felületek (például a mobilügyfelek) azonos kéréseket adnak majd le, fontolja meg, hogy valóban érdemes-e külön háttérrendszert kialakítani minden egyes felülethez, vagy esetleg elegendő egyetlen háttérrendszer.
- Ennek a mintának az implementálásakor nagyon valószínű, hogy a kód duplikálva lesz az egyes szolgáltatásokban.
- Az egyes előterekre irányuló háttérrendszereknek csak ügyfélspecifikus logikát és működést szabad tartalmaznia. Az általános üzleti logikát és az egyéb globális szolgáltatásokat az alkalmazás valamely más részében kell kezelni.
- Gondolja végig, hogy ennek a mintának az alkalmazása miként módosítja a felelősségi köröket a fejlesztői csapatban.
- Vegye számításba, hogy mennyi ideig tart megvalósítani a mintát. Okoznak majd az új háttérrendszerek kialakításába fektetett erőfeszítések műszaki adósságot, miközben továbbra is támogatja a meglévő általános háttérrendszert?
Mikor érdemes ezt a mintát használni?
Használja ezt a mintát, ha:
- Egy megosztott vagy általános célú háttérszolgáltatást kell fenntartani jelentős fejlesztési többletterhelés mellett.
- A háttérrendszert a specifikus ügyfélfelületek követelményeihez szeretné optimalizálni.
- Az általános célú háttérrendszer testreszabásával több felületet szeretne kiszolgálni.
- A programozási nyelv jobban megfelel egy adott felhasználói felület háttérrendszerének, de nem minden felhasználói felületnek.
Nem érdemes ezt a mintát használni, ha:
- Ha a felületek ugyanazokat vagy hasonló kéréseket intéznek a háttérrendszerhez.
- Ha csak egyetlen felület kommunikál a háttérrendszerrel.
Számítási feladatok tervezése
Az tervezőknek értékelniük kell, hogyan használhatók a háttérrendszer mintája a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:
| Pillér | Hogyan támogatja ez a minta a pillércélokat? |
|---|---|
| A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön. | Ha egy adott előtér-felületre kizárólagos külön szolgáltatások tartoznak, hibásan működik, így előfordulhat, hogy az egyik ügyfél rendelkezésre állása nem befolyásolja egy másik ügyfél hozzáférésének elérhetőségét. Emellett a különböző ügyfelek eltérő kezelése esetén a megbízhatósági erőfeszítéseket a várt ügyfélhozzáférési minták alapján rangsorolhatja. - RE:02 Kritikus folyamatok - RE:07 Önmegőrzés |
| A biztonsági tervezési döntések segítenek biztosítani a számítási feladatok adatainak és rendszereinek titkosságát, integritását és rendelkezésre állását. | Az ebben a mintában bevezetett szolgáltatáselválasztás miatt az egy ügyfelet támogató szolgáltatási réteg biztonsága és engedélyezése az ügyfél által igényelt funkciókhoz igazítható, ami csökkentheti az API felületét és az oldalirányú mozgást a különböző háttérrendszerek között, amelyek különböző képességeket tehetnek elérhetővé. - Standard kiadás:04 Szegmentálás - Standard kiadás:08 Erőforrások keményítése |
| A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését . | A háttérbeli elkülönítés lehetővé teszi, hogy olyan módon optimalizáljon, amely megosztott szolgáltatási réteggel esetleg nem lehetséges. Ha másként kezeli az egyes ügyfeleket, optimalizálhatja a teljesítményt egy adott ügyfél korlátaihoz és funkcióihoz. - PE:02 Kapacitástervezés - PE:09 Kritikus folyamatok |
Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.