Servisga yo'naltirilgan arxitektura

Joylashuv mustaqilligi : mijoz kodi qo'ng'iroq mahalliy yoki masofaviy ekanligini bilmaydi. Yaxshi eshitiladi, lekin kechikishning davomiyligi va nosozliklar turlari juda farq qilishi mumkin. Agar bizda qanday qo'ng'iroq borligini bilmasak, dastur qo'ng'iroqlarni qayta ishlash usuli uchun mos strategiyani tanlay olmaydi va shuning uchun tsikl ichida masofaviy qo'ng'iroqlarni yarata olmaydi. Natijada, butun tizim sekinroq ishlaydi.

Murakkab, shishgan va noaniq spetsifikatsiya : U turli sotuvchilardan spetsifikatsiyalarning bir nechta versiyalaridan tuzilgan, shuning uchun (o'sha paytda) shishgan, noaniq va amalga oshirish qiyin edi.

Bloklangan aloqa kanallari (aloqa quvurlari) : TCP / IP orqali maxsus protokollar, shuningdek, ma'lum portlar (yoki hatto tasodifiy portlar) orqali qo'llaniladi. Ammo korporativ xavfsizlik qoidalari va xavfsizlik devorlari ko'pincha CORBA aloqalarini bloklaydigan 80-portda HTTP ulanishlariga ruxsat beradi.



Veb-xizmatlar
Bugungi kunda CORBA-dan foydalanish mavjud bo'lsa-da, tizim ish faoliyatini yaxshilash uchun masofaviy kirishlar sonini kamaytirish zarurligini bilamiz . Bundan tashqari , ishonchli aloqa kanali va oddiyroq xabar almashish spetsifikatsiyasi kerak edi.
Va bu muammolarni hal qilish uchun veb-servislar 1990-yillarning oxirida paydo bo'la boshladi.
Bizga ishonchli aloqa kanali kerak edi , shuning uchun:
HTTP endi sukut bo'yicha 80-portda ishlaydi.

• 
  Xabar almashish uchun ular platformadan mustaqil tildan foydalanishni boshladilar (masalan, XML yoki JSON).
  
• 
  Masofaviy qo'ng'iroqlar sonini kamaytirish kerak edi , shuning uchun:
  
  
  
  • 
    Masofaviy ulanishlar aniq amalga oshiriladi, shuning uchun biz endi masofaviy qo'ng'iroq qachon amalga oshirilganini har doim bilamiz.
    
  • 
    Ko'p masofaviy ob'ekt qo'ng'iroqlari o'rniga biz masofaviy xizmatlardan foydalanamiz, lekin kamroq.
    
• 
  Xabarlar spetsifikatsiyasini soddalashtirish kerak edi , shuning uchun:
  
  
  
  • 
    SOAPning birinchi loyihasi 1998 yilda paydo bo'lgan, 2003 yilda W3C tavsiyasiga aylandi, shundan so'ng u standartga aylandi. SOAP ba'zi CORBA g'oyalarini o'z ichiga oladi, masalan, xabar almashish uchun qatlam va veb-xizmatlarni tavsiflash tili (WSDL ) yordamida interfeysni belgilaydigan "hujjat" .
    
  • 
    Roy Fielding 2000 yilda o'zining "Architectural Styles and Design of Network-based Software Architectures" dissertatsiyasida RESTni tasvirlab berdi . Uning spetsifikatsiyasi SOAP-ga qaraganda ancha sodda bo'lib chiqdi, shuning uchun REST tez orada mashhurlik bo'yicha SOAPni ortda qoldirdi.
    
  • 
    Facebook 2012-yilda GraphQL-ni ishlab chiqdi va 2015-yilda ommaga taqdim etdi. Bu API uchun so'rovlar tili bo'lib, mijozga server unga qanday ma'lumotlarni yuborishi kerakligini, ko'p yoki kam emas, qat'iy belgilash imkonini beradi.
    

Mikroservislar tufayli biz SOA paradigmasida masofaviy ob'ekt usulini chaqirishdan (CORBA) xizmatlar o'rtasida xabarlarni uzatishga o'tdik.

Ammo shuni tushunishingiz kerakki, SOA doirasida veb-xizmatlar shunchaki umumiy maqsadli APIlar emas, ular HTTP orqali ma'lumotlar bazasiga CRUD kirishini ta'minlaydi. Ushbu dastur ba'zi hollarda foydali bo'lishi mumkin, ammo ma'lumotlaringizning yaxlitligi foydalanuvchilar asosiy modelni tushunishlarini va biznes qoidalariga rioya qilishlarini talab qiladi . SOA veb-xizmatlari biznes sub-domenlarining (biznes sub-domeni) cheklangan kontekstlari ekanligini anglatadi va amalga oshirishni veb-xizmatlar tomonidan hal qilinadigan vazifalardan ajratib turadi.

Texnologik nuqtai nazardan, SOA nafaqat xizmat ko'rsatish arxitekturasi, balki bizga kerakli xizmatlarni taqdim etish va olish imkonini beradigan siyosatlar, amaliyotlar va ramkalar to'plamidir.

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.
  

Kamchiliklar

Xabarlarni uzatish tillaridagi farqlar tufayli turli veb-xizmatlarni birlashtirish qiyin. Masalan, ikkita veb-xizmat bir xil kontseptsiyaning turli JSON ko'rinishlaridan foydalanadi.

• 
  Sinxron xabarlar tizimlarni ortiqcha yuklashi mumkin.
  

xabar navbati

Bizda platformadan mustaqil xabarlar yordamida bir-biri bilan asinxron aloqada bo'ladigan bir nechta ilovalar mavjud. Message Queuing miqyosni yaxshilaydi va dastur izolyatsiyasini yaxshilaydi. Ular boshqa ilovalarning qaerdaligini, ularning soni va hatto nima ekanligini bilishlari shart emas. Biroq, bu ilovalarning barchasi bir xil xabar almashish tilidan, ya'ni oldindan belgilangan matnli ma'lumotlar formatidan foydalanishi kerak.

Xabar navbati infratuzilma komponenti sifatida dasturiy xabarlar brokeridan (RabbitMQ, Beanstalkd, Kafka va boshqalar) foydalanadi. Ilovalar o'rtasidagi aloqani amalga oshirish uchun siz navbatni turli yo'llar bilan sozlashingiz mumkin:

•