A Guide to Java Microservices. Bagean 1: Dasar lan Arsitektur Microservices

Ing pandhuan iki, sampeyan bakal sinau apa microservices Java, carane ngrancang lan nggawe. Iki uga nyakup pitakonan babagan perpustakaan microservice Java lan kemungkinan nggunakake layanan mikro. Terjemahan lan adaptasi Java Microservices: A Practical Guide .

Java Microservices: Dasar

Kanggo ngerti layanan mikro, sampeyan kudu nemtokake apa sing dudu. Apa ora "monolit" - monolit Jawa: apa iku lan apa kaluwihan utawa cacat?

Apa iku monolit Jawa?

Bayangake sampeyan kerja ing bank utawa startup fintech. Sampeyan menehi pangguna aplikasi seluler sing bisa digunakake kanggo mbukak akun bank anyar. Ing kode Jawa iki bakal nyebabake ana kelas controller. Disederhanakake, katon kaya iki:

@Controller
class BankController {

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

Sampeyan mbutuhake controller kanggo:

1. Dikonfirmasi formulir registrasi.
2. Priksa risiko alamat pangguna kanggo mutusake manawa bakal menehi akun bank.
3. Mbukak akun bank.

Kelas BankControllerbakal rangkep bebarengan karo liyane saka sumber menyang bank.jar utawa bank.war file kanggo penyebaran prajurit - iki monolit lawas apik ngemot kabeh kode needed kanggo mbukak bank. Minangka perkiraan kasar, ukuran awal file .jar (utawa .war) bakal ana saka 1 nganti 100 MB. Saiki sampeyan mung bisa mbukak file .jar ing server sampeyan ... lan iku kabeh sing perlu kanggo masang aplikasi Java. Gambar, persegi dowo kiwa ndhuwur: penyebaran mono(lithic) bank java -jar bank.jar (cp .war/.ear menyang appserver). persegi dowo tengen: mbukak browser.

Apa masalah karo monolit Jawa?

Ora ana sing salah karo monolit Jawa. Nanging, pengalaman wis nuduhake yen ing proyek sampeyan:

• Ana akeh programer / tim / konsultan sing kerja ...
• ... liwat monolit padha ing meksa saka pelanggan karo syarat banget samar ...
• ing sawetara taun ...

... banjur ing kasus iki file bank.jar cilik sampeyan dadi gigabyte kode sing gedhe banget, sing nggegirisi malah nyedhaki, apamaneh disebarake.

Carane nyuda ukuran monolit Jawa?

Pitakonan alami muncul: carane nggawe monolith luwih cilik? Saiki bank.jar sampeyan mlaku ing siji JVM, siji proses ing siji server. Ora luwih, ora kurang. Lan saiki ana pikiran sing logis: "Nanging layanan verifikasi risiko bisa digunakake dening departemen liyane ing perusahaanku! Ora ana hubungane langsung karo aplikasi perbankan monolitik! Mbok iku kudu Cut metu saka monolith lan tugasaken minangka produk kapisah? Yaiku, kanthi teknis, mlaku minangka proses Jawa sing kapisah.

Apa iku microservice Java?

Ing laku, tembung iki tegese saiki telpon cara riskCheck()ora bakal digawe saka BankController: cara iki utawa komponen kacang karo kabeh kelas tambahan bakal dipindhah menyang Maven utawa Gradle project dhewe. Uga bakal disebarake lan diselehake ing kontrol versi independen saka monolit banking. Nanging, kabeh proses ekstraksi iki ora ngowahi modul RiskCheck anyar sampeyan dadi layanan mikro, amarga definisi layanan mikro mbukak kanggo interpretasi. Iki nyebabake diskusi asring ing tim lan perusahaan.

• Apa 5-7 kelas ing mikro proyek utawa apa?
• 100 utawa 1000 kelas ... isih mikro?
• Apa microservice umume ana hubungane karo jumlah kelas utawa ora?

Ayo ninggalake pertimbangan teoretis, lan tetep nganggo pertimbangan pragmatis lan tindakake iki:

1. Ayo nelpon kabeh layanan microservice sing disebar kanthi kapisah, preduli saka ukuran utawa wates domain.
2. Ayo dipikirake carane ngatur komunikasi antar layanan. Layanan mikro kita butuh cara kanggo komunikasi karo siji liyane.

Dadi, kanggo ngringkes: sadurunge sampeyan duwe siji proses JVM, monolit sing padhet kanggo mbukak bank. Saiki sampeyan duwe proses JVM monolit perbankan lan layanan mikro RiskCheck kapisah sing mlaku ing proses JVM dhewe. Lan saiki, kanggo mriksa risiko, monolit sampeyan kudu nelpon layanan mikro iki. Carane nindakake iki?

Kepiye carane nggawe komunikasi antarane layanan mikro Jawa?

Umumé lan umum, ana rong pilihan - komunikasi sinkron lan asinkron.

Komunikasi sinkron: (HTTP)/REST

Biasane, komunikasi sing disinkronake antarane layanan mikro dumadi liwat layanan kaya HTTP lan REST sing ngasilake XML utawa JSON. Mesthi wae, bisa uga ana pilihan liyane - njupuk paling ora Google Protocol Buffers . Yen sampeyan butuh respon langsung, luwih becik nggunakake komunikasi REST. Ing conto kita, iki persis sing kudu ditindakake, amarga verifikasi risiko dibutuhake sadurunge mbukak akun. Yen ora ana mriksa risiko, ora ana akun. Kita bakal ngrembug alat ing ngisor iki, ing bagean " Pustaka sing paling apik kanggo telpon REST Java sinkron ".

Pesen - Komunikasi Asynchronous

Komunikasi layanan mikro asinkron biasane ditindakake kanthi ijol-ijolan pesen karo implementasi JMS lan/utawa nggunakake protokol kayata AMQP . Kita nulis "biasane" ing kene kanthi alasan: ayo ngomong jumlah integrasi email / SMTP ora bisa disepelekake. Gunakake nalika sampeyan ora mbutuhake respon langsung. Contone, pangguna ngeklik tombol "tuku saiki", lan sampeyan uga pengin nggawe invoice. Proses iki mesthi ora kedadeyan ing siklus panjalukan-respon tuku pangguna. Ing ngisor iki kita bakal njlèntrèhaké alat sing paling apik kanggo olahpesen Jawa asinkron .

Conto: REST API telpon ing Jawa

Ayo kita nganggep kita milih komunikasi microservice sinkron. Ing kasus iki, kode Jawa kita (sing kita presented ndhuwur) ing tingkat kurang bakal katon kaya iki. (kanthi tingkat sing kurang ing kene tegese kasunyatan manawa kanggo komunikasi microservice, perpustakaan klien biasane digawe sing abstrak saka telpon HTTP sing nyata).

@Controller
class BankController {

    @Autowired
    private HttpClient httpClient;

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

Adhedhasar kode kasebut, dadi jelas yen saiki kita kudu nggunakake rong layanan Java (mikro), Bank lan RiskCheck. Akibaté, kita bakal duwe loro pangolahan JVM mlaku. Iku kabeh sing perlu kanggo ngembangaken project Java microservices: mung mbangun lan masang potongan cilik (.jar utawa .war file) tinimbang siji monolithic. Jawaban kanggo pitakonan kasebut tetep ora jelas: kepiye carane ngethok monolit dadi layanan mikro? Sepira cilik potongan kasebut, kepiye carane nemtokake ukuran sing bener? Ayo priksa.

Arsitektur Microservices Jawa

Ing praktik, perusahaan ngembangake proyek layanan mikro kanthi cara sing beda-beda. Pendekatan kasebut gumantung apa sampeyan nyoba ngowahi monolit sing wis ana dadi proyek microservice utawa miwiti proyek kasebut saka awal.

Saka monolith kanggo microservices

Salah sawijining ide sing paling logis yaiku ngekstrak layanan mikro saka monolit sing ana. Elinga yen awalan "mikro" ing kene ora ateges layanan sing diekstrak bakal dadi cilik; iki ora mesthi kedadeyan. Ayo ndeleng latar mburi teoritis.

Idea: break monolith menyang microservices

Pendekatan layanan mikro bisa ditrapake kanggo proyek warisan. Lan mulane:

1. Paling asring, proyek kasebut angel dijaga / diganti / dikembangake.
2. Saben uwong, saka pangembang nganti manajemen, pengin nyederhanakake.
3. Sampeyan duwe (relatif) wates domain sing jelas, tegese sampeyan ngerti persis apa sing kudu ditindakake piranti lunak sampeyan.

Bali menyang conto kita, iki tegese sampeyan bisa ndeleng monolit perbankan Jawa lan nyoba kanggo break mudhun liwat wates domain.

• Dadi, bakal cukup kanggo misahake pangolahan data pangguna (kayata jeneng, alamat, nomer telpon) menyang layanan mikro sing kapisah "Manajemen Akun".
• Utawa "Modul Pemeriksa Risiko" sing kasebut ing ndhuwur sing mriksa tingkat risiko pangguna lan bisa digunakake dening akeh proyek liyane utawa malah departemen perusahaan.
• Utawa modul invoice sing ngirim invoice ing format PDF utawa liwat mail.

Implementasi gagasan: supaya wong liya nindakake

Pendekatan sing diterangake ing ndhuwur katon apik ing kertas lan diagram kaya UML. Nanging, kabeh ora dadi prasaja. Implementasi praktis mbutuhake persiapan teknis sing serius: jurang antarane pangerten babagan apa sing bakal diekstrak saka monolit lan proses ekstraksi dhewe gedhe banget. Umume proyek perusahaan tekan tahap ing ngendi pangembang wedi, ucapake, nganyarke versi Hibernate sing umur 7 taun dadi sing luwih anyar. Pustaka bakal dianyari bebarengan karo, nanging ana bebaya nyata bejat soko. Dadi pangembang sing padha saiki kudu nggali kode warisan kuno kanthi wates transaksi database sing ora jelas lan ngekstrak layanan mikro sing wis ditemtokake? Paling asring, masalah iki rumit banget lan ora bisa "ditanggulangi" ing papan tulis utawa ing rapat arsitektur. Kanggo ngutip pangembang Twitter @simonbrown: Aku bakal ngomong maneh lan maneh ... yen wong ora bisa mbangun monolith kanthi bener, microservices ora bakal mbantu. Simon Brown

Proyek saka awal adhedhasar arsitektur microservice

Ing kasus proyèk Jawa anyar, telu angka saka bagéan sadurungé katon rada beda:

1. Sampeyan miwiti karo slate resik, supaya ora ana "bagasi" kanggo njaga.
2. Pangembang pengin tetep prasaja ing mangsa ngarep.
3. Masalah: Sampeyan duwe gambar wates domain sing luwih kabur: sampeyan ora ngerti apa sing kudu ditindakake piranti lunak sampeyan (petunjuk: agile ;))

Iki nyebabake perusahaan nyoba proyek anyar nganggo layanan mikro Java.

Arsitektur microservice teknis

Titik pisanan katon sing paling jelas kanggo pangembang, nanging ana uga sing ora kuwatir. Hadi Hariri nyaranake "Extract Microservice" refactoring ing IntelliJ. Lan sanajan conto ing ngisor iki gampang banget, implementasine sing diamati ing proyek nyata, sayangé, ora adoh banget. Sadurunge microservices

@Service
class UserService {

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

Kanthi substring Java microservice

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

Dadi sampeyan pancen mbungkus panggilan metode Java ing telpon HTTP, tanpa alesan sing jelas. Siji alesan, Nanging, iki: kurang pengalaman lan nyoba kanggo meksa pendekatan microservices Jawa. Rekomendasi: Aja nindakake iki.

Arsitektur microservice berorientasi alur kerja

Pendekatan umum sabanjure yaiku mbagi microservices Java menyang modul adhedhasar alur kerja. Conto nyata: Ing Jerman, nalika sampeyan menyang dhokter (umum), dheweke kudu ngrekam kunjungan sampeyan ing sistem CRM medis. Kanggo entuk pembayaran saka asuransi, dheweke bakal ngirim data babagan perawatan sampeyan (lan perawatan pasien liyane) menyang perantara liwat XML. Broker bakal ndeleng file XML iki lan (disederhanakake):

1. Bakal mriksa yen file XML sing bener ditampa.
2. Iku bakal mriksa plausibility saka tata cara: ngomong, bocah umur setaun sing nampa telung prosedur reresik untu ing sawijining dina saka gynecologist katon rada curiga.
3. Bakal nggabungake XML karo sawetara data birokrasi liyane.
4. Bakal nerusake file XML menyang perusahaan asuransi kanggo miwiti pembayaran.
5. Lan bakal ngirim asil menyang dhokter, menehi pesen "sukses" utawa "monggo kirim maneh rekaman iki sanalika bisa."

Cathetan. Ing conto iki, komunikasi antarane microservices ora muter peran, nanging uga bisa rampung asynchronously dening makelar pesen (eg RabbitMQ), amarga dhokter ora nampa saran langsung. Maneh, iki katon apik ing kertas, nanging pitakonan alami muncul:

• Apa perlu masang enem aplikasi kanggo ngolah siji file XML?
• Apa layanan mikro iki pancen bebas saka saben liyane? Apa bisa disebarake kanthi bebas saka saben liyane? Kanthi macem-macem versi lan skema API?
• Apa sing ditindakake microservice plausibility informasi yen microservice verifikasi ora bisa digunakake? Apa sistem isih bisa digunakake?
• Apa microservices iki nuduhake database padha (padha mesthi mbutuhake sawetara data umum ing tabel DB), utawa padha duwe dhewe?
• … lan akeh liyane.

Sing nggumunake, diagram ing ndhuwur katon luwih gampang amarga saben layanan saiki duwe tujuan sing tepat lan jelas. Iku digunakake kanggo katon kaya monolith medeni iki: Nalika sampeyan bisa argue bab gamblang saka diagram iki, temtunipun saiki kudu ngatasi tantangan operasional tambahan iki.

• Sampeyan ora mung kudu masang siji aplikasi, nanging paling sethithik enem.
• Sampeyan bisa uga kudu nyebarake pirang-pirang basis data, gumantung sepira sampeyan pengin mlebu ing arsitektur layanan mikro.
• Sampeyan kudu nggawe manawa saben sistem online lan bisa digunakake kanthi bener.
• Sampeyan kudu mesthekake yen telpon ing antarane layanan mikro pancen tahan banting (pirsani Kepiye carane nggawe layanan mikro Jawa dadi tahan banting?).
• Lan liya-liyane sing ditrapake persiyapan iki - saka setelan pangembangan lokal nganti tes integrasi.

Dadi, rekomendasi kasebut yaiku:

• Yen sampeyan dudu Netflix (kemungkinan, sampeyan dudu Netflix) ...
• Kajaba sing duwe skills karya super kuwat ngendi sampeyan mbukak lingkungan pembangunan lan nyebabake monkey lam sing mbuwang adoh database produksi kang gampang dibalèkaké ing 5 detik.
• utawa sampeyan aran kaya @monzo lan gelem nyoba 1500 microservices mung amarga sampeyan bisa.

→ Aja nindakake iki. Lan saiki kurang hiperbolik. Nyoba model microservices liwat wates domain katon cukup cukup. Nanging iki ora ateges sampeyan kudu njupuk siji alur kerja lan dibagi dadi bagean cilik (nampa XML, validasi XML, maju XML). Mula, saben sampeyan miwiti proyek anyar nganggo microservices Java lan wates domain isih kabur, coba njaga ukuran microservice sampeyan ing tingkat sing sithik. Sampeyan bisa tansah nambah modul liyane mengko. Lan priksa manawa sampeyan wis maju DevOps ing tim / perusahaan / divisi kanggo ndhukung infrastruktur anyar sampeyan.

Polyglot utawa arsitektur microservice berorientasi tim

Ana pendekatan katelu, meh libertarian, kanggo ngembangake layanan mikro: ngidini tim utawa malah individu kanggo ngetrapake crita pangguna nggunakake sawetara basa utawa layanan mikro (para pemasar nyebut pendekatan iki "pemrograman poliglot"). Mangkono, layanan validasi XML sing diterangake ing ndhuwur bisa ditulis nganggo basa Jawa, dene layanan mikro validasi ing wektu sing padha bisa ditulis ing Haskell (kanggo nggawe swara matematika). Kanggo microservice sing diterusake asuransi, sampeyan bisa nggunakake Erlang (amarga pancen kudu skala;)). Apa sing katon nyenengake saka sudut pandang pangembang (ngembangake sistem sing sampurna nganggo basa sing sampurna ing lingkungan sing terisolasi), nyatane, ora ana sing dikarepake organisasi: homogenisasi lan standarisasi. Iki tegese sakumpulan basa, perpustakaan, lan alat sing relatif standar supaya pangembang liyane bisa terus ndhukung microservice Haskell ing mangsa ngarep nalika sampeyan pindhah menyang pangonan sing luwih ijo. Sejarah nuduhake yen standarisasi biasane dadi jero banget. Contone, pangembang ing perusahaan Fortune 500 sing gedhe kadhangkala ora diidini nggunakake Spring amarga "dudu bagean saka roadmap teknologi perusahaan." Nanging, transisi lengkap menyang pendekatan polyglot meh padha, sisih liyane saka duwit receh padha. Rekomendasi: Yen sampeyan arep nggunakake program polyglot, coba kurang variasi ing ekosistem basa pamrograman sing padha. Dadi, luwih becik nggunakake Kotlin lan Jawa bebarengan (loro basa kasebut adhedhasar JVM lan 100% kompatibel karo siji liyane), tinimbang Jawa lan, ucapake, Haskell. Ing bagean sabanjure, sampeyan bakal sinau babagan nyebarake lan nguji microservices Java.