Paskirstytų sistemų plėtra sparčiai auga, nes programinės įrangos kūrėjai kuria sistemas, kurios turi atitikti vis didėjančius elektroninio verslo reikalavimus. Bet dar niekada pranešimų apdorojimo sluoksnio projektavimas ir įgyvendinimas paskirstytoje sistemoje nebuvo toks sudėtingas kaip šiandien. Tai daugiausia lemia tai, kad labai išaugo potencialus funkcionalumas, kurį įgalino tokie standartai kaip „Java Message Service“ (JMS), kurie sujungia daugelio tiekėjų technologijas vienoje sistemoje. Be to, dėl interneto plitimo atsirado naujų, plačių vartotojų bazių, o komunikacijai paskirstytoje sistemoje buvo prieinami keli protokolai. Tokie protokolai yra CORBA IIOP (interneto tarp ORB protokolas), „Microsoft DCOM“ (paskirstyto komponento objekto modelis) ir „Java RMI“ (nuotolinio metodo iškvietimas).
Natūrali šių protokolų evoliucija paskatino įvesti į pranešimą orientuotą tarpinę programinę įrangą (MOM), leidžiančią laisvesnį ryšį paskirstytose sistemose abstrahuojant vertimą, saugumą ir pagrindinius ryšių protokolus iš klientų ir serverių. Tarpinės programinės įrangos sprendimai apima SOAP (paprastą prieigos prie objekto protokolą) ir JMS. Nuosavybė, vidutinio lygio operacijų apdorojimas egzistuoja nuo pat COBOL (bendros į verslą orientuotos kalbos) laikų, tačiau tai nebuvo labai sudėtinga dėl ankstyvųjų pranešimų siuntimo technologijų apribojimų.
Atsiradus tokiems standartams kaip JMS, kūrėjai dabar gali prijungti daugybę technologijų. Paskirstytos sistemos projektavimo sprendimai yra sunkesni, o jų įtaka duomenų vientisumui ir paskirstymui yra labai svarbi sistemos sėkmei ar gedimui.
Visuotinė ir tyli prielaida yra ta, kad technologijų diegimas yra turtas, o jų įsipareigojimai dažnai ignoruojami. Neapskaitinėjant įsipareigojimų, sistema dažnai yra be reikalo sudėtinga ir (arba) per didelė. Pagrindinis JMS ir jai būdingų savybių (nuo sistemos nepriklausančių savybių) supratimas, po kurio atliekama kruopšti analizė, atsižvelgiant į konkrečius paskirstytos sistemos scenarijus, gali parodyti, kaip JMS gali išspręsti sistemos reikalavimus, palyginti su esamų problemų pakeitimu ar net naujų įdiegimu.
JMS apžvalga
JMS, kurią „Sun Microsystems“ pristatė 1999 m. Kaip „Java 2 Platform, Enterprise Edition“ (J2EE) specifikacijos dalį, yra standartų rinkinys, apibūdinantis pranešimų apdorojimo tarpinės programinės įrangos pagrindo pagrindus. JMS leidžia sistemoms bendrauti sinchroniškai arba asinchroniškai tiek naudojant taško į tašką, tiek skelbiant ir prenumeruojant modelius. Šiandien keli pardavėjai teikia JMS diegimą, pvz., „BEA Systems“, „Hewlett-Packard“, IBM, „Macromedia“ ir „Oracle“, taip leisdami JMS sąveikauti su daugeliu tiekėjų technologijų.
1 paveiksle parodyta paprasta JMS pagrįsta sistema su išeinančia eile, užpildyta pranešimais, kuriuos klientai turi apdoroti, ir įeinančia eile, kuri renka kliento apdorojimo rezultatus įterpimui į duomenų bazę.
Kaip minėta pirmiau, MOM (kaip ir JMS) leidžia laisvesnį sujungimą paskirstytose sistemose, iš klientų ir serverių abstrahuojant vertimą, saugumą ir pagrindinius ryšių protokolus. Vienas iš pagrindinių pranešimų apdorojimo sluoksnio turtų yra tas, kad įvedus šį abstrakcijos sluoksnį, kliento arba serverio įgyvendinimas gali pasikeisti, kartais radikaliai, nepaveikdamas kitų sistemos komponentų.
Du konkretūs scenarijai
Šiame skyriuje pristatau dvi paskirstytas sistemas, kurios yra potencialios JMS kandidatės, ir paaiškinu kiekvienos sistemos tikslus ir kodėl sistemos yra JMS kandidatės.
1 scenarijus
Pirmasis kandidatas yra paskirstytoji kodavimo sistema (parodyta 2 paveiksle). Ši sistema turi rinkinį N klientai, kurie gauna kodavimo užduotis iš centrinio duomenų bazės serverio. Tada klientai vykdo faktinį transformavimą (kodavimą) iš skaitmeninio pagrindinio į koduotus failus ir baigia pranešdami apie savo po apdorojimo būseną (pvz., Sėkmė / nesėkmė) atgal į centrinę duomenų bazės serverį.
Kodavimo (pvz., Teksto, garso ar vaizdo) ar transformacijų (pvz., .pdf į .xml, .wav į .mp3, .avi į .qt) Nesvarbu. Svarbu suprasti, kad kodavimas reikalauja daug procesoriaus ir norint jį išplėsti, reikia paskirstyto apdorojimo keliems klientams.
Iš pirmo žvilgsnio ši sistema yra potenciali JMS kandidatė, nes:
- Apdorojimas turi būti paskirstytas, nes jis reikalauja daug procesoriaus (procesoriaus)
- Sistemos našumo požiūriu gali būti problematiška kelis klientus tiesiogiai prijungti prie vieno duomenų bazės serverio
2 scenarijus
Antroji JMS kandidatų sistema yra pasaulinė interneto portalo registracijos sistema. Visuotinė registracija tvarko naujo vartotojo kūrimo (registracijos), prisijungimo ir autentifikavimo užklausas.
Specifinė registracijos informacija (pvz., Vardas, adresas, mėgstamiausia spalva) ir vartotojo autentifikavimo metodai (pvz., Serverio vartotojo objektai, HTTP slapukai) yra nesvarbūs. Tačiau svarbu, kad ši sistemos skalė valdytų milijonus vartotojų, o naudojimo įpročius sunku, o gal ir neįmanoma nuspėti. (Per televizijos ESPN pasaulio taurės žaidimą diktorius sako: "Prisijunkite ir balsuokite mūsų internetinėje apklausoje. Rezultatus pristatysime laidos pabaigoje." Staiga 500 000 vartotojų prisijungia per tris minutes intervalas. 3 minutės = 180 sekundžių; 500 000 vartotojo prisijungimų / 180 sekundžių = 2 778 vartotojo prisijungimai / sek.)
Ši sistema yra potenciali JMS kandidatė dėl šių priežasčių:
- Sistema turi būti paskirstyta, kad būtų galima apskaičiuoti operacijų apimtį
- Sandoriai yra atominiai (pvz., Prisijungimas), todėl jie yra be pilietybės ir todėl gali būti platinami
Abi sistemos yra architektūriškai panašios. Keletas klientų mašinų išgauna duomenis iš centrinio duomenų bazės serverio (galbūt nukopijuojami į M tik skaitymo duomenų bazės serveriai), vykdykite kliento logiką ir tada praneškite apie būseną centriniam duomenų bazės serveriui. Viena sistema perduoda užkoduotus failus į failų sistemą per UNC / FTP; kitas pateikia HTML turinį žiniatinklio naršyklėms per HTTP. Abi sistemos yra paskirstytos.
Tai yra tiek, kiek daugelis inžinierių atlieka savo analizes prieš taikydami JMS. Likusioje šio straipsnio dalyje aš paaiškinu, kad nors šioms sistemoms būdinga daugybė savybių, JMS tinkamumas tampa aiškesnis ir labiau skiriasi, kai nagrinėjame kiekvienos sistemos reikalavimus, įskaitant sistemos našumą, duomenų paskirstymą ir mastelį.
Sistemos analizė: integruoti ar neintegruoti
JMS turi būdingų, nuo sistemos nepriklausančių savybių. Kai kurios iš šių savybių (pliusai, pažymėti +, trūkumai, žymimi -), kurie taikomi abiem sistemoms, yra šie:
- (+) JMS yra standartų rinkinys, sukurtas kelių tiekėjų diegimų; todėl vengiate baimės pardavėjo užraktas problema.
- (+) JMS leidžia abstrahuoti (per bendrą API) tarp kliento ir serverio; galite pakeisti duomenų bazės schemą ar platformą nekeisdami programos sluoksnio (numanomi čia yra kiti galimi sistemos pakeitimai, atskirti vienas nuo kito pranešimų sluoksniu).
- (+)/(-) JMS gali padėti sistemos mastui (pro). Neteisinga yra tai, kad bet kuri sistema, kuri keičia mastelį su JMS, gali be jos keisti mastelį.
- (-) JMS yra sudėtinga. Tai visiškai naujas sluoksnis su nauju serverių rinkiniu. Programinės įrangos išleidimo valdymas, serverio stebėjimas ir sauga yra tik kelios nereikšmingos problemos, susijusios su JMS išleidimu. Taip pat reikėtų atsižvelgti į išlaidas.
- (-) Pardavėjai ne visada aiškina ir todėl įgyvendina standartus tiksliai tuo pačiu būdu, todėl egzistuoja skirtingi įgyvendinimai.
- (-) Naudojant JMS reikia daugiau sistemos patikrinimų ir balansų. Jūs įvedate ne tik naują sluoksnį, bet ir asinchroninį duomenų paskirstymą bei patvirtinimą, kuris turi papildomą asinchroninio pranešimo sudėtingumą.
- (-) Nėra pranešimų pranešimo / atnaujinimo / stebėjimo eilių be pasirinktinės programinės įrangos.
JMS taip pat turi nuo sistemos priklausančių savybių. JMS tinkamumas priklauso nuo to, kaip gerai šios savybės atitinka problemą, kurią bandote išspręsti. Kai kurios iš šių savybių ir kaip jos susijusios su dviem dominančiomis sistemomis:
Talpykla
Talpyklos talpinimas yra pagrindinis dėmesys planuojant pajėgumus bet kurioje paskirstytoje sistemoje. JMS turi daug funkcijų, leidžiančių jį naudoti kaip talpyklos technologiją (daugiausia tai, kad jis yra paskirstytas, sinchroninis ar asinchroninis, o duomenimis keičiamasi kaip objektais pranešimuose). Todėl esamas JMS diegimas gali būti naudojamas kaip talpyklos infrastruktūra, jei to reikia.
Svarstant kodavimo sistemą, talpyklos talpinimas paprastai nėra naudingas siekiant padidinti bendrą sistemos našumą, nes dauguma failų transformacijų vykdomos vieną kartą ir persikelia į prieglobos įrenginį arba SAN (saugyklos srities tinklą), ir yra mažai turinio sutapimas tarp klientų. Visuotinė registracija yra pagrindinis kandidatas į informacijos apie vartotoją talpyklą, nes vartotojai paprastai prisijungia, naršo ir tada atsijungia. Prisijungus sukuriamas vartotojo talpyklos įrašas, o šis objektas suteikia vėlesnį vartotojo autentifikavimą, kol vartotojas yra svetainėje.
Apdorojame užsakyma
Pasaulinėje registracijos sistemoje nėra planavimo ir (arba) užsakymo operacijų apdorojimui. Pseudoatsitiktiniai vartotojai prisijungdami prisijungia prie sistemos pseudoatsitiktiniais intervalais, naršo turinį (todėl yra patvirtinami, kai prieina prie riboto turinio ir (arba) programų) ir tada atsijungia.
Kodavimo sistemoje užsakomas apdorojimas. Turinys siunčiamas į grupes, atsižvelgiant į galimą išimamą saugyklą (pvz., DLT sprendimai arba „Network Appliance“ saugykla). Turinys nepateikiamas, kol partija bus baigta, todėl paketai turi būti vykdomi tvarka (nors transformacijos pakete gali būti neužsakytos). JMS gali būti įgyvendinamos prioritetinės eilės, kad būtų išsaugota apdorojimo tvarka, tačiau išlaikyti tokią pranešimų paketų tvarką tarp kelių JMS serverių ir kelių eilių tampa gana sudėtinga. Reliacinis duomenų bazės serveris, palaikantis operacijas, yra tinkamesnė technologija šiai darbo eigai valdyti.
Saugumas
Saugumas nėra JMS specifikacijos dalis. Saugos problema nebūtinai keičiama įgyvendinant JMS pagrįstą diegimą (jei prieš JMS turite saugos reikalavimų, panašius saugos reikalavimus turėsite ir po JMS). Tai žinant svarbu suprasti, kaip JMS gali būti susijęs su esamu infrastruktūros saugumu.
Apskritai, kuo daugiau technologijų naudosite, tuo jūsų sistema bus labiau pažeidžiama įsilaužėlių ir saugumo pažeidimų atžvilgiu. Kadangi pasaulinis registracijos programų serveris yra nukreiptas į internetą, saugos trūkumai, aptikti jūsų tiekėjų JMS diegime ir paskelbti interneto naujienų grupėse, greitai tampa jūsų svetainės saugumo įsipareigojimais. Be to, kadangi JMS yra bendroji API, ji labiau linkusi į saugumo pažeidimus nei nuosavybės sistema, naudojanti neskelbtą API.
Nors galite panaudoti esamą užkardą ir IP pagrįstą tinklo saugumą, kad apsaugotumėte savo išorines (skaitykite: ne žiniatinklyje esančias - skirtas žodžiams) programų ir duomenų bazių serverius nuo saugos pažeidimų, atskleidus JMS programų serverius, kyla didelė saugos rizika. tiesiogiai į internetą.
Kodavimo sistema paprastai egzistuoja tame pačiame tinkle (taip pat tinkle, izoliuotame nuo interneto). Taigi, šios sistemos tinklo topografijoje nėra nieko, kas susiję su JMS ir šios topografijos pritaikymu saugumui užtikrinti (kodavimo sistemai yra daug mažiau saugumo reikalavimų, nes ji nėra nukreipta į internetą).
Mastelis
Kadangi pasaulinė registracijos sistema priklauso nuo gausios ir kaprizingai spustelėjusios vartotojų bazės užgaidų, sistemos mastelio reikalavimai reikalauja JMS. JMS padės ne tik sumažinti sistemos mastą, bet ir sudaryti eilės operacijas, nors tai nebus labai naudinga, kai vartotojo užklausos užlieja sistemą.
Kadangi paskirstyta kodavimo sistema kruopščiai reguliuoja duomenų srautą (nes tai tikriausiai yra savarankiška sistema), sistemos mastelio reikalavimai nėra tokie baisūs. Norėdami naudoti paskirstytą kodavimą, galite prijungti savo O [100] klientus tiesiai į jūsų duomenų bazę ir apribokite jų srautą, kad subalansuotumėte kodavimo našumą ir duomenų bazės serverio našumą.
Spektaklis
Vieno JMS serverio įvedimas gali pakeisti veikimo problemas, o ne jas išspręsti. Dėl šios priežasties JMS sistema turėtų būti suprojektuota su keliais JMS serveriais (taigi ir keliomis eilėmis). 4 paveiksle parodyta, kodėl našumo problemos keičiamos, o ne sprendžiamos. Tai iliustruoja apdorojimo sluoksnius, reikalingus bendram duomenų serveriui atsakyti į kliento prisijungimo užklausas:
Duomenų mainai tarp kliento ir serverio yra dviejų dalių procesas, nesvarbu, ar tai klientas-duomenų bazė, ar klientas-JMS serveris:
- Prieiga prie duomenų
- Gijų ir lizdų valdymas, telkimas ir talpinimas
JMS ir duomenų bazės serveris atrodo visiškai vienodi (4 pav.). Jie tvarko lizdo jungtis, gijų valdymą ir prieigą prie serverio duomenų.
Turint tik vieną JMS serverį, galimos našumo problemos tiesiog keliauja iš duomenų bazės serverio į JMS serverį. Be galimo naikinimo, susijusio su konteksto keitimu jūsų duomenų bazės serveryje, našumo problemos dabar gali būti didesnės dėl JVM našumo problemų jūsų JMS serveryje.
Vienas JMS serveris padidina jūsų sistemos sudėtingumą ir gali sukelti našumo problemų, susijusių su kelių klientų prijungimu prie vieno serverio. Kelių JMS serverių įtaka jūsų sistemos dizainui ir duomenų srautui gali reikšti skirtumą tarp sėkmingo ar nepavykusio sistemos išleidimo.
Apibendrinant, funkcijos ir galimas JMS poveikis atrodo taip:
Funkcijos, palyginti su JMS poveikiu
