Mijoz-server arxitekturasi

1.1 Dastur arxitekturasi

Bu kurs yangi boshlovchilar uchun mo'ljallangan, chunki jiddiy dastur arxitekturasini loyihalash hali uzoq muddatli emas. Lekin, xafa bo'lishga hojat yo'q, yaxshi arxitektura - yaxshi qoida emas, balki istisno. Dasturni yaratishdan oldin to'g'ri arxitekturani tanlash juda qiyin.

Katta serverli dasturlar uchun mashhur arxitektura misollari:

• Ko'p qatlamli arxitektura (Layered Architecture).
• Ko'p darajali arxitektura (Tiered Architecture).
• Xizmatga yo'naltirilgan arxitektura (Service Oriented Architecture – SOA).
• Mikroservis arxitekturasi (Microservice Architecture).

Har birining o'z afzalliklari va kamchiliklari bor. Lekin ularni o'rganishda hech narsa bermaydi. Arxitektura - bu tizim ichidagi minglab obyektlar o'zaro ta'sirini qanday tashkil qilish haqidagi savolga javob. Tosh tajribasiz, muammoning murakkabligini his qilmaguningizcha, yechimning ko'p qirraliligini tushuna olmaysiz.

Barcha dasturlar biron bir arxitekturadan foydalanadi yoki hech bo'lmaganda shunday ko'rsatadi. Shuning uchun, dasturlarni loyihalashning mashhur yondashuvlarini bilish sizga qanday dastur tuzilganligini tez va yaxshiroq tushunishga imkon beradi. Demak, kerakli joylarga o'zgarishlar kiritish mumkin.

«Qayerga kerakli joylarga o'zgarishlar kiritish» nimani anglatadi? O'zgarishlar kiritmaslik kerak bo'lgan joylar bormi? Ha, aynan.

Aniqroq qilish uchun keling, siz o'rta darajadagi backend-proekti bo'yicha ishlayotganingizni taxmin qilaylik. U 20 kishidan iborat jamoa tomonidan 5 yil davomida yozilgan. Loyihaga 100 odam-yil sarflangan, unda taxminan 100 ming kod satrlari bor. U umumiy hisobda ikki ming sinfdan iborat, ular turli o'lchamdagi 10 modulga bo'lingan.

Va qattiq haqiqatni qo'shamiz. Ba'zi vazifalarning logikasi bir nechta modullar bo'ylab yoyilgan. Bundan tashqari, biznes logika frontendda (JavaScriptda yozilgan) va/yoki to'g'ridan-to'g'ri ma'lumotlar bazasida saqlangan protsedura sifatida yozilgan bo'lishi mumkin. Siz hali ham darhol qayerga aniq o'zgarishlar kiritish joyini aniqlay olasiz deb ishonasizmi?

Bu qandaydir dahshat emas, men sizlarni qo'rqitish uchun o'ylab topilgan emas. Bu juda odatiy loyiha. Yana ham yomonrog'i bo'lishi mumkin. Nega bu sodir bo'ladi? Sabablari juda ko'p bo'lishi mumkin, lekin har doim quyidagilar mavjud:

• Loyihada ko'pchilik odamlar ishlaydi - har bir kishi uni biroz boshqacha ko'radi.
• 5 yil davomida loyihada 10 kishi almashdi, yangi odamlar unda chuqur o'rganmadi.
• Dasturiy ta'minot yaratish - bu doimiy o'zgarishlar kiritish, ular doimiy ravishda hamma narsani o'zgartiradi.
• Besh yil avval, arxitekturani tanlashda, loyiha niyati biroz boshqacha edi.

Lekin, eng muhimi, loyiha arxitekturasidan qat'i nazar, unda ishlayotgan barcha dasturchilar, ushbu loyihaning qanday tashkil etilganligini bir xil tushunishlarini saqlab qoldilar. Keling, eng oddiy tushunchadan - mijoz-server arxitekturasidan boshlaymiz.

1.2 Mijoz-server o'zaro ta'sir konsepsiyasi

Endi biz "mijoz-server" arxitekturasining asosini tashkil etuvchi konsepsiyani ko'rib chiqamiz va sizga internetda millionlab dasturlar o'rtasidagi o'zaro ta'sir qanday tashkil etilganligini yaxshiroq tushunishga yordam beradi.

Nomi aniq ko'rinib turibdiki, ushbu konsepsiyada ikki tomon ishtirok etadi: mijoz va server. Bu yerda hamma narsa hayotdagidek: mijoz - bu ma'lum bir xizmat buyurtmachisi, server esa xizmatlarning yetkazib beruvchisi. Mijoz va server jismoniy jihatdan dasturlar ni ifodalaydi, masalan, tipik mijoz - bu brauzer.

Server sifatida quyidagi misollarni keltirish mumkin:

• Veb-serverlar, masalan, Tomcat.
• Ma'lumotlar bazasi serverlari, masalan, MySQL.
• To'lov shlyuzlari, masalan, Stripe.

Mijoz va server odatda internet orqali muloqot qiladi (garchi ular bir local tarmoqda yoki boshqa turdagi har qanday tarmoqlarda ishlashi mumkin bo'lsa-da). Muloqot HTTP, FTP yoki TCP yoki UDP kabi past darajali bo'lgan standart protokollar orqali amalga oshiriladi.

Protokol odatda serverlar tomonidan taqdim etilgan xizmat turiga qarab tanlanadi. Masalan, agar bu videoaloqa bo'lsa, odatda UDP ishlatiladi.

Tomcat va uning servletlari qanday ishlashini eslaysizmi? Server HTTP-xabari oladi, uni ochadi, barcha kerakli ma'lumotlarni chiqarib oladi va ishlov berish uchun servletga yuboradi. Keyin ishlov berish natijasini yana HTTP-response ga o'rab, mijozga yuboradi.

Bu mijoz-server o'zaro ta'sirining tipik bir misolidir. Brauzer - bu veb-mijoz, Tomcat - bu veb-server. Tomcat hatto veb-server deb ham ataladi.

Agar o'ylab ko'rsak, nom emas, mazmun muhim - dasturlar o'rtasidagi rollarni taqsimlash. Sizning HTML sahifasida ishlayotgan JS-skriptni mijoz deb atash mumkin, va sizning servletni server. Ular mijoz-server konsepsiyasi doirasida birgalikda ishlaydi.

1.3 Muhim nuqta

Shuningdek, ta'kidlash joizki, mijoz-server o'zaro ta'sirining asosi shundaki, bunday o'zaro ta'sir mijoz tomonidan boshlanadi: server faqat mijozga javob beradi va mijozga xizmat ko'rsatish mumkinmi va agar mumkin bo'lsa, qanday sharoitda ma'lum qilinadi.

Mijoz va server qayerda joylashganligi muhim emas. Mijoz dasturi va server dasturi odatda turli mashinalarda o'rnatilgan, lekin ular bitta kompyuterda ham ishlashi mumkin.

Ushbu konsepsiya murakkab tizimni soddalashtirishga birinchi qadam sifatida ishlab chiqilgan. Unda quyidagi kuchli tomonlar mavjud:

• Lozikani soddalashtirish: server mijoz haqida hech narsa bilmaydi va u kelajakda uning ma'lumotlarini qanday ishlatishidan.
• Zaif mijozlar bo'lishi mumkin: barcha resurs talab qiladigan vazifalarni serverga ko'chirishingiz mumkin.
• Mijoz kodlari va server kodlarining mustaqil rivojlanishi.
• Turli xil mijozlar, masalan - Tomcat va har xil brauzerlar.

Mijoz va server o'rtasidagi eng asosiy o'zaro ta'sir varianti rasmda ko'rsatilgan:

Bu yerda ikki muhim detallarni ta'kidlash kerak. Birinchidan, rasmda ko'rsatilganidek, bitta serverga ko'plab mijozlar murojaat qilishi mumkin. Ikkinchidan, ular bir vaqtda murojaat qilishi mumkin. Bu ham serverning muhim qismidir.

Bir mijoz odatda bir foydalanuvchi bilan ishlaydi, shuning uchun ko'pincha u yerda hatto avtorizatsiya ham kerak emas. Lekin server minglab mijozlarning so'rovlarini qayta ishlaydi va uning uchun kod yozayotganda avtorizatsiyani autentifikatsiyadan ajrata olish kerak.

Yana bir muhim narsa, server minglab so'rovlarni bir vaqtda qayta ishlaydi. Bu shuni anglatadiki, backend kodini yozayotganda, resurslarga bir vaqtning o'zida kirish masalasi haqida doimo o'ylashingiz kerak bo'ladi. Shuningdek, server kodida race condition (iplar poygasi), deadlock (iplar blokadasi) yuqori ehtimollik bilan sodir bo'ladi.

Muvofiq obyektlarning hayotiy tsiklini majburiy nazorat qilish kerak:

Serverda new Thread().start() orqali yangi ipni shunchaki boshlay olmaysiz. Buning o'rniga, barcha xizmat iplarida ishlatiladigan ThreadPool bo'lishi kerak.

Shuningdek, asinxron vazifani shunchaki boshlay olmaysiz, chunki ular ham alohida iplarida bajariladi. Bunday vazifani yaratishda, har doim qaysi ip-gavhalari uni bajarayotgani va agar bunday gavhalar tolib ketsa nima bo'lishini bilishingiz kerak.

Barcha fayllar va kataloglar bilan ishlash try-with-resources orqali amalga oshirilishi kerak. Oddiy dasturni ishlab chiqayotganda siz fayl yoki ipni yopishni unutdingizmi - bu muammo? U dasturni chiqishda o'z-o'zidan yopiladi. Ammo serverda bir joyda kodda faylni yopishni esdan chiqarib qo'ysangiz, va sizning serveringiz bir necha oylar davomida ishlaydi... Tez orada thousandlab yopilmagan fayllar yig'iladi va OS yangi fayllarni ochishni to'xtatadi (fayllar bilan ishlashni OS nazorat qiladi). Teamlead sizni maqtab qo'ymaydi...

1.4 "Mijoz-server" arxitekturasi

Yana bir muhim nuqta. Mijoz-server arxitekturasi faqat kompyuterlar o'rtasidagi umumiy o'zaro ta'sir printsiplarini belgilaydi, o'zaro ta'sirning tafsilotlarini turli protokollar belgilaydi.

Ushbu konsepsiya (mijoz-server) bizni, tarmoqdagi mashinalarni mijozlarga va serverlarga ajratish kerakligini eslatadi, ulardan mijozlar doimiy ravishda nimadir talab qiladi va serverlar esa kerakli narsani beradi. Bu vaqtda, o'zaro ta'sirni doim mijoz boshlaydi va o'zaro ta'sir qoidalarini protokol tasvirlaydi.

Mijoz-server o'zaro ta'sirining ikki turi mavjud: birinchisi ikki darajali mijoz-server o'zaro ta'sir arxitekturasi, ikkinchisi esa ko'p darajali mijoz-server arxitekturasi (ba'zan uni uch darajali yoki uch qatlamli arxitektura deb ham ataydilar, lekin bu xususiy holat).

Ikki darajali mijoz-server o'zaro ta'sir arxitekturasi ish prinsipi shundan iboratki, so'rovni qayta ishlash bitta serverda amalga oshiriladi, bunday ishlov berish jarayonida boshqa serverlarga murojaat qilmasdan.

Ikki darajali mijoz-server o'zaro ta'sir modelini oddiy sxema sifatida tasvirlash mumkin.

Bu yerda birinchi daraja - bu mijoz bilan bog'liq barcha narsalar, ikkinchi daraja esa server bilan bog'liq barcha narsalarni o'z ichiga oladi.