Java микросервистеріне арналған нұсқаулық. 1-бөлім: Микросервис негіздері және архитектурасы

Бұл нұсқаулықта сіз Java микросервистерінің не екенін, оларды қалай жобалау және жасау керектігін білесіз. Ол сонымен қатар Java микросервис кітапханалары және микросервистерді пайдалану мүмкіндігі туралы сұрақтарды қамтиды. Java микросервистерін аудару және бейімдеу : практикалық нұсқаулық .

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

Микросервистерді түсіну үшін алдымен олардың не емес екенін анықтау керек. Бұл «монолит» емес пе - Java монолиті: бұл не және оның артықшылықтары немесе кемшіліктері қандай?

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 қолданба serverіне) орналастыру. Оң жақ төртбұрыш: браузерді ашыңыз.

Java монолиттерімен қандай мәселе бар?

Java монолиттерінде дұрыс емес ештеңе жоқ. Дегенмен, тәжірибе көрсеткендей, егер сіздің жобаңызда:

• Көптеген бағдарламашылар/командалар/кеңесшілер жұмыс істейді...
• ...өте түсініксіз талаптары бар тұтынушылардың қысымымен сол монолиттің үстінде...
• бір-екі жыл ішінде...

... онда бұл жағдайда сіздің шағын bank.jar файлыңыз орасан зор гигаbyte codeқа айналады, оны орналастыру былай тұрсын, жақындау да қорқынышты.

Java монолитінің өлшемін қалай азайтуға болады?

Табиғи сұрақ туындайды: монолитті қалай кішірейту керек? Дәл қазір bank.jar бір JVM жүйесінде, бір serverде бір процесс жұмыс істейді. Артық емес, кем емес. Дәл қазір ойға логикалық ой келуі мүмкін: «Бірақ тәуекелді тексеру қызметін менің компаниямның басқа бөлімшелері де пайдалана алады! Бұл менің монолитті банктік қосымшама тікелей қатысты емес! Мүмкін оны монолиттен кесіп алып, жеке өнім ретінде орналастыру керек пе? Яғни, техникалық тілмен айтқанда, оны жеке Java процесі ретінде іске қосу.

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

Іс жүзінде бұл сөз тіркесі енді әдісті шақыру riskCheck()BankController қолданбасынан жасалмайтынын білдіреді: бұл әдіс немесе бұршақ құрамдас бөлігі өзінің барлық көмекші сыныптарымен өзінің Maven немесе Gradle жобасына ауыстырылады. Ол сондай-ақ банктік монолитке тәуелсіз түрде орналастырылады және нұсқалық бақылауға орналастырылады. Дегенмен, бұл бүкіл шығару процесі жаңа RiskCheck модуліңізді микросервиске айналдырмайды, өйткені микросервис анықтамасы түсіндіруге ашық. Бұл командалар мен компаниялар ішінде жиі талқылауларға әкеледі.

• Микро жобада 5-7 сынып бар ма немесе не?
• 100 немесе 1000 сынып... әлі де микро?
• Микросервис әдетте сыныптар санына байланысты ма, жоқ па?

Теориялық пайымдауды артта қалдырып, оның орнына прагматикалық ойларға сүйеніп, мынаны орындайық:

1. Өлшеміне немесе домен шекараларына қарамастан, барлық бөлек орналастырылған қызметтерді микросервис деп атайық.
2. Қызметаралық байланысты қалай ұйымдастыру керектігі туралы ойланайық. Біздің микросервистерге бір-бірімен байланысу тәсілдері қажет.

Сонымен, қорытындылау үшін: бұрын сізде бір JVM процесі болды, ол банкті басқаруға арналған берік монолит. Енді сізде банктік монолитті JVM процесі және жеке JVM процесінде жұмыс істейтін жеке RiskCheck микросервисі бар. Ал енді тәуекелдерді тексеру үшін монолит осы микросервиске қоңырау шалуы керек. Мұны қалай жасауға болады?

Java микросервистері арасындағы байланысты қалай орнатуға болады?

Жалпы және жалпы екі нұсқа бар - синхронды және асинхронды байланыс.

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

Әдетте, микросервистер арасындағы синхрондалған байланыс HTTP және XML немесе JSON қайтаратын REST тәрізді қызметтер арқылы жүзеге асады. Әрине, басқа опциялар болуы мүмкін - кем дегенде Google Protocol Buffers алыңыз . Егер сізге дереу жауап қажет болса, REST байланысын қолданған дұрыс. Біздің мысалда дәл осылай істеу керек, өйткені шот ашпас бұрын тәуекелді тексеру қажет. Тәуекелді тексеру болмаса, шот жоқ. Төмендегі құралдарды « Java REST синхронды қоңыраулары үшін қай кітапханалар жақсы » бөлімінде талқылаймыз .

Хабарлама – асинхронды байланыс

Асинхронды микросервис байланысы әдетте JMS енгізуімен және/немесе AMQP сияқты хаттамамен алмасу арқылы жүзеге асырылады . Біз мұнда бір себеппен «әдетте» деп жаздык: электрондық пошта/SMTP интеграцияларының санын елемеуге болмайды делік. Оны дереу жауап қажет болмаған кезде пайдаланыңыз. Мысалы, пайдаланушы «қазір сатып алу» түймесін басады, ал сіз өз кезегінде шот-фактураны жасағыңыз келеді. Бұл процесс, әрине, пайдаланушының сатып алу сұрауы-жауап циклі ішінде болмауы керек. Төменде біз асинхронды Java хабарламалары үшін қай құралдар жақсы екенін сипаттаймыз .

Мысал: Java тіліндегі 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 тәрізді диаграммаларда тамаша көрінеді. Дегенмен, бәрі соншалықты қарапайым емес. Оны іс жүзінде жүзеге асыру күрделі техникалық дайындықты қажет етеді: монолиттен нені алу жақсы болатынын түсінуіміз бен өндіру процесінің өзі арасындағы алшақтық өте үлкен. Көптеген кәсіпорын жобалары әзірлеушілер күту режимінің 7 жылдық нұсқасын жаңасына жаңартудан қорқатын кезеңге жетеді. Кітапханалар онымен бірге жаңартылады, бірақ бір нәрсені бұзу қаупі бар. Сонымен, дәл сол әзірлеушілер енді дерекқор транзакцияларының шекаралары анық емес көне codeты зерттеп, жақсы анықталған микросервистерді шығаруы керек пе? Көбінесе бұл мәселе өте күрделі және оны тақтада немесе сәулет жиналыстарында «шешу» мүмкін емес. Twitter әзірлеушісі @simonbrown сөзін келтіретін болсақ: Мен мұны қайта-қайта айтамын... егер адамдар монолиттерді дұрыс құра алмаса, микросервистер көмектеспейді. Саймон Браун

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

Жаңа Java жобалары үшін алдыңғы бөліктегі үш нөмірленген элемент сәл басқаша көрінеді:

1. Сіз таза парақтан бастайсыз, сондықтан күтетін «жүк» жоқ.
2. Әзірлеушілер болашақта қарапайым нәрселерді сақтағысы келеді.
3. Мәселе: Сізде домен шекараларының әлдеқайда анық емес суреті бар: сіз бағдарламалық жасақтаманың не істеу керек екенін білмейсіз (кеңес: agile;))

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

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

Бірінші тармақ әзірлеушілер үшін ең айқын болып көрінеді, бірақ оны қатты тоқтататындар да бар. Хади Харири IntelliJ жүйесінде «Extract Microservice» рефакторингін ұсынады. Келесі мысал өте жеңілдетілген болса да, нақты жобаларда байқалған енгізулер, өкінішке орай, одан тым алыс кетпейді. Микросервистерге дейін

@Service
class UserService {

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

Ішкі 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. Ол нәтижені дәрігерге жіберіп, оған «сәттілік» немесе «бұл жазбаны мағынасы болған кезде қайта жіберуіңізді өтінемін» деген хабарды береді.

Ескерту. Бұл мысалда микросервистер арасындағы байланыс рөл атқармайды, бірақ хабар брокерімен (мысалы, RabbitMQ) асинхронды түрде орындалуы мүмкін, себебі дәрігер бәрібір дереу кері байланыс алмайды. Тағы да, бұл қағазда жақсы көрінеді, бірақ табиғи сұрақтар туындайды:

• Бір XML файлын өңдеу үшін алты қолданбаны қолдану қажет пе?
• Бұл микросервистер бір-бірінен шынымен тәуелсіз ме? Оларды бір-бірінен тәуелсіз орналастыруға бола ма? Әртүрлі нұсқалармен және API схемаларымен?
• Тексеру микросервисі жұмыс істемесе, сенімділік микросервисі не істейді? Жүйе әлі жұмыс істеп жатыр ма?
• Бұл микросервистер бірдей дерекқорды ортақ пайдаланады ма (олар, әрине, ДҚ кестелеріндегі кейбір жалпы деректерге мұқтаж) немесе олардың әрқайсысында өздерінің бар ма?
• … және тағы басқалар.

Бір қызығы, жоғарыда келтірілген диаграмма қарапайымырақ көрінеді, өйткені қазір әрбір қызметтің өзінің нақты, нақты мақсаты бар. Бұрын бұл қорқынышты монолитке ұқсайтын: сіз осы диаграммалардың қарапайымдылығы туралы даулассаңыз да, енді осы қосымша операциялық қиындықтарды шешуіңіз керек.

• Сізге бір қолданбаны ғана емес, кем дегенде алты қолданбаны орналастыру қажет.
• Микросервис архитектурасына қаншалықты кіргіңіз келетініне байланысты бірнеше дерекқорды орналастыру қажет болуы мүмкін.
• Әрбір жүйенің желіде екеніне және дұрыс жұмыс істейтініне көз жеткізу керек.
• Микросервистер арасындағы қоңырауларыңыз шынымен төзімді екеніне көз жеткізуіңіз керек (Java микросервисін қалай төзімді ету керек? бөлімін қараңыз).
• Бұл орнатуды білдіретін барлық нәрсе - жергілікті әзірлеу параметрлерінен интеграциялық тестілеуге дейін.

Сонымен, ұсыныс келесідей болады:

• Егер сіз Netflix болмасаңыз (мүмкін, сіз Netflix емессіз)...
• Егер сізде әзірлеу ортасын ашатын өте күшті жұмыс дағдылары болмаса және ол 5 секундта оңай қалпына келтірілетін өндірістік дерекқорыңызды лақтырып жіберетін хаос маймылын тудырмаса.
• немесе сіз @monzo сияқты сезінесіз және 1500 микросервисті қолданып көруге дайынсыз.

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

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

Микросервистерді әзірлеудің үшінші, дерлік либертарлы тәсілі бар: топтарға немесе тіпті жеке тұлғаларға кез келген тілдерді немесе микросервистерді пайдалана отырып, пайдаланушы оқиғаларын жүзеге асыруға мүмкіндік беру (маркетингтер бұл тәсілді «полиглоттық бағдарламалау» деп атайды). Осылайша, жоғарыда сипатталған XML тексеру қызметі Java тілінде жазылуы мүмкін, ал валидация микросервисі бір уақытта Хаскелл тілінде жазылуы мүмкін (оны математикалық тұрғыдан дұрыс ету үшін). Сақтандыруды қайта жіберу микросервисі үшін сіз Erlang қызметін пайдалана аласыз (өйткені ол шынымен масштабтау керек;)). Әзірлеушінің көзқарасы бойынша қызық болып көрінуі мүмкін нәрсе (оқшауланған ортада мінсіз тіліңізбен тамаша жүйені жасау) іс жүзінде ұйым ешқашан қаламайды: гомогенизация және стандарттау. Бұл басқа әзірлеушілер сіз жасыл жайылымдарға көшкен кезде болашақта Haskell микросервисіне қолдау көрсетуді жалғастыра алатын тілдердің, кітапханалардың және құралдардың салыстырмалы түрде стандартталған жиынтығын білдіреді. Тарих стандарттау әдетте тым терең сіңіп кеткенін көрсетеді. Мысалы, Fortune 500 ірі компанияларындағы әзірлеушілерге кейде Spring қолданбасын пайдалануға рұқсат етілмеді, себебі ол «компанияның технологиялық жол картасының бөлігі емес». Дегенмен, полиглоттық тәсілге толық көшу - бұл бірдей нәрсе, бір тиынның екінші жағы. Ұсыныс: Егер сіз полиглоттық бағдарламалауды пайдаланғыңыз келсе, сол бағдарламалау тілінің экожүйесінде әртүрлілікті азайтып көріңіз. Сонымен, Java және, айталық, Haskell емес, Котлин мен Java тілдерін бірге қолданған дұрыс (екі тіл де JVM негізінде жасалған және бір-бірімен 100% үйлесімді). Келесі бөлімде сіз Java микросервистерін қолдану және сынау туралы білесіз.