Men uzoq vaqt davomida mikroservis arxitekturasi mavzusida maqola yozmoqchi bo'ldim, lekin ikkita nuqta meni to'xtatdi - mavzuga qanchalik chuqur kirib borganim sayin, men bilgan narsam ravshan bo'lib tuyuldi. t bilishni o'rganish va o'rganish kerak. Boshqa tomondan, menimcha, keng omma orasida muhokama qilinadigan narsa allaqachon mavjud. Shunday qilib, muqobil fikrlar mamnuniyat bilan qabul qilinadi.
Konvey qonuni va biznes, tashkilot va axborot tizimi o'rtasidagi munosabatlar
Yana bir bor iqtibos keltirishga ruxsat beraman:
"Tizimni loyihalashtirgan har qanday tashkilot (keng ma'noda) strukturasi ushbu tashkilotdagi jamoalar tuzilishini takrorlaydigan dizaynni oladi."
- Melvin Konvey, 1967 yil
Menimcha, bu qonun to'g'ridan-to'g'ri axborot tizimiga emas, balki biznesni tashkil etishning maqsadga muvofiqligi bilan bog'liq. Bir misol bilan tushuntiraman. Aytaylik, bizda shunday uzoq umr ko'rish davriga ega bo'lgan juda barqaror biznes imkoniyati bor, shuning uchun korxonani tashkil qilish mantiqiy (bu xato emas, lekin men o'g'irlagan bu atama menga juda yoqadi). Tabiiyki, bu biznesni qo'llab-quvvatlash tizimi. tashkiliy va texnologik jihatdan ushbu biznesga mos keladi.
Axborot tizimlarining biznes yo'nalishi
Bir misol bilan tushuntiraman. Aytaylik, pizza sotadigan biznesni tashkil qilish uchun biznes imkoniyati mavjud. V1 versiyasida (keling, uni oldindan ma'lumot deb ataymiz) kompaniya pitseriya, kassa apparati va yetkazib berish xizmati edi. Ushbu versiya atrof-muhitning past o'zgaruvchanligi sharoitida uzoq umr ko'rdi. Keyin uning o'rniga 2-versiya keldi - yanada rivojlangan va monolit arxitekturaga ega biznes uchun asosiy axborot tizimidan foydalanishga qodir. Va bu erda, mening fikrimcha, monolitlarga nisbatan dahshatli adolatsizlik bor - go'yoki monolit arxitektura domen biznes modeliga mos kelmaydi. Ha, agar shunday bo'lsa, tizim umuman ishlay olmas edi - o'sha Konvey qonuniga va sog'lom fikrga zid. Yo'q, monolit arxitektura biznesni rivojlantirishning ushbu bosqichidagi biznes modeliga to'liq mos keladi - men, albatta, tizim allaqachon yaratilgan va ishga tushirilgan bosqichni nazarda tutyapman. Arxitektura yondashuvidan qat'i nazar, xizmatga yo'naltirilgan arxitekturaning 3-versiyasi ham, mikroservislar arxitekturasining N versiyasi ham bir xil darajada yaxshi ishlashi mutlaqo ajoyib haqiqatdir. Tushunish nima?
Hamma narsa oqadi, hamma narsa o'zgaradi yoki mikroservislar murakkablik bilan kurashish vositasimi?
Davom etishdan oldin, keling, mikroservis arxitekturasi haqidagi ba'zi noto'g'ri tushunchalarni ko'rib chiqaylik.
Mikroservis yondashuvidan foydalanish tarafdorlari ko'pincha monolitni mikroservislarga ajratish individual xizmatlarning kod bazasini qisqartirish orqali rivojlanish yondashuvini soddalashtirishini ta'kidlaydilar. Menimcha, bu gap mutlaqo bema'nilik. Jiddiy ravishda, monolit va bir hil kod ichidagi aniq o'zaro ta'sir murakkab ko'rinadi? Agar bu haqiqatan ham shunday bo'lganida, barcha loyihalar dastlab mikroservislar sifatida qurilgan bo'lardi, amaliyot shuni ko'rsatadiki, monolitdan mikroservislarga o'tish ancha keng tarqalgan. Murakkablik yo'qolmaydi; u shunchaki individual modullardan interfeyslarga (ma'lumotlar avtobuslari, RPC, API va boshqa protokollar bo'lsin) va boshqarish tizimlariga o'tadi. Va bu qiyin!
Heterojen stackdan foydalanishning afzalligi ham shubhali. Men bu ham mumkin, deb bahslashmayman, lekin aslida bu kamdan-kam hollarda sodir bo'ladi (Oldinga qarab - bu sodir bo'lishi kerak - afzallik emas, balki oqibat sifatida).
Mahsulotning hayot aylanishi va xizmat ko'rsatish muddati
Yuqoridagi diagrammaga yana bir nazar tashlang. Men biznesning alohida versiyasining hayot aylanishining qisqarishini ta'kidlaganim bejiz emas - zamonaviy sharoitda biznesning versiyalar o'rtasida o'tish jarayonining tezlashishi uning muvaffaqiyati uchun hal qiluvchi ahamiyatga ega. Mahsulotning muvaffaqiyati undagi biznes farazlarini sinab ko'rish tezligi bilan belgilanadi. Va bu erda, mening fikrimcha, mikroservis arxitekturasining asosiy ustunligi. Ammo keling, tartibda boraylik.
Keling, axborot tizimlari evolyutsiyasining keyingi bosqichiga - SOA ning xizmatga yo'naltirilgan arxitekturasiga o'tamiz. Shunday qilib, ma'lum bir nuqtada biz mahsulotimizda ta'kidladik uzoq muddatli xizmatlar - mahsulotning versiyalari o'rtasida o'tishda xizmatning hayot aylanishi mahsulotning keyingi versiyasining hayot tsiklidan uzoqroq bo'lishi ehtimoli borligi ma'nosida uzoq umr ko'rish. Ularni umuman o'zgartirmaslik mantiqan to'g'ri bo'lardi - biz Muhimi, keyingi versiyaga o'tish tezligi. Ammo, afsuski, biz xizmatlarni doimiy ravishda o'zgartirishga majburmiz - va bu erda hamma narsa biz uchun ishlaydi, DevOps amaliyotlari, konteynerlashtirish va boshqalar - aqlga kelgan hamma narsa. Ammo bular hali ham mikroservislar emas!
Mikroservislar murakkablikka qarshi kurash vositasi sifatida... konfiguratsiyani boshqarish
Va bu erda biz nihoyat mikroservislarning aniqlovchi roliga o'tishimiz mumkin - bu mahsulot konfiguratsiyasini boshqarishni soddalashtiradigan yondashuv. Batafsilroq aytadigan bo‘lsak, har bir mikroservisning funksiyasi domen modeliga muvofiq mahsulot ichidagi biznes funksiyasini aniq tasvirlab beradi – bular qisqa muddatli versiyada emas, balki uzoq muddatli biznes imkoniyatida yashaydigan narsalardir. Va mahsulotning keyingi versiyasiga o'tish tom ma'noda sezilmasdan sodir bo'ladi - siz bitta mikroservisni va ehtimol ularning o'zaro ta'siri sxemasini o'zgartirasiz/qo'shasiz va to'satdan siz o'zingizni kelajakda ko'rasiz va bu versiyalar orasida o'tishda davom etadigan yig'layotgan raqobatchilarni ortda qoldirasiz. ularning monolitlari. Endi tasavvur qiling-a, oldindan belgilangan interfeyslar va biznes imkoniyatlariga ega bo'lgan juda katta hajmdagi mikroservislar mavjud. Va siz kelib, mahsulotingizning tuzilishini tayyor mikroservislardan yaratasiz - masalan, diagramma chizish orqali. Tabriklaymiz - sizda platforma bor - va endi siz o'zingiz uchun biznesni jalb qilishingiz mumkin. Orzular Orzular.
topilmalar
- Tizimning arxitekturasi uning tarkibiy qismlarining hayot aylanishi bilan belgilanishi kerak. Agar komponent mahsulot versiyasida yashasa, mikroservis yondashuvidan foydalangan holda tizimning murakkabligini oshirishning ma'nosi yo'q.
- Mikroservis arxitekturasi domen modeliga asoslangan bo'lishi kerak - chunki biznes imkoniyati eng uzoq muddatli domendir
- Yetkazib berish amaliyotlari (DevOps amaliyotlari) va orkestratsiya mikroservis arxitekturasi uchun eng muhimlaridan biridir - chunki komponentlarning o'zgarish tezligining oshishi etkazib berish tezligi va sifatiga talablarni oshiradi.
Manba: www.habr.com