Arsitektur telung tingkat

Pambuka kanggo arsitektur telung tingkat

Arsitektur telung tingkat minangka arsitektur interaksi sing paling umum ing Internet. Katon nalika bagean server rong tingkat dipérang dadi rong bagéan: lapisan logika lan lapisan data .

Iku katon kaya iki:

Lapisan klien minangka bagean saka "aplikasi sing disebarake" sing tanggung jawab kanggo interaksi pangguna. Lapisan iki ngirim ora ngemot logika bisnis lan ngirim ora nyimpen data kritis. Uga, ora kudu sesambungan karo lapisan database langsung, nanging mung liwat lapisan logika bisnis.

Nanging, isih ana sawetara logika ing kene. Kaping pisanan, iki interaksi karo pangguna liwat antarmuka, validasi data sing dilebokake dening dheweke, nggarap file lokal. Iki uga kalebu kabeh sing ana gandhengane karo wewenang pangguna lan enkripsi data nalika nggarap server.

Kapindho, iku logika bisnis sing prasaja. Contone, yen toko online ngirim dhaptar produk, kita bisa ngurutake lan nyaring ing sisih klien. Lan panyimpenan data primitif uga ana ing kene: caching, cookie pangguna sing mlebu, lan liya-liyane.

Lapisan logika bisnis dumunung ing tingkat kapindho, sebagian besar logika bisnis dikonsentrasi. Ing njaba, mung fragmen sing diekspor menyang klien, uga unsur logika sing dicelupake ing basis data (prosedur lan pemicu sing disimpen).

Sebagean banget saka server logika bisnis ora mung ngemot logika sing padha, nanging uga ngatasi masalah skala: kode kasebut dibagi dadi bagean lan disebarake menyang server sing beda. Sawetara layanan sing dituntut banget bisa mlaku ing puluhan server. Beban ing antarane diatur dening load balancer.

Aplikasi server biasane dirancang kanthi cara supaya salinan server liyane bisa diluncurake kanthi gampang lan miwiti kerja sama karo salinan liyane. Tegese, sanajan ing proses nulis kode server, sampeyan ora bakal duwe jaminan yen kelas statis diluncurake ing siji conto.

Lapisan data nyedhiyakake panyimpenan data lan diselehake ing tingkat sing kapisah, dileksanakake, minangka aturan, kanthi sistem manajemen basis data (DBMS), sambungan menyang komponen iki mung kasedhiya saka tingkat server aplikasi.

Alasan kanggo misahake lapisan data

Pemisahan lapisan data dadi lapisan katelu sing lengkap dumadi amarga akeh alasan, nanging sing utama yaiku beban sing tambah ing server.

Kaping pisanan, database wiwit mbutuhake akeh memori lan wektu prosesor kanggo pangolahan data. Mulane, dheweke wiwit diselehake ing endi wae ing server sing kapisah.

Kanthi beban tambah, backend bisa gampang diduplikasi lan sepuluh salinan siji server bisa diunggahake, nanging ora bisa duplikat database - database isih tetep dadi komponen siji lan ora bisa dipisahake saka sistem kasebut.

Kapindho, database wis dadi pinter - padha duwe logika bisnis dhewe. Dheweke wiwit ndhukung prosedur sing disimpen, pemicu, basa dhewe kayata PLSQL. Lan malah muncul programer sing wiwit nulis kode sing mlaku ing DBMS.

Kabeh logika sing ora ana hubungane karo data dijupuk menyang backend lan diluncurake kanthi paralel ing puluhan server. Kabeh sing ana hubungane karo data tetep ana ing DBMS, lan masalah beban tambah kudu ditanggulangi kanthi nggunakake metode kita dhewe:

• Kluster basis data minangka klompok server basis data sing nyimpen data sing padha lan nyinkronake nggunakake protokol tartamtu.
• Sharding - data dipérang dadi blok logis lan disebarake ing macem-macem server database. Iku angel banget kanggo njaga owah-owahan database karo pendekatan iki.
• Pendekatan NoSQL yaiku kanggo nyimpen data ing basis data sing dibangun kanggo nyimpen data sing akeh banget. Iki asring ora malah database, nanging panyimpenan file tartamtu. Fungsionalitas sing kurang apik dibandhingake karo database relasional.
• Caching data. Tinimbang cache prasaja ing tingkat basis data, kabeh DBMS caching katon, sing mung nyimpen asil ing memori.

Cetha yen wong sing kapisah lan / utawa kabeh tim dibutuhake kanggo ngatur zoo teknologi server iki, sing nyebabake mbusak lapisan data dadi lapisan sing kapisah.

Penting! Kabeh teknologi canggih lair ing jero perusahaan IT gedhe, nalika pendekatan lawas ora bisa ngatasi tantangan anyar. Nggawe database menyang lapisan kapisah ora nemokke dening programmer sembarang, nanging dening klompok engineers nang endi wae ing ambane Oracle utawa IBM.

menarik! Nalika Zuckerberg miwiti nulis Facebook, dheweke kerja mung ing PHP + MySQL. Nalika ana mayuta-yuta pangguna, dheweke nulis penerjemah khusus sing nerjemahake kabeh kode PHP menyang C ++ lan dikompilasi dadi kode mesin asli.

Uga, MySQL ora bisa nyimpen data milyaran pangguna, mula Facebook ngembangake konsep database NoSQL lan nulis DBMS NoSQL sisi server sing kuat - Cassandra. Miturut cara, iku rampung ditulis ing Jawa.

Ambiguitas lokasi logika aplikasi

Lan senadyan arsitektur telung-undakan meh unambiguously distributes peran antarane bagean sawijining, iku ora tansah bisa kanggo bener nemtokake persis ngendi ing sistem bagean anyar saka logika bisnis (kode anyar) kudu ditambahake.

Conto ambiguitas kasebut ditampilake ing gambar ing ngisor iki:

Bagian server diisi latar mburi abu-abu, bagian klien diisi putih. Conto apik saka pendekatan sing terakhir (tengen) yaiku aplikasi seluler modern. Sisih klien (ing telpon) ngemot tampilan (tampilan), logika, lan data. Lan mung kadhangkala data iki disinkronake karo server.

Conto pilihan paling kiwa iku server PHP khas, kang wis kabeh logika ing server, lan menehi klien wis HTML statis. Nang endi wae ing antarane rong ekstrem iki, proyek sampeyan bakal ditemokake.

Ing wiwitan karya, sawise sampeyan kenal karo proyek kasebut, sampeyan kudu takon karo programer sing nggarap, babagan papan sing luwih apik kanggo sampeyan ngetrapake logika tugas sabanjure.

Bebas bae kanggo nglakoni. Kaping pisanan, dheweke ora mlebu biara wong liya kanthi piagam. Kapindho, bakal luwih gampang kanggo kabeh wong (lan sampeyan uga) nemokake kode sing sampeyan butuhake ing papan sing dikarepake.