Java Microservices үчүн колдонмо. 1-бөлүк: Микросервистердин негиздери жана архитектурасы

Бул окуу куралында сиз Java микросервистери эмне экенин, аларды кантип долбоорлоону жана түзүүнү үйрөнөсүз. Ал ошондой эле Java микросервис китепканалары жана микросервистерди колдонуунун максатка ылайыктуулугу жөнүндө суроолорду камтыйт. Java микросервистерин которуу жана адаптациялоо : Практикалык колдонмо .

Java микросервистери: негиздери

Микросервистерди түшүнүү үчүн, адегенде алар эмне эмес экенин аныкташыңыз керек. Бул "монолит" эмеспи - Java монолит: бул эмне жана анын кандай артыкчылыктары же кемчorктери бар?

Java монолит деген эмне?

Элестетиңиз, сиз банкта же финтех стартапында иштейсиз. Сиз колдонуучуларга жаңы банк эсебин ачуу үчүн колдоно турган мобилдик тиркемени бересиз. Java codeунда бул контроллер классынын болушуна алып келет. Жөнөкөйлөштүрүлгөн, ал төмөнкүдөй көрүнөт:

@Controller
class BankController {

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

Сизге контроллер керек:

1. Каттоо формасын тастыктады.
2. Колдонуучунун дарегинин тобокелдиктерин текшерип, ага банк эсебин берүүнү чечкен.
3. Банк эсебин ачты.

Класс BankControllerсиздин калган булактарыңыз менен бирге жайгаштыруу үчүн bank.jar же bank.war файлына топтолот - бул банкыңызды иштетүү үчүн зарыл болгон бардык codeду камтыган жакшы эски монолит. Болжолдуу баа катары, .jar (же .war) файлынын баштапкы өлчөмү 1ден 100 МБга чейин өзгөрөт. Эми сиз жөн гана serverиңизде .jar файлын иштетсеңиз болот... жана Java тиркемеңизди жайгаштыруу үчүн ушул гана керек. Сүрөт, жогорку сол тик бурчтук: моно(литтик) банк java -jar bank.jar (cp .war/.ear appserverге) жайгаштыруу. Оң тик бурчтук: браузерди ачуу.

Java монолиттеринин көйгөйү эмнеде?

Java монолиттеринде эч кандай ката жок. Бирок, тажрыйба көрсөткөндөй, эгерде сиздин долбооруңузда:

• Көптөгөн программисттер/командалар/консультанттар иштейт...
• ... өтө бүдөмүк талаптар менен кардарлардын кысымы астында ошол эле монолиттин үстүнөн ...
• бир эки жылдын ичинде ...

... анда бул учурда сиздин кичинекей bank.jar файлыңыз эбегейсиз чоң гигаbyte codeго айланат, аны жайылтуу мындай турсун, жакындоо да коркунучтуу.

Java монолитинин көлөмүн кантип азайтуу керек?

Табигый суроо туулат: монолитти кантип кичирейтүү керек? Учурда bank.jar бир JVMде, бир serverде бир процессте иштеп жатат. Артык эмес, кем эмес. Мына азыр логикалык ой келип калышы мүмкүн: «Бирок тобокелдикти текшерүү кызматын менин компаниямдын башка бөлүмдөрү колдоно алат! Бул менин монолиттүү банктык тиркемеме түздөн-түз байланыштуу эмес! Балким, аны монолиттен кесип, өзүнчө продукт катары жайылтуу керектир? Башкача айтканда, техникалык жактан айтканда, аны өзүнчө Java процесси катары иштетүү.

Java микросервиси деген эмне?

Иш жүзүндө, бул сөз айкашы, эми riskCheck()BankControllerден метод чакырыгы жасалbyte дегенди билдирет: бул метод же фасоль компоненти анын бардык көмөкчү класстары менен өзүнүн Maven же Gradle долбооруна жылдырылат. Ал ошондой эле банктык монолитке көз карандысыз түрдө жайгаштырылат жана versionнын көзөмөлүндө болот. Бирок, бул бүт экстракция процесси сиздин жаңы RiskCheck модулуңузду микросервиске айландырbyte, анткени микросервистин аныктамасы чечмелөөгө ачык. Бул командалардын жана компаниялардын ичинде тез-тез талкууларга алып келет.

• Долбоордо 5-7 класстар микро же эмне?
• 100 же 1000 класс... дагы эле микро?
• Микросервис жалпысынан класстардын санына байланыштуубу же жокпу?

Келгиле, теориялык ой жүгүртүүнү артка калтырып, анын ордуна прагматикалык ойлорду карманып, муну жасайлы:

1. Өлчөмүнө жана доменинин чектерине карабастан, өзүнчө жайгаштырылган бардык кызматтарды микросервис деп атайлы.
2. Кызматтар аралык байланышты кантип уюштуруу керектиги жөнүндө ойлонуп көрөлү. Биздин микросервистерге бири-бири менен байланышуу жолдору керек.

Ошентип, кыскача айтканда: мурда сизде бир JVM процесси болгон, банкты башкаруу үчүн катуу монолит. Эми сизде банктык монолиттүү JVM процесси жана өзүнүн JVM процессинде иштеген өзүнчө RiskCheck микросервиси бар. Ал эми азыр, тобокелдиктерди текшерүү үчүн, сиздин монолит бул микросервисти чакырышы керек. Муну кантип кылуу керек?

Java микросервистеринин ортосунда байланышты кантип орнотуу керек?

Жалпысынан жана жалпысынан эки вариант бар - синхрондук жана асинхрондук байланыш.

Синхрондук байланыш: (HTTP)/REST

Адатта, микросервистердин ортосунда синхрондуу байланыш XML же JSON кайтарып берген HTTP жана REST сыяктуу кызматтар аркылуу ишке ашат. Албетте, башка варианттар болушу мүмкүн - жок дегенде Google Protocol Buffers алыңыз . Эгер сизге дароо жооп керек болсо, REST байланышын колдонгонуңуз жакшы. Биздин мисалда бул так аткарылышы керек, анткени эсепти ачуудан мурун тобокелдикти текшерүү талап кылынат. Эгерде тобокелдикти текшерүү жок болсо, анда эсеп жок. Биз төмөндөгү куралдарды талкуулайбыз " Кайсы китепканалар синхрондуу Java REST чалуулары үчүн эң жакшы ".

Кабарлашуу - Асинхрондук байланыш

Асинхрондук микросервис байланышы, адатта, JMS ишке ашыруу менен билдирүүлөрдү алмашуу жана/же AMQP сыяктуу протоколду колдонуу менен ишке ашат . Биз бул жерде бир себеп менен "көбүнчө" деп жазганбыз: электрондук почта/SMTP интеграциясынын санын бааланбай коюуга болбойт дейли. Аны дароо жооп талап кылбаганда колдонуңуз. Мисалы, колдонуучу "азыр сатып алуу" баскычын чыкылдатса, сиз өз кезегинде эсеп-дүмүрчөк түзгүңүз келет. Бул процесс, албетте, колдонуучунун сатып алуу суроо-жооп циклинин ичинде болбошу керек. Төмөндө биз асинхрондук Java билдирүүлөрү үчүн кайсы куралдар эң жакшы экенин сүрөттөп беребиз .

Мисал: Java тorндеги REST API чалуу

Келгиле, биз синхрондуу микросервис байланышын тандайлы. Бул учурда, биздин Java codeубуз (жогоруда көрсөтүлгөн) төмөнкү деңгээлдегидей көрүнөт. (төмөн деңгээл дегенде биз микросервис байланышы үчүн, адатта, сизди чыныгы HTTP чалууларынан абстракциялаган кардар китепканалары түзүлөт дегенди билдирет).

@Controller
class BankController {

    @Autowired
    private HttpClient httpClient;

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

Коддун негизинде, биз азыр эки Java (микро) кызматын, Банк жана RiskCheckти жайылтышыбыз керек экени айкын болот. Натыйжада бизде эки JVM процесси иштейт. Java микросервис долбоорун иштеп чыгуу үчүн ушул гана керек: бир монолиттүү эмес, кичинекей бөлүктөрдү (.jar же .war файлдары) түзүп, жайгаштырыңыз. Суроонун жообу белгисиз бойдон калууда: монолитти микросервистерге кантип кесишибиз керек? Бул бөлүктөр канчалык кичинекей болушу керек, туура өлчөмүн кантип аныктоого болот? текшерип көрөлү.

Java микросервистеринин архитектурасы

Иш жүзүндө компаниялар микросервис долбоорлорун ар кандай жолдор менен иштеп чыгышат. Бул ыкма сиз учурдагы монолитти микросервис долбооруна айландырууга аракет кылып жатасызбы же долбоорду нөлдөн баштап баштаганыңыздан көз каранды.

Монолиттен микросервистерге чейин

Эң логикалык идеялардын бири - учурдагы монолиттен микросервистерди алуу. Бул жердеги "микро" префикси чындыгында алынган кызматтар чындап эле кичинекей болот дегенди билдирбейт; бул сөзсүз түрдө андай эмес. Келгиле, теориялык негиздерди карап көрөлү.

Идея: монолитти микросервистерге бөлүү

Микросервис ыкмасы эски долбоорлорго колдонулушу мүмкүн. Ошондон улам:

1. Көбүнчө мындай долбоорлорду сактоо/өзгөртүү/кеңейтүү кыйынга турат.
2. Иштеп чыгуучулардан баштап менеджментке чейин бардыгы жөнөкөйлөтүүнү каалайт.
3. Сизде (салыштырмалуу) так домен чектери бар, демек сиз программалык камсыздооңуз эмне кылышы керектигин так билесиз.

Биздин мисалга кайрылсак, бул сиз Java банкингдин монолитиңизди карап, аны домен чек аралары аркылуу бузууга аракет кыла аласыз дегенди билдирет.

• Ошентип, колдонуучунун маалыматтарын иштетүүнү (мисалы, аттары, даректери, телефон номерлери) өзүнчө микросервиске "Эсепти башкаруу" деп бөлүү жөндүү болмок.
• Же жогоруда айтылган "Тобокелдиктерди текшергич модулу", ал колдонуучунун тобокелдик деңгээлин текшерет жана көптөгөн башка долбоорлор же компаниянын бөлүмдөрү тарабынан колдонулушу мүмкүн.
• Же PDF форматында же почта аркылуу эсеп-фактураларды жөнөтүүчү эсеп-дүмүрчөк модулу.

Идеяны ишке ашыруу: аны башка бирөө жасасын

Жогоруда сүрөттөлгөн ыкма кагазда жана UML сымал диаграммада сонун көрүнөт. Бирок, баары ушунчалык жөнөкөй эмес. Аны практикалык ишке ашыруу олуттуу техникалык даярдыкты талап кылат: монолиттен эмнени алуу жакшы болорун түшүнүү менен казып алуу процессинин ортосундагы ажырым абдан чоң. Көпчүлүк ишканалардын долбоорлору иштеп чыгуучулар, айталы, Hibernate режиминин 7 жылдык versionсын жаңысына жаңыртуудан коркушат. Аны менен бирге китепканалар да жаңыланат, бирок бир нерсени бузуп алуу коркунучу бар. Ошентип, ошол эле иштеп чыгуучулар эми базанын транзакциясынын так чектери менен байыркы мурас codeду казып, так аныкталган микросервистерди чыгарышы керекпи? Көбүнчө, бул маселе өтө татаал жана аны тактада же архитектуралык жолугушууларда "чечүүгө" болбойт. Twitter иштеп чыгуучусу @simonbrown цитата кылуу үчүн: Мен муну кайра-кайра айтам... эгерде адамдар монолиттерди туура кура албаса, микросервистер жардам бербейт. Саймон Браун

Микросервис архитектурасына негизделген нөлдөн баштап долбоор

Жаңы Java долбоорлорунда мурунку бөлүктөгү үч сандуу пункттар бир аз башкача көрүнөт:

1. Сиз таза барактан баштайсыз, андыктан сактай турган "жүк" жок.
2. Иштеп чыгуучулар келечекте жөнөкөй нерселерди сактагысы келет.
3. Көйгөй: Сизде домен чектеринин бир топ бүдөмүк сүрөтү бар: сиз программалык камсыздооңуз эмне кылышы керек экенин билбейсиз (кеңеш: agile;))

Бул Java микросервистери менен жаңы долбоорлорду сынап жаткан компанияларга алып келет.

Техникалык микросервис архитектурасы

Биринчи пункт иштеп чыгуучулар үчүн эң айкын көрүнөт, бирок аны катуу четке Howкандар да бар. Хади Харири IntelliJде "Extract Microservice" рефакторингди сунуштайт. Ал эми төмөнкү мисал абдан жөнөкөйлөштүрүлгөн болсо да, реалдуу долбоорлордо байкалган ишке ашыруу, тилекке каршы, андан алыс эмес. Микросервистерге чейин

@Service
class UserService {

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

Substring Java микросервиси менен

@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());
        // ...
    }
}

Ошентип, сиз эч кандай айкын себепсиз эле Java ыкмасынын чалуусун HTTP чалууга ороп жатасыз. Мунун бир себеби, бул: тажрыйбанын жетишсиздиги жана Java микросервистеринин мамилесин мажбурлоого аракет кылуу. Сунуш: Муну кылбаңыз.

Иш процессине багытталган микросервис архитектурасы

Кийинки жалпы ыкма Java микросервистерин иштөө процессине негизделген модулдарга бөлүү болуп саналат. Чыныгы турмуштук мисал: Германияда (коомдук) дарыгерге барганыңызда, ал өзүнүн медициналык CRM тутумуна сиздин иш сапарыңызды жазышы керек. Камсыздандыруудан төлөм алуу үчүн, ал XML аркылуу ортомчуга сиздин дарылооңуз (жана башка бейтаптарды дарылоо) жөнүндө маалыматтарды жөнөтөт. Брокер бул XML файлын карайт жана (жөнөкөйлөштүрүлгөн):

1. Туура XML файлы алынганын текшерет.
2. Ал proceduresалардын жүйөлүүлүгүн текшерет: айталы, гинекологдон бир күндө үч жолу тиш тазалоо proceduresасын алган бир жаштагы бала бир аз шектүү көрүнөт.
3. XMLди башка бюрократиялык маалыматтар менен айкалыштырат.
4. Төлөмдөрдү баштоо үчүн XML файлын камсыздандыруу компаниясына жөнөтөт.
5. Жана ал натыйжаны дарыгерге жөнөтүп, ага "ийгorк" же "бул жазууну мааниси келгенде кайра жөнөтүңүз" деген билдирүүнү берет.

Эскертүү. Бул мисалда микросервистердин ортосундагы байланыш эч кандай роль ойнобойт, бирок билдирүү брокери (мисалы, RabbitMQ) тарабынан асинхрондуу түрдө аткарылышы мүмкүн, анткени дарыгер баары бир дароо пикир ала алbyte. Дагы, бул кагазда сонун көрүнөт, бирок табигый суроолор пайда болот:

• Бир XML файлын иштетүү үчүн алты тиркемени жайылтуу керекпи?
• Бул микросервистер бири-биринен көз карандысызбы? Аларды бири-биринен көз карандысыз жайгаштырса болобу? Ар кандай versionлары жана API схемалары мененби?
• Текшерүү микросервиси иштебесе, маалыматтын ишенимдүүлүгүнүн микросервиси эмне кылат? Система дагы эле иштеп жатабы?
• Бул микросервистер бир эле маалымат базасын бөлүшөбү (алар, албетте, МБ tableларында кээ бир жалпы маалыматтарга муктаж), же алардын ар бири өз алдынчабы?
• ... жана дагы көп нерселер.

Кызыктуусу, жогорудагы диаграмма жөнөкөй көрүнөт, анткени азыр ар бир кызматтын өзүнүн так, так аныкталган максаты бар. Мурда бул коркунучтуу монолит сыяктуу көрүнчү: Сиз бул диаграммалардын жөнөкөйлүгү жөнүндө талаша аласыз, бирок сиз азыр бул кошумча оперативдүү көйгөйлөрдү чечишиңиз керек.

• Сиз жөн гана бир тиркемени эмес, кеминде алты тиркемени колдонушуңуз керек.
• Микросервистердин архитектурасына канчалык деңгээлде киргиңиз келгениңизге жараша, сизге бир нече маалымат базаларын жайгаштыруу керек болушу мүмкүн.
• Сиз ар бир системанын онлайн режиминде жана туура иштеп жатканын текшеришиңиз керек.
• Микросервистердин ортосундагы чалууларыңыз чындап ийкемдүү экенине ынанышыңыз керек (караңыз: Java микросервисин кантип ийкемдүү кылуу керек?).
• Бул жөндөөнүн бардыгы - жергorктүү өнүгүү орнотууларынан баштап интеграциялык тестирлөөгө чейин.

Ошентип, сунуш болот:

• Эгер сиз Netflix эмес болсоңуз (мүмкүнчүлүктөр, сиз Netflix эмессиз)...
• Өнүктүрүү чөйрөсүн ачкан жана ал 5 секунданын ичинде оңой калыбына келтирилген өндүрүштүк маалымат базаңызды ыргытып жиберген башаламандык маймылын чакырган жерде супер күчтүү иштөө жөндөмүңүз болбосо.
• же сиз өзүңүздү @monzo сыяктуу сезесиз жана 1500 микросервисти сынап көрүүгө даярсыз.

→ Муну кылба. Ал эми азыр ал азыраак гиперболалык. Домен чектеринде микросервистерди моделдөө аракети абдан акылга сыярлык көрүнөт. Бирок бул бир иш агымын алып, аны кичинекей бөлүктөргө бөлүү керек дегенди билдирбейт (XML алуу, XMLди ырастоо, XMLди алдыга жылдыруу). Демек, сиз Java микросервистери менен жаңы долбоорду баштаганда жана домендин чек аралары дагы эле бүдөмүк болсо, микросервисиңиздин көлөмүн төмөн деңгээлде кармоого аракет кылыңыз. Сиз ар дайым кийинчерээк көбүрөөк модулдарды кошо аласыз. Жаңы инфраструктураңызды колдоо үчүн командада/компанияда/бөлүмдө өркүндөтүлгөн DevOps бар экенин тактаңыз.

Полиглот же командага багытталган микросервис архитектурасы

Микросервистерди өнүктүрүүнүн үчүнчү, дээрлик либертариандык мамилеси бар: командаларга же жеке адамдарга ар кандай тилдерди же микросервистерди колдонуу менен колдонуучу окуяларын ишке ашырууга мүмкүндүк берүү (маркетерлер бул ыкманы "полиглоттук программалоо" деп аташат). Ошентип, жогоруда сүрөттөлгөн XML валидация кызматы Java тorнде жазылышы мүмкүн, ал эми валидация микросервиси ошол эле учурда Хаскеллде жазылышы мүмкүн (математикалык жактан туура болушу үчүн). Камсыздандыруу микросервиси үчүн Erlang колдонсоңуз болот (анткени ал чындап масштабдалышы керек;)). Иштеп чыгуучунун көз карашы боюнча кызыктуу көрүнгөн нерсе (обочолонгон чөйрөдө идеалдуу тorңиз менен идеалдуу системаны иштеп чыгуу), чындыгында, уюм эч качан каалаган нерсе эмес: гомогенизация жана стандартташтыруу. Бул тилдердин, китепканалардын жана куралдардын салыштырмалуу стандартташтырылган топтомун билдирет, ошондуктан башка иштеп чыгуучулар келечекте сиз жашыл жайыттарга өткөндө Haskell микросервисиңизди колдоону уланта алышат. Тарых стандартташтыруу, адатта, өтө терең сиңип калганын көрсөтүп турат. Мисалы, ири Fortune 500 компанияларынын иштеп чыгуучуларына кээде Жазды колдонууга да уруксат берилген эмес, анткени ал "компаниянын технологиялык жол картасына кирбейт". Бирок, полиглоттук мамилеге толук өтүү дээрлик бир эле нерсе, бир эле тыйындын экинчи тарабы. Сунуш: Эгер сиз полиглоттук программалоону колдоно турган болсоңуз, ошол эле программалоо тorнин экосистемасынын ичинде азыраак түрлүктү байкап көрүңүз. Ошентип, Java жана, айталы, Хаскеллге караганда, Котлин менен Javaны чогуу колдонгон жакшы (эки тил тең JVMге негизделген жана бири-бирине 100% шайкеш келет). Кийинки бөлүмдө сиз Java микросервистерин жайылтуу жана тестирлөө жөнүндө биле аласыз.