Java mikroservislari bo'yicha qo'llanma. 3-qism: Umumiy savollar

Java mikroservislarini tarjima qilish va moslashtirish : amaliy qo'llanma . Qo'llanmaning oldingi qismlari:

• mikroservis asoslari va ularning arxitekturasi ;
• mikroservislarni joylashtirish va sinovdan o'tkazish .

Keling, mavhum narsalardan boshlab va aniq kutubxonalar bilan yakunlangan Java-dagi mikroservislarning o'ziga xos muammolarini ko'rib chiqaylik.

Java mikroxizmatini qanday qilib barqaror qilish mumkin?

Eslatib o'tamiz, siz mikroservislarni yaratganingizda, siz sinxron HTTP qo'ng'iroqlari yoki asinxron xabarlar uchun JVM usuli qo'ng'iroqlarini sotasiz. Usul chaqiruvi asosan yakunlanishi kafolatlangan bo'lsa-da (kutilmagan JVM yopilishidan tashqari), tarmoq qo'ng'irog'i sukut bo'yicha ishonchsizdir. U ishlashi mumkin, lekin u turli sabablarga ko'ra ishlamasligi mumkin: tarmoq haddan tashqari yuklangan, yangi xavfsizlik devori qoidasi joriy qilingan va hokazo. Bu qanday farq qilishini ko'rish uchun, keling, BillingService misolini ko'rib chiqaylik.

HTTP/REST chidamlilik namunalari

Aytaylik, mijozlar kompaniyangiz veb-saytida elektron kitoblarni sotib olishlari mumkin. Buni amalga oshirish uchun siz haqiqiy PDF hisob-fakturalarini yaratish uchun onlayn-do'koningizga qo'ng'iroq qila oladigan hisob-kitob mikroxizmatini joriy qildingiz. Hozircha biz ushbu qo‘ng‘iroqni HTTP orqali sinxron tarzda amalga oshiramiz (garchi bu xizmatni sinxron tarzda chaqirish mantiqiyroq bo‘lsa-da, chunki PDF yaratish foydalanuvchi nuqtai nazaridan bir zumda bo‘lishi shart emas. Keyingi misolda ham xuddi shu misoldan foydalanamiz. bo'limga o'ting va farqlarga qarang).

@Service
class BillingService {

    @Autowired
    private HttpClient client;

     public void bill(User user, Plan plan) {
        Invoice invoice = createInvoice(user, plan);
        httpClient.send(invoiceRequest(user.getEmail(), invoice), responseHandler());
        // ...
    }
}

Xulosa qilib aytganda, bu HTTP chaqiruvining uchta mumkin bo'lgan natijasidir.

• OK: qo'ng'iroq amalga oshirildi, hisob muvaffaqiyatli yaratildi.
• Kechikish: Qo'ng'iroq amalga oshdi, lekin uni bajarish uchun juda uzoq vaqt ketdi.
• XATO. Qo'ng'iroq amalga oshmadi, siz mos kelmaydigan so'rov yuborgan bo'lishingiz mumkin yoki tizim ishlamayotgan bo'lishi mumkin.

Har qanday dastur faqat muvaffaqiyatli bo'lganlarni emas, balki xatolik holatlarini ham hal qilishi kutiladi. Xuddi shu narsa mikroservislarga ham tegishli. Agar siz alohida mikroservislarni joylashtirish va chiqarishni boshlaganingizdan so'ng API ning barcha o'rnatilgan versiyalari mos kelishini ta'minlash uchun qo'shimcha kuch sarflashingiz kerak bo'lsa ham. Ko'rib chiqish uchun qiziqarli holat - bu kechikish ishi. Misol uchun, javob beruvchining mikroservis qattiq diski to'lgan va javob berish uchun 50 ms o'rniga 10 soniya kerak bo'ladi. Agar ma'lum bir yukni boshdan kechirsangiz, bu yanada qiziqroq bo'ladi, shunda BillingService javob bermasligi tizimingiz orqali kaskadlana boshlaydi. Tasviriy misol sifatida, oshxonani asta-sekin barcha restoran ofitsiantlarining "blokini" boshlaganini tasavvur qiling. Ushbu bo'lim mikroservisning moslashuvchanligi mavzusini to'liq ko'rib chiqa olmasligi aniq, ammo bu ishlab chiquvchilarga bu birinchi nashrdan oldin e'tiborga olinishi kerak bo'lgan va e'tibordan chetda qolmasligi kerak bo'lgan narsa ekanligini eslatib turadi (bu tajribaga qaraganda tez-tez sodir bo'ladi. emas). quyidagi). Kechikish va xatolarga chidamlilik haqida o'ylashga yordam beradigan mashhur kutubxona Netflix-ning Hystrix-dir. Mavzuga chuqurroq kirib borish uchun uning hujjatlaridan foydalaning.

Xabar almashish chidamliligi namunalari

Keling, asinxron aloqani batafsil ko'rib chiqaylik. Bizning BillingService dasturimiz xabar almashish uchun Spring va RabbitMQ dan foydalanayotgan bo'lsak, endi shunday ko'rinishi mumkin. Hisob qaydnomasini yaratish uchun biz RabbitMQ xabar brokerimizga xabar yuboramiz, u erda bir nechta ishchilar yangi xabarlarni kutmoqda. Ushbu ishchilar PDF hisob-fakturalarini yaratadilar va ularni tegishli foydalanuvchilarga yuboradilar.

@Service
class BillingService {

    @Autowired
    private RabbitTemplate rabbitTemplate;

     public void bill(User user, Plan plan) {
        Invoice invoice = createInvoice(user, plan);
        // преобразует счет, например, в json и использует его How тело messages
        rabbitTemplate.convertAndSend(exchange, routingkey, invoice);
        // ...
    }
}

Potensial xatolar endi biroz boshqacha ko'rinadi, chunki siz sinxron HTTP ulanishi kabi darhol OK yoki XATO javoblarini olmaysiz. Buning o'rniga, bizda quyidagi savollar tug'ilishi mumkin bo'lgan noto'g'ri bo'lishi mumkin bo'lgan uchta potentsial stsenariy bo'lishi mumkin:

1. Mening xabarim xodim tomonidan yetkazildi va foydalanildimi? Yoki yo'qolganmi? (Foydalanuvchi hisob-fakturani olmaydi).
2. Mening xabarim faqat bir marta yetkazilganmi? Yoki bir necha marta yetkazib berilgan va faqat bir marta qayta ishlanganmi? (Foydalanuvchi bir nechta hisob-fakturalarni oladi).
3. Konfiguratsiya: "Men almashish uchun to'g'ri marshrutlash kalitlari/nomlaridan foydalandimmi" dan "Mening xabarlar brokerim to'g'ri sozlanganmi va saqlanganmi yoki uning navbatlari to'lganmi?" (Foydalanuvchi hisob-fakturani olmaydi).

Har bir asinxron mikroxizmat moslashuvchanligi namunasining batafsil tavsifi ushbu qo'llanma doirasidan tashqarida. Biroq, to'g'ri yo'nalishda belgilar mavjud. Bundan tashqari, ular xabar almashish texnologiyasiga bog'liq bo'ladi. Misollar:

• Agar siz ActiveMQ kabi JMS ilovalaridan foydalansangiz, ikki fazali (XA) majburiyatlar kafolati uchun tezlikni almashishingiz mumkin.
• Agar siz RabbitMQ dan foydalanayotgan bo'lsangiz, avval ushbu qo'llanmani o'qing, so'ngra tasdiqlar, nosozliklarga chidamlilik va umuman xabar ishonchliligi haqida yaxshilab o'ylab ko'ring.
• Ehtimol, kimdir Active yoki RabbitMQ serverlarini sozlashni yaxshi biladi, ayniqsa klasterlash va Docker bilan birgalikda (har kim? ;))

Qaysi ramka Java mikroservislari uchun eng yaxshi yechim bo'ladi?

Bir tomondan, siz Spring Boot kabi juda mashhur variantni o'rnatishingiz mumkin . Bu .jar fayllarini yaratishni juda oson qiladi, Tomcat yoki Jetty kabi o'rnatilgan veb-server bilan birga keladi va tez va istalgan joyda ishga tushirilishi mumkin. Mikroservis dasturlarini yaratish uchun ideal. Yaqinda qisman reaktiv dasturlashdan ilhomlangan Kubernetes yoki GraalVM ixtisoslashgan bir nechta mikroservis ramkalari paydo bo'ldi. Mana yana bir nechta qiziqarli da'vogarlar: Quarkus , Micronaut , Vert.x , Helidon . Oxir-oqibat, siz o'zingiz uchun tanlov qilishingiz kerak bo'ladi, lekin biz sizga mutlaqo standart bo'lmasligi mumkin bo'lgan bir nechta tavsiyalarni berishimiz mumkin: Spring Boot bundan mustasno, barcha mikroservislar ramkalari odatda deyarli bir lahzada ishga tushirish bilan nihoyatda tez sotiladi. , kam xotiradan foydalanish, cheksizgacha miqyoslash. Marketing materiallari odatda platformani begemot Spring Boot yonida yoki bir-biriga ko'rsatadigan ta'sirchan grafikalarga ega. Bu, nazariy jihatdan, ba'zan yuklash uchun bir necha daqiqa davom etadigan eski loyihalarni qo'llab-quvvatlovchi ishlab chiquvchilarning asablarini saqlaydi. Yoki bulutda ishlaydigan ishlab chiquvchilar 50 ms ichida hozir kerak bo'lganda shuncha mikrokonteynerni ishga tushirish/to'xtatish. Ammo muammo shundaki, bu (sun'iy) yalang'och metallni ishga tushirish vaqtlari va qayta joylashtirish vaqtlari loyihaning umumiy muvaffaqiyatiga deyarli hissa qo'shmaydi. Hech bo'lmaganda ular kuchli ramka infratuzilmasi, kuchli hujjatlar, hamjamiyat va kuchli ishlab chiquvchi qobiliyatlariga qaraganda kamroq ta'sir qiladi. Demak, bunga shunday qarash yaxshidir: Agar hozirgacha:

• Siz oddiy ish oqimlari uchun yuzlab so'rovlarni yaratib, ORM-larning keng tarqalishiga ruxsat berasiz.
• O'rtacha murakkab monolitni ishlatish uchun sizga cheksiz gigabaytlar kerak bo'ladi.
• Sizda shunchalik ko'p kod bor va murakkablik shunchalik yuqoriki (biz hozir Hibernate kabi potentsial sekin boshlanuvchilar haqida gapirmayapmiz), ilovangizni yuklash uchun bir necha daqiqa vaqt ketadi.

Agar shunday bo'lsa, qo'shimcha mikoservis muammolarini qo'shish (tarmoq barqarorligi, xabar almashish, DevOps, infratuzilma) sizning loyihangizga bo'sh Salom, dunyoni yuklashdan ko'ra ko'proq ta'sir qiladi. Rivojlanish jarayonida issiq qayta joylashtirish uchun siz JRebel yoki DCEVM kabi echimlarga ega bo'lishingiz mumkin . Keling, yana Saymon Braunning so'zlaridan iqtibos keltiramiz : " Agar odamlar (tez va samarali) monolitlar qura olmasalar, ular tuzilishidan qat'i nazar, mikroservislarni (tez va samarali) qurishda qiynaladilar ." Shunday qilib, ramkalaringizni oqilona tanlang.

Qaysi kutubxonalar sinxron Java REST qo'ng'iroqlari uchun eng yaxshisidir?

Past darajadagi texnik tomondan, siz quyidagi HTTP mijozlar kutubxonalaridan biriga ega bo'lishingiz mumkin: Java-ning mahalliy HttpClient (Java 11-dan beri), Apache-ning HttpClient yoki OkHttp . E'tibor bering, men bu erda "ehtimol" deyapman, chunki eski yaxshi JAX-RS mijozlaridan zamonaviy WebSocket mijozlarigacha bo'lgan boshqa variantlar mavjud . Har qanday holatda, tendentsiya HTTP mijozini yaratish, HTTP qo'ng'iroqlari bilan shug'ullanishdan voz kechishdir. Buning uchun siz OpenFeign loyihasini va uning hujjatlarini keyingi o'qish uchun boshlang'ich nuqtasi sifatida ko'rib chiqishingiz kerak .

Asinxron Java xabar almashish uchun eng yaxshi brokerlar qaysilar?

Katta ehtimol bilan siz mashhur ActiveMQ (Classic yoki Artemis) , RabbitMQ yoki Kafka bilan uchrashasiz .

• ActiveMQ va RabbitMQ an'anaviy, to'liq huquqli xabar brokerlaridir. Ular "aqlli broker" va "ahmoq foydalanuvchilar" ning o'zaro ta'sirini o'z ichiga oladi.
• Tarixan, ActiveMQ RabbitMQ/Docker/TestContainer sozlamalari bilan yumshatilishi mumkin bo'lgan oson inlining (sinov uchun) afzalliklariga ega edi.
• Kafkani an'anaviy "aqlli" broker deb atash mumkin emas. Buning o'rniga, bu aqlli iste'molchilarni qayta ishlashni talab qiladigan nisbatan "soqov" xabarlar do'koni (jurnal fayli).

RabbitMQ (yoki umuman boshqa an'anaviy xabar brokerlari) yoki Kafkadan qachon foydalanishni yaxshiroq tushunish uchun boshlang'ich nuqtasi sifatida ushbu asosiy postni ko'rib chiqing . Umuman olganda, xabar almashish brokerini tanlayotganda, sun'iy ishlash sabablarini e'tiborsiz qoldirishga harakat qiling. Jamoalar va onlayn hamjamiyatlar RabbitMQ qanchalik tez va ActiveMQ qanchalik sekin ekanligi haqida doimiy ravishda bahslashadigan vaqt bor edi. Endi RabbitMQ haqida ham xuddi shunday dalillar keltiriladi, ular soniyasiga 20-30 ming xabar bilan sekin ishlayotganini aytishadi. Kafka soniyasiga 100 ming xabar yozadi. Ochig'ini aytganda, bunday qiyoslar iliq bilan yumshoq solishtirishga o'xshaydi. Bundan tashqari, ikkala holatda ham o'tkazuvchanlik qiymatlari, masalan, Alibaba guruhining past va o'rta oralig'ida bo'lishi mumkin. Biroq, haqiqatda siz bunday miqyosdagi loyihalarni (daqiqada millionlab xabarlar) uchratishingiz dargumon. Ular, albatta, mavjud va ularda muammolar bo'ladi. Boshqa 99% "muntazam" Java biznes loyihalaridan farqli o'laroq. Shuning uchun moda va shov-shuvlarga e'tibor bermang. Donolik bilan tanlang.

Mikroservislarni sinab ko'rish uchun qanday kutubxonalardan foydalanishim mumkin?

Bu sizning to'plamingizga bog'liq. Agar sizda Spring ekotizimingiz o'rnatilgan bo'lsa, ramkaning maxsus vositalaridan foydalanish oqilona bo'lardi . Agar JavaEE Arquillian kabi bo'lsa . Mahalliy ishlab chiqish yoki integratsiya testlari uchun Oracle ma'lumotlar bazasini osongina va tez o'rnatishga yordam beradigan Docker va haqiqatan ham yaxshi Testcontainers kutubxonasini ko'rib chiqishga arziydi . Butun HTTP serverlarini soxta sinovdan o'tkazish uchun Wiremock ni tekshiring . Asinxron xabar almashishni sinab ko'rish uchun ActiveMQ yoki RabbitMQ-ni qo'llang va keyin Awaitility DSL yordamida testlarni yozing . Bundan tashqari, barcha odatiy vositalaringiz ishlatiladi - Junit , TestNG for AssertJ va Mockito . E'tibor bering, bu to'liq ro'yxat emas. Agar siz o'zingiz yoqtirgan vositani bu erda topmasangiz, uni sharhlar bo'limiga qo'ying.

Barcha Java mikroservislari uchun jurnalni qanday yoqish mumkin?

Mikroservislar uchun tizimga kirish qiziqarli va juda murakkab mavzu. Kamroq yoki grep buyruqlari bilan boshqarishingiz mumkin bo'lgan bitta jurnal fayliga ega bo'lish o'rniga, endi sizda n ta jurnal fayli bor va ular juda tarqoq bo'lmasligini xohlaysiz. Yog'ochni kesish ekotizimining xususiyatlari ushbu maqolada yaxshi tasvirlangan (ingliz tilida). Uni o'qib chiqishga ishonch hosil qiling va mikroservislar nuqtai nazaridan markazlashtirilgan ro'yxatga olish bo'limiga e'tibor bering . Amalda siz turli xil yondashuvlarga duch kelasiz: tizim ma'muri turli serverlardagi jurnal fayllarini to'playdigan va birlashtiradigan ma'lum skriptlarni yozadi va ularni FTP serverlariga yuklab olish uchun joylashtiradi. Parallel SSH seanslarida cat/grep/unig/sort kombinatsiyalarini ishga tushirish. Amazon AWS aynan shunday qiladi va bu haqda menejeringizga xabar berishingiz mumkin. Graylog yoki ELK Stack (Elasticsearch, Logstash, Kibana) kabi vositalardan foydalaning.

Mening mikroservislarim bir-birini qanday topadi?

Hozirgacha biz mikroservislarimiz bir-biri haqida biladi va tegishli IPS-ni biladi deb taxmin qildik. Keling, statik konfiguratsiya haqida gapiraylik. Shunday qilib, bizning bank monolitimiz [ip = 192.168.200.1] xususiyatlar faylida qattiq kodlangan risk serveri [ip = 192.168.200.2] bilan gaplashish kerakligini biladi. Biroq, siz narsalarni yanada dinamik qilishingiz mumkin:

• Bulutga asoslangan konfiguratsiya serveridan foydalaning, undan barcha mikroservislar oʻz mikroservislarida application.properties fayllarini joylashtirish oʻrniga oʻz konfiguratsiyalarini oladi.
• Sizning xizmat ko'rsatish namunalaringiz o'z joylashuvini dinamik ravishda o'zgartirishi mumkinligi sababli, sizning xizmatlaringiz qayerda yashashi, ularning IP manzillari va ularni qanday yo'naltirish kerakligini biladigan xizmatlarni ko'rib chiqishga arziydi.
• Endi hamma narsa dinamik, yangi muammolar paydo bo'ladi, masalan, rahbarni avtomatik tanlash: masalan, ikki marta qayta ishlamaslik uchun muayyan vazifalarni bajaradigan usta kim? Rahbar muvaffaqiyatsizlikka uchraganida uni kim almashtiradi? Qanday asosda almashtirish amalga oshiriladi?

Umuman olganda, bu mikroservis orkestratsiyasi deb ataladigan narsa va bu boshqa tubsiz mavzu. Evrika yoki Zookeeper kabi kutubxonalar qaysi xizmatlar mavjudligini ko'rsatib, bu muammolarni "hal qilishga" harakat qiladi. Boshqa tomondan, ular qo'shimcha murakkablikni keltirib chiqaradi. ZooKeeper-ni o'rnatgan har kimdan so'rang.

Java mikroservislari yordamida avtorizatsiya va autentifikatsiyani qanday tashkil qilish mumkin?

Bu mavzu ham alohida hikoya qilishga arziydi. Shunga qaramay, variantlar maxsus xavfsizlik tizimlari bilan qattiq kodlangan asosiy HTTPS autentifikatsiyasidan tortib, o'zining avtorizatsiya serveri bilan Oauth2 o'rnatilishini ishga tushirishgacha.

Barcha muhitlarim bir xil ko'rinishiga qanday ishonch hosil qilishim mumkin?

Mikroservissiz o'rnatishlar uchun to'g'ri bo'lgan narsa bittasi bilan tarqatish uchun ham amal qiladi. Docker/Testcontainers va Scripting/Ansible kombinatsiyasini sinab ko'ring.

Savol yo'q: YAML haqida qisqacha

Keling, kutubxonalar va tegishli masalalardan bir lahzaga uzoqlashamiz va Yamlni tezda ko'rib chiqamiz. Ushbu fayl formati de-fakto "konfiguratsiyani kod sifatida yozish" formati sifatida ishlatiladi. Bundan tashqari, Ansible kabi oddiy vositalar va Kubernetes kabi gigantlar tomonidan qo'llaniladi. YAML indentatsiyasining og'rig'ini boshdan kechirish uchun oddiy Ansible faylini yozib ko'ring va kutilgandek ishlashidan oldin faylni qanchalik tahrirlashingiz kerakligini ko'ring. Va bu format barcha asosiy IDElar tomonidan qo'llab-quvvatlansa ham! Shundan so'ng, ushbu qo'llanmani o'qishni tugatish uchun qaytib keling.

Yaml:
  - is:
    - so
    - great

Taqsimlangan tranzaktsiyalar haqida nima deyish mumkin? Ishlash testi? Boshqa mavzular?

Ehtimol, bir kun kelib, qo'llanmaning keyingi nashrlarida. Hozircha hammasi shu. Biz bilan qoling!

Mikroservislar bilan bog'liq kontseptual muammolar

Java-da mikroservislarning o'ziga xos muammolaridan tashqari, boshqa muammolar ham mavjud, aytaylik, har qanday mikroservis loyihasida paydo bo'ladigan muammolar. Ular asosan tashkilot, jamoa va boshqaruv bilan bog'liq.

Frontend va Backend nomuvofiqligi

Frontend va Backend nomuvofiqligi ko'plab mikroservis loyihalarida juda keng tarqalgan muammodir. Bu nima degani? Faqat eski yaxshi monolitlarda veb-interfeys ishlab chiquvchilari ma'lumotlarni olish uchun ma'lum bir manbaga ega edilar. Mikroservis loyihalarida front-end ishlab chiquvchilari to'satdan ma'lumot olish uchun n ta manbaga ega bo'lishadi. Tasavvur qiling-a, siz Java-da IoT (Internet of Things) mikroservislari loyihasini yaratyapsiz. Aytaylik, siz butun Evropa bo'ylab geodeziya mashinalari va sanoat pechlarini boshqarasiz. Va bu pechlar sizga o'zlarining haroratlari va shunga o'xshash narsalar bilan muntazam yangilanishlarni yuboradi. Ertami-kechmi siz administrator interfeysida pechlarni topishni xohlashingiz mumkin, ehtimol "o'choq qidirish" mikroservislaridan foydalaning. Backend hamkasblaringiz domenga asoslangan dizayn yoki mikroservis qonunlarini qanchalik qat'iy qo'llashiga qarab , "pechni top" mikroxizmati turi, modeli yoki joylashuvi kabi boshqa ma'lumotlarni emas, balki faqat pech identifikatorlarini qaytarishi mumkin. Buning uchun frontend ishlab chiquvchilari birinchi mikroservisdan olgan identifikatorlari bilan "o'choq ma'lumotlarini olish" mikroxizmatida bitta yoki qo'shimcha qo'ng'iroqlarni (peyjingni amalga oshirishga qarab) amalga oshirishlari kerak bo'ladi. Va bu oddiy misol bo'lsa ham, haqiqiy (!) loyihadan olingan bo'lsa ham, u quyidagi muammoni ko'rsatadi: supermarketlar juda mashhur bo'lib ketdi. Sababi, ular bilan sabzavot, limonad, muzlatilgan pitsa va hojatxona qog‘ozi sotib olish uchun 10 ta turli joyga borishingiz shart emas. Buning oʻrniga siz bir joyga borasiz. Bu osonroq va tezroq. Xuddi shu narsa front-end va mikroservis ishlab chiquvchilari uchun ham amal qiladi.

Boshqaruv umidlari

Rahbariyat endi (umumiy) loyiha uchun cheksiz sonli ishlab chiquvchilarni yollashlari kerak degan noto'g'ri taassurotda, chunki endi ishlab chiquvchilar bir-biridan mutlaqo mustaqil, har biri o'z mikroservislarida ishlashi mumkin. Oxirida faqat bir oz integratsiya ishlari talab qilinadi (ishga tushirishdan biroz oldin). Aslida, bu yondashuv juda muammoli. Keyingi paragraflarda nima uchun buni tushuntirishga harakat qilamiz.

"Kichikroq bo'laklar" "yaxshiroq bo'laklarga" teng emas

20 qismga bo'lingan kod bir butun bo'lakdan ko'ra yuqori sifatga ega bo'ladi deb o'ylash katta xato bo'ladi. Sifatni faqat texnik nuqtai nazardan oladigan bo'lsak ham, bizning shaxsiy xizmatlarimiz hali ham qo'llab-quvvatlanmaydigan kod qatlamlarini bosib o'tib, ma'lumotlar bazasidan foydalanuvchi tanlash uchun 400 Hibernate so'rovini bajarishi mumkin. Yana bir bor Saymon Braun iqtibosiga qaytamiz: agar siz monolitlarni to'g'ri qura olmasangiz, to'g'ri mikroservislarni yaratish qiyin bo'ladi. Mikroservis loyihalarida xatolarga chidamlilik haqida gapirish ko'pincha juda kech. Shunday qilib, ba'zida mikroservislarning haqiqiy loyihalarda qanday ishlashini ko'rish qo'rqinchli. Buning sababi shundaki, Java dasturchilari xatolarga chidamlilik, tarmoq va boshqa tegishli mavzularni kerakli darajada o'rganishga har doim ham tayyor emaslar. "Bo'laklar" ning o'zlari kichikroq, ammo "texnik qismlar" kattaroqdir. Tasavvur qiling-a, sizning mikroservislar jamoasidan ma'lumotlar bazasi tizimiga kirish uchun texnik mikroservis yozish so'raladi, masalan:

@Controller
class LoginController {
    // ...
    @PostMapping("/login")
    public boolean login(String username, String password) {
        User user = userDao.findByUserName(username);
        if (user == null) {
            // обработка варианта с несуществующим пользователем
            return false;
        }
        if (!user.getPassword().equals(hashed(password))) {
            // обработка неверного пароля
            return false;
        }
        // 'Ю-ху, залогинorсь!';
        // установите cookies, делайте, что угодно
        return true;
    }
}

Endi sizning jamoangiz bu juda oddiy va zerikarli ekanligiga qaror qilishi mumkin (va, ehtimol, ishbilarmonlarni ham ishontirishi mumkin), login xizmatini yozish o'rniga, hech qanday haqiqiy va aniq biznes talablarisiz haqiqatan ham foydali UserStateChanged mikroservisni yozish yaxshiroqdir. Va hozirda ba'zi odamlar Java-ga dinozavr kabi munosabatda bo'lganligi sababli, keling, UserStateChanged mikroservisimizni zamonaviy Erlang tilida yozaylik. Va keling, bir joyda qizil-qora daraxtlardan foydalanishga harakat qilaylik, chunki Stiv Yegge Google'ga murojaat qilish uchun ularni ichkaridan bilish kerakligini yozgan. Integratsiya, texnik xizmat ko'rsatish va umumiy dizayn nuqtai nazaridan, bu bitta monolit ichida spagetti kodining qatlamlarini yozish kabi yomon. Sun'iy va oddiy misol? Ha shunaqa. Biroq, bu haqiqatda sodir bo'lishi mumkin.

Kamroq qismlar - kamroq tushunish

Shunda tabiiy ravishda tizimni, uning jarayonlarini va ish oqimlarini tushunish haqida savol tug'iladi, lekin shu bilan birga siz ishlab chiquvchi sifatida faqat izolyatsiya qilingan mikroservisingizda ishlash uchun javobgarsiz [95: login-101: updateUserProfile]. Bu avvalgi xatboshiga mos keladi, lekin tashkilotingizga, ishonch va aloqa darajasiga qarab, bu mikroservis zanjirida tasodifiy buzilish sodir bo'lsa, bu juda ko'p chalkashliklarga, yelka qisishga va ayblashga olib kelishi mumkin. Va sodir bo'lgan voqea uchun to'liq javobgarlikni o'z zimmasiga oladigan hech kim yo'q. Va bu umuman insofsizlik masalasi emas. Aslida, turli qismlarni ulash va ularning loyihaning umumiy rasmidagi o'rnini tushunish juda qiyin.

Aloqa va xizmat ko'rsatish

Aloqa va xizmat ko'rsatish darajasi kompaniya hajmiga qarab juda farq qiladi. Biroq, umumiy munosabatlar aniq: qanchalik ko'p bo'lsa, shunchalik muammoli.

• №47 mikroservisni kim boshqaradi?
• Ular hozirgina mikroservisning yangi, mos kelmaydigan versiyasini o'rnatdimi? Bu qayerda hujjatlashtirilgan?
• Yangi xususiyatni so'rash uchun kim bilan gaplashishim kerak?
• Bu tilni bilgan yagona odam kompaniyadan ketganidan keyin Erlangdagi mikroservisni kim qo'llab-quvvatlaydi?
• Bizning barcha mikroservis jamoalarimiz nafaqat turli dasturlash tillarida, balki turli vaqt zonalarida ham ishlaydi! Bularning barchasini qanday qilib to'g'ri muvofiqlashtiramiz?

Asosiy nuqta shundaki, DevOps-da bo'lgani kabi, yirik, ehtimol hatto xalqaro kompaniyada mikroservislarga to'liq yondashish bir qator qo'shimcha aloqa muammolari bilan birga keladi. Va kompaniya bunga jiddiy tayyorgarlik ko'rishi kerak.

xulosalar

Ushbu maqolani o'qib chiqqandan so'ng, muallif mikroservislarning ashaddiy raqibi deb o'ylashingiz mumkin. Bu mutlaqo to'g'ri emas - men asosan yangi texnologiyalar uchun aqldan ozgan poygada kam odam e'tibor beradigan fikrlarni ta'kidlashga harakat qilaman.

Mikroservislarmi yoki monolitmi?

Java mikroxizmatlaridan istalgan vaqtda, istalgan joyda foydalanish - bu bir ekstremal. Ikkinchisi monolitdagi yuzlab yaxshi eski Maven modullariga o'xshaydi. Sizning vazifangiz to'g'ri muvozanatni topishdir. Bu, ayniqsa, yangi loyihalar uchun to'g'ri keladi. Yigirmata bulutga tayyor mikroservislardan boshlashdan ko'ra, sizni konservativ, "monolitik" yondashuvni qo'llashga va kamroq yaxshi Maven modullarini yaratishga hech narsa to'sqinlik qilmaydi.

Mikroservislar qo'shimcha murakkablikni keltirib chiqaradi

Shuni yodda tutingki, sizda qanchalik ko'p mikroservislar mavjud bo'lsa va sizda qanchalik kuchli DevOps bo'lsa (yo'q, bir nechta Ansible skriptlarini ishlatish yoki Heroku-ga joylashtirish hisobga olinmaydi!), keyinchalik jarayonda shunchalik ko'p muammolarga duch kelasiz. Ushbu qo'llanmaning Java mikroservislari haqidagi umumiy savollarga bag'ishlangan qismini oxirigacha o'qish ham juda zerikarli vazifadir. Ushbu infratuzilma muammolarining barchasiga yechimlarni amalga oshirish haqida yaxshilab o'ylab ko'ring va siz to'satdan endi biznes dasturlash (siz nima qilish uchun pul olasiz) haqida emas, balki ko'proq texnologiyaga qo'shimcha texnologiyani o'rnatish haqida ekanligini tushunasiz. Shiva Prasad Reddi o'z blogida buni mukammal tarzda jamlagan : "Jamoa vaqtining 70 foizini zamonaviy infratuzilma bilan kurashishga sarflagani va biznes mantig'ini bajarish uchun vaqtning atigi 30 foizi qolgani qanchalik dahshatli ekanligini bilmaysiz. ” Shiva Prasad Reddi

Java mikroservislarini yaratishga arziydimi?

Bu savolga javob berish uchun men ushbu maqolani juda bema'ni, Google intervyusiga o'xshash tizer bilan yakunlamoqchiman. Agar siz ushbu savolga javobni tajribangizdan bilsangiz, hatto bu mikroservislarga hech qanday aloqasi yo'qdek tuyulsa ham, siz mikroservislar yondashuviga tayyor bo'lishingiz mumkin.

Ssenariy

Tasavvur qiling-a, sizda eng kichik Hetzner ajratilgan serverida yakka o'zi ishlaydigan Java monolitingiz bor . Xuddi shu narsa ma'lumotlar bazasi serveriga ham tegishli, u xuddi shunday Hetzner mashinasida ham ishlaydi . Shuningdek, faraz qilaylik, sizning Java monolitingiz ish jarayonlarini, masalan, foydalanuvchini ro'yxatdan o'tkazishni boshqara oladi va siz har bir ish oqimi uchun yuzlab ma'lumotlar bazasi so'rovlarini yaratmayapsiz, balki yanada oqilona raqam (<10).

Savol

Java monolitingiz (ulanish pulingiz) ma'lumotlar bazasi serverida nechta ma'lumotlar bazasi ulanishini ochishi kerak? Nega bunday? Sizningcha, monolitingiz (taxminan) bir vaqtning o'zida qancha faol foydalanuvchiga ega bo'lishi mumkin?

Javob

Ushbu savollarga javobingizni sharhlar bo'limida qoldiring. Barcha javoblarni kutaman. Endi bir qarorga kel. Agar siz oxirigacha o'qisangiz, biz sizga juda minnatdormiz!