Servisga yo'naltirilgan arxitektura

Enterprise Service Bus (ESB)
Korporativ servis avtobusi veb-xizmatlardan 1990-yillarda birinchi marta paydo bo'lganida foydalangan (ehtimol, ba'zi ilovalar birinchi bo'lib CORBA-dan foydalanganmi?).
ESB kompaniyalarning alohida ilovalari mavjud bo'lgan davrda paydo bo'lgan. Misol uchun, biri moliya bilan ishlash uchun, ikkinchisi kadrlar hisobi uchun, uchinchisi omborlarni boshqarish uchun va hokazo va ular qandaydir tarzda bir-biri bilan bog'langan, qandaydir tarzda birlashtirilgan bo'lishi kerak edi. Ammo bu ilovalarning barchasi integratsiyasiz yaratilgan, ilovalarning o'zaro ta'siri uchun standart til yo'q edi (bugungidek). Shuning uchun, dastur ishlab chiquvchilari ma'lum bir formatda ma'lumotlarni yuborish va qabul qilish uchun so'nggi nuqtalarni taqdim etdilar. Keyin mijozlar kompaniyalari ilovalarni ular o'rtasida aloqa kanallarini o'rnatish va xabarlarni bir dastur tilidan boshqasiga aylantirish orqali birlashtirdilar.
Xabar navbati ilovalarning muloqotini osonlashtirishi mumkin, ammo u turli til formatlari muammosini hal qila olmaydi. Shu bilan birga, xabarlar navbatini oddiy aloqa kanalidan xabarlarni yetkazib beruvchi va ularni kerakli formatlarga/tillarga aylantiruvchi vositachiga aylantirishga harakat qilindi. ESB oddiy xabarlar navbatining tabiiy evolyutsiyasidagi navbatdagi qadam edi.

Ushbu arxitektura modulli dasturdan (kompozit dastur) foydalanadi, odatda foydalanuvchilarga qaratilgan bo'lib, u ba'zi operatsiyalarni bajarish uchun veb-xizmatlar bilan bog'lanadi. O'z navbatida, ushbu veb-xizmatlar boshqa veb-xizmatlar bilan ham bog'lanishi mumkin, keyinchalik ba'zi ma'lumotlarni ilovaga qaytaradi. Lekin na ilova, na backend xizmatlari bir-biri haqida, jumladan joylashuv va aloqa protokollari haqida hech narsa bilishmaydi. Ular faqat qaysi Servisga murojaat qilishni va xizmat avtobusi qayerda joylashganligini bilishadi.
Mijoz (xizmat yoki modulli dastur) xizmat avtobusiga so'rov yuboradi, u xabarni belgilangan manzil tomonidan qo'llab-quvvatlanadigan formatga aylantiradi va so'rovni u erga yo'naltiradi . Barcha shovqinlar xizmat avtobusi orqali o'tadi, shuning uchun agar u tushib qolsa, boshqa barcha tizimlar u bilan birga tushadi. Ya'ni, ESB asosiy vositachi, tizimning juda murakkab tarkibiy qismidir.
Bu ESB arxitekturasining juda soddalashtirilgan tavsifi. Bundan tashqari, ESB arxitekturaning asosiy komponenti bo'lsa-da, tizimda domen brokerlari, ma'lumotlar xizmatlari, jarayonlarni tartibga solish xizmatlari va qoidalar dvigatellari kabi boshqa komponentlardan foydalanish mumkin. Xuddi shu naqsh federativ dizaynda qo'llanilishi mumkin: tizim o'z ESB'lari bo'lgan biznes domenlariga bo'lingan va barcha ESB'lar bir-biriga ulangan. Bunday sxema yuqori ko'rsatkichlarga ega va bitta muvaffaqiyatsizlik nuqtasi yo'q: agar ba'zi ESB tushib qolsa, unda faqat uning biznes sohasi zarar ko'radi.

ESBning asosiy vazifalari:

• 
  Xizmatlar o'rtasida xabar almashinuvini kuzatib boring va yo'naltiring.
  
• 
  Xabarlarni aloqa xizmati komponentlari o'rtasida o'zgartiring.
  
• 
  Xizmatlarni tarqatish va versiyalashni boshqarish.
  
• 
  Ortiqcha xizmatlardan foydalanishni boshqarish.
  
• 
  Standart hodisalarni qayta ishlash, ma'lumotlarni o'zgartirish va xaritalash xizmatlarini, xabarlar va hodisalarni navbatga qo'yish xizmatlarini, xavfsizlik yoki istisnolarni qayta ishlash xizmatlarini, protokollarni o'zgartirish va sifatni ta'minlash xizmatlarini taqdim eting.
  

Turli jarayonlar o'rtasida aloqa tuzilmalarini yaratishda biz juda ilg'or aloqa mexanizmlaridan foydalanadigan ko'plab mahsulotlar va yondashuvlarni ko'rdik. Yaxshi misol - korporativ xizmat avtobuslari, ular ko'pincha murakkab xabarlarni marshrutlash, xoreografiya, tarjima va biznes qoidalariga rioya qilishni o'z ichiga oladi.
Ushbu me'moriy naqshning ijobiy tomonlari bor. Biroq, men buni ayniqsa veb-xizmatlarga "egamiz" bo'lmagan va xizmatlar o'rtasida xabarlarni uzatish, bir nechta veb-xizmatlardan foydalanadigan biznes jarayonlarni boshqarish uchun vositachiga muhtoj bo'lgan holatlarda foydali deb bilaman.
Shuni ham unutmaslikni maslahat beraman, ESB ilovalari allaqachon ishlab chiqilgan va ko'p hollarda konfiguratsiya uchun sudrab va tushirish yordami bilan foydalanuvchi interfeysidan foydalanishga imkon beradi.

Afzalliklar

• 
  Texnologiyalar to'plamining mustaqilligi, xizmatlarni joylashtirish va kengaytirish.
  
• 
  Standart, oddiy va ishonchli aloqa kanali (80-portda HTTP orqali matnni uzatish).
  
• 
  Optimallashtirilgan xabarlar.
  
• 
  Barqaror xabar almashish spetsifikatsiyasi.
  
• 
  Domen kontekstlarini izolyatsiya qilish.
  
• 
  Xizmatlarni ulash va o'chirish qulayligi.
  
• 
  Asinxron xabarlar tizimdagi yukni boshqarishga yordam beradi.
  
• 
  Versiyalash va konversiyani boshqarish uchun yagona nuqta.
  

Kamchiliklar

• 
  Pastroq aloqa tezligi, ayniqsa allaqachon mos keladigan xizmatlar o'rtasida.
  
  • 
    Markazlashtirilgan mantiq.
    
  • 
    Bitta nosozlik butun kompaniyaning aloqa tizimlarini buzishga qodir.
    
  • 
    Konfiguratsiya va qo'llab-quvvatlashning katta murakkabligi.
    
  • 
    Vaqt o'tishi bilan siz ESBda biznes qoidalarini saqlashga kelishingiz mumkin.
    
  • 
    Avtobus shu qadar murakkabki, uni boshqarish uchun butun jamoa kerak.
    
  • 
    Xizmatlarning ESBga yuqori bog'liqligi.
    

Mikroservislar

Mikroservis arxitekturasi SOA tushunchalariga asoslanadi. Uning maqsadi ESB bilan bir xil: biznes domenlarining bir nechta ixtisoslashtirilgan ilovalaridan yagona umumiy korporativ ilovani yaratish.
Mikroservislar va avtobus o'rtasidagi asosiy farq shundaki, ESB yagona korporativ taqsimlangan ilovani olish uchun alohida ilovalarni birlashtirish kontekstida yaratilgan. Mikroservis arxitekturasi esa (asosan) noldan o'zlarining bulutli ilovalarini yaratadigan tez va doimiy o'zgaruvchan biznes kontekstida yaratilgan .
Ya'ni, ESB holatida bizda allaqachon "egalik" bo'lmagan ilovalar mavjud edi va shuning uchun biz ularni o'zgartira olmadik. Mikroservislarga kelsak, biz ilovalar ustidan to'liq nazoratga egamiz (shu bilan birga, tizimda uchinchi tomon veb-xizmatlaridan ham foydalanish mumkin).
Mikroservislarni qurish/loyihalash tabiati chuqur integratsiyani talab qilmaydi. Mikroservislar biznes kontseptsiyasiga, cheklangan kontekstga mos kelishi kerak. Ular o'z holatini saqlab qolishlari, boshqa mikroservislardan mustaqil bo'lishlari kerak va shuning uchun ular kamroq integratsiyaga muhtoj. Ya'ni, past o'zaro bog'liqlik va yuqori ulanish integratsiyaga bo'lgan ehtiyojni kamaytirishning ajoyib yon ta'siriga ega.
ESB arxitekturasining asosiy kamchiliklari boshqa barcha ilovalar bog'liq bo'lgan juda murakkab markazlashtirilgan dastur edi. Mikroservis arxitekturasida esa bu dastur deyarli butunlay olib tashlanadi.
Mikroservislarning butun ekotizimiga singib ketgan elementlar hali ham mavjud. Ammo ular ESBlarga qaraganda ancha kam vazifalarga ega. Misol uchun, xabarlar navbati hali ham mikroservislar o'rtasidagi asinxron aloqa uchun ishlatiladi, ammo bu faqat xabarlarni uzatish uchun kanal, boshqa hech narsa emas. Yoki barcha tashqi ma'lumotlar almashinuvi o'tadigan mikroservislar ekotizimining shlyuzi haqida o'ylashingiz mumkin.


Mikroservislarni qurish kitobining muallifi Sem Nyuman mikroservis arxitekturasining sakkiz tamoyilini bayon qiladi. Bu:

•