Java mikroservislari bo'yicha qo'llanma. 1-qism: Mikroservis asoslari va arxitekturasi

Ushbu qo'llanmada siz Java mikroservislari nima ekanligini, ularni qanday loyihalash va yaratishni bilib olasiz. Shuningdek, u Java mikroservis kutubxonalari va mikroservislardan foydalanishning maqsadga muvofiqligi haqidagi savollarni qamrab oladi. Java mikroservislarini tarjima qilish va moslashtirish : amaliy qo'llanma .

Java mikroservislari: asoslar

Mikroservislarni tushunish uchun avval ular nima emasligini aniqlashingiz kerak. Bu "monolit" emasmi - Java monolit: bu nima va uning afzalliklari yoki kamchiliklari qanday?

Java monolit nima?

Tasavvur qiling, siz bank yoki fintech startapida ishlaysiz. Siz foydalanuvchilarga yangi bank hisobini ochish uchun foydalanishi mumkin bo'lgan mobil ilovani taqdim etasiz. Java kodida bu nazoratchi sinfining mavjudligiga olib keladi. Soddalashtirilgan holda, u quyidagicha ko'rinadi:

@Controller
class BankController {

    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        riskCheck(form);
        openBankAccount(form);
        // etc..
    }
}

Sizga boshqaruvchi kerak:

1. Ro'yxatdan o'tish shakli tasdiqlandi.
2. Unga bank hisobini taqdim etish to‘g‘risida qaror qabul qilish uchun foydalanuvchi manzilining risklari tekshirildi.
3. Bank hisobini ochdi.

Sinf BankControllerboshqa manbalaringiz bilan birga bank.jar yoki bank.war fayliga joylashtiriladi - bu eski yaxshi monolit bo'lib, bankingizni boshqarish uchun zarur bo'lgan barcha kodlarni o'z ichiga oladi. Taxminiy hisob-kitoblarga ko'ra, .jar (yoki .war) faylining boshlang'ich hajmi 1 dan 100 MB gacha bo'ladi. Endi siz shunchaki serveringizda .jar faylini ishga tushirishingiz mumkin... va bu Java ilovangizni joylashtirish uchun qilishingiz kerak. Rasm, yuqori chap to'rtburchak: mono(litik) bank java -jar bank.jar (cp .war/.ear ilova serveriga) joylashtirilishi. To'g'ri to'rtburchak: brauzerni oching.

Java monolitlari bilan qanday muammo bor?

Java monolitlarida hech qanday yomon narsa yo'q. Biroq, tajriba shuni ko'rsatadiki, agar sizning loyihangizda:

• Ko'plab dasturchilar/jamoalar/maslahatchilar ishlaydi...
• ... juda noaniq talablarga ega bo'lgan mijozlar bosimi ostida bir xil monolit ustida ...
• bir necha yil ichida ...

... keyin bu holda sizning kichik bank.jar faylingiz faqat ulkan gigabayt kodga aylanadi, bu esa joylashtirish u yoqda tursin, yaqinlashish ham qo'rqinchli.

Java monolitining hajmini qanday kamaytirish mumkin?

Tabiiy savol tug'iladi: monolitni qanday qilib kichikroq qilish kerak? Hozirda bank.jar bitta JVMda, bitta serverda bitta jarayonda ishlamoqda. Ko'p emas, kam emas. Va hozir xayolga mantiqiy fikr kelishi mumkin: “Ammo riskni tekshirish xizmatidan mening kompaniyamning boshqa bo'limlari ham foydalanishi mumkin! Bu mening monolit bank ilovam bilan bevosita bog'liq emas! Ehtimol, uni monolitdan kesib, alohida mahsulot sifatida joylashtirish kerakmi? Ya'ni, texnik jihatdan aytganda, uni alohida Java jarayoni sifatida boshqaradi.

Java mikroservisi nima?

Amalda, bu ibora endi usul chaqiruvi riskCheck()BankController'dan amalga oshirilmasligini anglatadi: bu usul yoki fasol komponenti barcha yordamchi sinflari bilan o'zining Maven yoki Gradle loyihasiga ko'chiriladi. Shuningdek, u bank monolitidan mustaqil ravishda joylashtiriladi va versiya nazorati ostida joylashtiriladi. Biroq, bu butun ekstraksiya jarayoni sizning yangi RiskCheck modulingizni o'z-o'zidan mikroservisga aylantirmaydi, chunki mikroservisning ta'rifi sharhlash uchun ochiq. Bu jamoalar va kompaniyalar ichida tez-tez muhokamalarga olib keladi.

• Loyihada 5-7 sinf mikromi yoki nima?
• 100 yoki 1000 sinf... hali ham mikromi?
• Mikroservis odatda sinflar soniga bog'liqmi yoki yo'qmi?

Keling, nazariy mulohazalarni ortda qoldirib, pragmatik mulohazalarga amal qilaylik va shunday qilaylik:

1. Hajmi yoki domen chegaralaridan qat'i nazar, barcha alohida joylashtirilgan xizmatlarni mikroservislar deb ataylik.
2. Keling, xizmatlararo aloqani qanday tashkil qilish haqida o'ylab ko'raylik. Bizning mikroservislarimiz bir-biri bilan aloqa qilish usullariga muhtoj.

Xulosa qilib aytadigan bo'lsak: ilgari sizda bitta JVM jarayoni bor edi, bu bankni boshqarish uchun mustahkam monolit. Endi sizda bank monolit JVM jarayoni va o'z JVM jarayonida ishlaydigan alohida RiskCheck mikroservisi mavjud. Va endi, xavflarni tekshirish uchun sizning monolitingiz ushbu mikroservisga qo'ng'iroq qilishi kerak. Buni qanday qilish kerak?

Java mikroservislari o'rtasida aloqani qanday o'rnatish mumkin?

Umuman olganda va umuman, ikkita variant mavjud - sinxron va asinxron aloqa.

Sinxron aloqa: (HTTP)/REST

Odatda, mikroservislar o'rtasidagi sinxronlashtirilgan aloqa HTTP va REST-ga o'xshash XML yoki JSON-ni qaytaradigan xizmatlar orqali amalga oshiriladi. Albatta, boshqa variantlar ham bo'lishi mumkin - kamida oling Google Protocol Buffers . Agar sizga zudlik bilan javob kerak bo'lsa, REST aloqasidan foydalanish yaxshiroqdir. Bizning misolimizda aynan shunday qilish kerak, chunki hisob ochishdan oldin xavfni tekshirish talab qilinadi. Agar xavfni tekshirish bo'lmasa, hisob yo'q. Biz quyidagi vositalarni " Java REST sinxron qo'ng'iroqlari uchun eng yaxshi kutubxonalar " bo'limida muhokama qilamiz .

Xabarlar - asinxron aloqa

Asinxron mikroservis aloqasi odatda JMS ilovasi bilan xabar almashish va/yoki AMQP kabi protokol yordamida amalga oshiriladi . Biz bu erda bir sababga ko'ra "odatda" deb yozdik: aytaylik, elektron pochta / SMTP integratsiyalari sonini kam baholab bo'lmaydi. Undan darhol javob kerak bo'lmaganda foydalaning. Masalan, foydalanuvchi "hozir sotib olish" tugmasini bosadi va siz o'z navbatida hisob-fakturani yaratmoqchisiz. Bu jarayon, albatta, foydalanuvchining xarid so'rovi-javob siklida sodir bo'lmasligi kerak. Quyida asenkron Java xabar almashish uchun qaysi vositalar eng yaxshi ekanligini tasvirlab beramiz .

Misol: Java-da REST API chaqiruvi

Faraz qilaylik, biz sinxron mikroservis aloqasini tanlaymiz. Bunday holda, past darajadagi Java kodimiz (yuqorida taqdim etganimiz) shunga o'xshash ko'rinadi. (past daraja deganda biz mikroservis aloqasi uchun odatda sizni haqiqiy HTTP qo'ng'iroqlaridan ajratib turuvchi mijozlar kutubxonalari yaratilganligini nazarda tutamiz).

@Controller
class BankController {

    @Autowired
    private HttpClient httpClient;

    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        httpClient.send(riskRequest, responseHandler());
        setupAccount(form);
        // etc..
    }
}

Kodga asoslanib, biz endi ikkita Java (mikro) xizmatlarini, Bank va RiskCheckni o'rnatishimiz kerakligi aniq bo'ladi. Natijada bizda ikkita JVM jarayoni ishlaydi. Java mikroservislari loyihasini ishlab chiqish uchun kerak bo'lgan hamma narsa: bitta monolit o'rniga kichikroq qismlarni (.jar yoki .war fayllari) yarating va joylashtiring. Savolga javob noaniq bo'lib qolmoqda: monolitni mikroservislarga qanday qilib kesishimiz kerak? Bu qismlar qanchalik kichik bo'lishi kerak, to'g'ri o'lchamni qanday aniqlash mumkin? Keling, tekshiramiz.

Java mikroservislar arxitekturasi

Amalda kompaniyalar mikroservis loyihalarini turli yo'llar bilan ishlab chiqadilar. Yondashuv siz mavjud monolitni mikroservislar loyihasiga aylantirmoqchimisiz yoki loyihani noldan boshlashingizga bog'liq.

Monolitdan mikroservislargacha

Eng mantiqiy g'oyalardan biri mavjud monolitdan mikroservislarni olishdir. E'tibor bering, bu erda "mikro" prefiksi aslida olingan xizmatlar haqiqatan ham kichik bo'lishini anglatmaydi; bu har doim ham shunday emas. Keling, nazariy asosni ko'rib chiqaylik.

G'oya: monolitni mikroservislarga ajratish

Mikroservis yondashuvi eski loyihalarga qo'llanilishi mumkin. Va shuning uchun:

1. Ko'pincha bunday loyihalarni saqlab qolish/o'zgartirish/kengaytirish qiyin.
2. Ishlab chiquvchilardan tortib menejmentgacha hamma soddalashtirishni xohlaydi.
3. Sizda (nisbatan) aniq domen chegaralari bor, ya'ni siz dasturiy ta'minotingiz nima qilishi kerakligini aniq bilasiz.

Bizning misolimizga qaytadigan bo'lsak, bu sizning Java banking monolitiga qarashingiz va uni domen chegaralari bo'ylab sindirishga harakat qilishingiz mumkinligini anglatadi.

• Shunday qilib, foydalanuvchi ma'lumotlarini (masalan, ismlar, manzillar, telefon raqamlari) qayta ishlashni "Hisobni boshqarish" alohida mikroservisga ajratish oqilona bo'lar edi.
• Yoki foydalanuvchining xavf darajasini tekshiradigan va ko'plab boshqa loyihalar yoki hatto kompaniyaning bo'limlari tomonidan ishlatilishi mumkin bo'lgan yuqorida aytib o'tilgan "Xavflarni tekshirish moduli".
• Yoki hisob-fakturalarni PDF formatida yoki pochta orqali yuboradigan hisob-faktura moduli.

G'oyani amalga oshirish: boshqa birovga ruxsat bering

Yuqorida tavsiflangan yondashuv qog'ozda va UML-ga o'xshash diagrammalarda ajoyib ko'rinadi. Biroq, hamma narsa juda oddiy emas. Uni amaliy amalga oshirish jiddiy texnik tayyorgarlikni talab qiladi: monolitdan nimani olish yaxshi bo'lishini tushunishimiz va qazib olish jarayonining o'zi o'rtasidagi tafovut juda katta. Aksariyat korporativ loyihalar ishlab chiquvchilar, aytaylik, Hibernate-ning 7 yillik versiyasini yangisiga yangilashdan qo'rqadigan bosqichga etadi. U bilan birga kutubxonalar ham yangilanadi, ammo biror narsani buzish xavfi mavjud. Shunday qilib, o'sha ishlab chiquvchilar endi ma'lumotlar bazasi tranzaksiyalari chegaralari aniq bo'lmagan qadimgi eski kodni qazib olishlari va aniq belgilangan mikroservislarni olishlari kerakmi? Ko'pincha, bu muammo juda murakkab va doskada yoki arxitektura yig'ilishlarida "hal qilish" mumkin emas. Twitter dasturchisi @simonbrowndan iqtibos keltirish uchun: Men buni qayta-qayta aytaman... agar odamlar monolitlarni to'g'ri qura olmasalar, mikroservislar yordam bermaydi. Saymon Braun

Mikroservis arxitekturasiga asoslangan noldan loyiha

Yangi Java loyihalarida oldingi qismdagi uchta raqamlangan nuqta biroz boshqacha ko'rinadi:

1. Siz toza varaqdan boshlaysiz, shuning uchun parvarish qilish uchun "bagaj" yo'q.
2. Ishlab chiquvchilar kelajakda oddiy narsalarni saqlashni xohlashadi.
3. Muammo: Sizda domen chegaralarining yanada noaniqroq tasviri bor: siz dasturiy ta'minotingiz aslida nima qilishi kerakligini bilmayapsiz (maslahat: agile;))

Bu kompaniyalarning Java mikroservislari bilan yangi loyihalarni sinab ko'rishiga olib keladi.

Texnik mikroservis arxitekturasi

Birinchi nuqta ishlab chiquvchilar uchun eng aniq bo'lib tuyuladi, ammo uni qat'iyan rad etadiganlar ham bor. Hadi Haririy IntelliJ-da "Extract Microservice" refaktorini tavsiya qiladi. Va quyidagi misol juda soddalashtirilgan bo'lsa-da, real loyihalarda kuzatilgan amalga oshirish, afsuski, undan uzoqqa bormaydi. Mikroservislardan oldin

@Service
class UserService {

    public void register(User user) {
        String email = user.getEmail();
        String username =  email.substring(0, email.indexOf("@"));
        // ...
    }
}

Substring Java mikroxizmati bilan

@Service
class UserService {

    @Autowired
    private HttpClient client;

    public void register(User user) {
        String email = user.getEmail();
        //теперь вызываем substring microservice via http
        String username =  httpClient.send(substringRequest(email), responseHandler());
        // ...
    }
}

Shunday qilib, siz hech qanday aniq sababsiz Java usuli chaqiruvini HTTP qo'ng'irog'iga o'rayapsiz. Buning sabablaridan biri bu: tajriba etishmasligi va Java mikroservislari yondashuvini majburlashga urinish. Tavsiya: buni qilmang.

Ish oqimiga yo'naltirilgan mikroservis arxitekturasi

Keyingi keng tarqalgan yondashuv Java mikroservislarini ish oqimiga asoslangan modullarga bo'lishdir. Haqiqiy hayot misoli: Germaniyada (davlat) shifokorga borganingizda, u tashrifingizni tibbiy CRM tizimida qayd etishi kerak. Sug'urta to'lovini olish uchun u sizning davolanishingiz (va boshqa bemorlarni davolash) haqidagi ma'lumotlarni XML orqali vositachiga yuboradi. Broker ushbu XML faylni ko'rib chiqadi va (soddalashtirilgan):

1. To'g'ri XML fayli olinganligini tekshiradi.
2. Bu muolajalarning asosliligini tekshiradi: aytaylik, ginekologdan bir kunda uchta tish tozalash protsedurasini olgan bir yoshli bola biroz shubhali ko'rinadi.
3. XMLni boshqa byurokratik ma'lumotlar bilan birlashtiradi.
4. To'lovlarni boshlash uchun XML faylni sug'urta kompaniyasiga yuboradi.
5. Va u natijani shifokorga yuboradi va unga "muvaffaqiyatli" yoki "iltimos, mantiqiy bo'lganda, ushbu yozuvni qayta yuboring" degan xabarni beradi.

Eslatma. Ushbu misolda, mikroservislar o'rtasidagi aloqa rol o'ynamaydi, lekin xabarlar brokeri (masalan, RabbitMQ) tomonidan asinxron tarzda amalga oshirilishi mumkin, chunki shifokor baribir darhol javob olmaydi. Shunga qaramay, bu qog'ozda ajoyib ko'rinadi, ammo tabiiy savollar tug'iladi:

• Bitta XML faylini qayta ishlash uchun oltita dasturni joylashtirish kerakmi?
• Ushbu mikroservislar haqiqatan ham bir-biridan mustaqilmi? Ular bir-biridan mustaqil ravishda joylashtirilishi mumkinmi? Turli versiyalar va API sxemalari bilanmi?
• Tasdiqlash mikroxizmati ishlamasa, ishonchlilik mikroxizmati nima qiladi? Tizim hali ham ishlayaptimi?
• Ushbu mikroservislar bir xil ma'lumotlar bazasini baham ko'radimi (ular ma'lumotlar bazasi jadvallarida ba'zi umumiy ma'lumotlarga muhtoj), yoki ularning har biri o'ziga xosmi?
• … va boshqalar.

Qizig'i shundaki, yuqoridagi diagramma oddiyroq ko'rinadi, chunki endi har bir xizmat o'zining aniq, aniq belgilangan maqsadiga ega. Ilgari u qo'rqinchli monolitga o'xshardi: siz ushbu diagrammalarning soddaligi haqida bahslashishingiz mumkin bo'lsa-da, endi siz ushbu qo'shimcha operatsion muammolarni hal qilishingiz kerak.

• Siz faqat bitta dasturni emas, balki kamida oltita dasturni joylashtirishingiz kerak.
• Mikroservislar arxitekturasiga qanchalik borishni xohlayotganingizga qarab, bir nechta ma'lumotlar bazalarini joylashtirishingiz kerak bo'lishi mumkin.
• Har bir tizim onlayn va to'g'ri ishlashiga ishonch hosil qilishingiz kerak.
• Mikroservislar orasidagi qo'ng'iroqlaringiz haqiqatan ham bardoshli ekanligiga ishonch hosil qilishingiz kerak (qarang: Java mikroxizmatini qanday qilib barqaror qilish mumkin?).
• Va bu o'rnatish nazarda tutadigan boshqa hamma narsa - mahalliy rivojlanish sozlamalaridan tortib integratsiya testlarigacha.

Shunday qilib, tavsiya quyidagicha bo'ladi:

• Agar siz Netflix bo'lmasangiz (ehtimol, siz Netflix emassiz)...
• Rivojlanish muhitini ochadigan va u 5 soniya ichida osongina tiklanadigan ishlab chiqarish ma'lumotlar bazasini tashlab yuboradigan tartibsizlik maymunini chaqiradigan juda kuchli ish qobiliyatiga ega bo'lmasangiz.
• yoki siz o'zingizni @monzo kabi his qilasiz va 1500 ta mikroservisni sinab ko'rishga tayyormisiz.

→ Buni qilmang. Va endi u kamroq giperbolik. Domen chegaralari bo'ylab mikroservislarni modellashtirishga urinish juda oqilona ko'rinadi. Ammo bu bitta ish jarayonini olib, uni kichik qismlarga bo'lish kerak degani emas (XML qabul qilish, XMLni tasdiqlash, XMLni yo'naltirish). Shunday qilib, Java mikroservislari bilan yangi loyihani boshlaganingizda va domen chegaralari hali ham noaniq bo'lsa, mikroservislaringiz hajmini past darajada saqlashga harakat qiling. Keyinchalik har doim qo'shimcha modullar qo'shishingiz mumkin. Yangi infratuzilmangizni qo‘llab-quvvatlash uchun jamoa/kompaniya/bo‘limda ilg‘or DevOps-ga ega ekanligingizga ishonch hosil qiling.

Poliglot yoki jamoaga yo'naltirilgan mikroservis arxitekturasi

Mikroservislarni ishlab chiqishda uchinchi, deyarli libertar yondashuv mavjud: jamoalarga yoki hatto shaxslarga istalgan sonli tillar yoki mikroservislardan foydalangan holda foydalanuvchi hikoyalarini amalga oshirishga ruxsat berish (marketologlar bu yondashuvni "poliglot dasturlash" deb atashadi). Shunday qilib, yuqorida tavsiflangan XML tekshirish xizmati Java-da yozilishi mumkin, tekshirish mikroxizmati esa bir vaqtning o'zida Haskell-da yozilishi mumkin (uni matematik jihatdan ishonchli qilish uchun). Sug'urtani yo'naltirish mikroxizmati uchun siz Erlang-dan foydalanishingiz mumkin (chunki u haqiqatan ham miqyoslash kerak;)). Ishlab chiquvchi nuqtai nazaridan qiziqarli bo'lib tuyulishi mumkin bo'lgan narsa (izolyatsiya qilingan muhitda mukammal tilingiz bilan mukammal tizimni ishlab chiqish) aslida hech qachon tashkilot xohlagan narsa emas: gomogenlashtirish va standartlashtirish. Bu nisbatan standartlashtirilgan tillar, kutubxonalar va vositalar to‘plamini bildiradi, shunda siz yashil yaylovlarga o‘tsangiz, kelajakda boshqa ishlab chiquvchilar Haskell mikroservisingizni qo‘llab-quvvatlashda davom etishlari mumkin. Tarix shuni ko'rsatadiki, standartlashtirish odatda juda chuqur singib ketgan. Misol uchun, yirik Fortune 500 kompaniyalari ishlab chiquvchilari ba'zan hatto Spring-dan foydalanishga ruxsat berilmagan, chunki u "kompaniyaning texnologik yo'l xaritasining bir qismi emas edi". Biroq, poliglot yondashuvga to'liq o'tish deyarli bir xil narsa, bir xil tanganing boshqa tomoni. Tavsiya: Agar siz poliglot dasturlashdan foydalanmoqchi bo'lsangiz, bir xil dasturlash tili ekotizimida kamroq xilma-xillikni sinab ko'ring. Shunday qilib, Java va, aytaylik, Haskelldan ko'ra, Kotlin va Java-dan (har ikkala til ham JVM-ga asoslangan va bir-biriga 100% mos keladi) birgalikda foydalanish yaxshiroqdir. Keyingi qismda siz Java mikroservislarini joylashtirish va sinovdan o'tkazish haqida bilib olasiz.