A Guide to Java Microservices. Part 3: pitakonan umum

Terjemahan lan adaptasi Java Microservices: A Practical Guide . Bagian sadurunge pandhuan:

• dhasar microservices lan arsitektur sing ;
• nyebarke lan nguji layanan mikro .

Ayo goleki masalah sing ana ing layanan mikro ing Jawa, diwiwiti kanthi abstrak lan dipungkasi karo perpustakaan konkrit.

Kepiye carane nggawe layanan mikro Java sing tahan banting?

Elinga yen sampeyan nggawe microservices, sampeyan kudu dagang metode JVM kanggo telpon HTTP sinkron utawa olahpesen asinkron. Nalika telpon cara biasane dijamin rampung (ngalangi mati JVM sing ora dikarepke), telpon jaringan ora bisa dipercaya kanthi standar. Bisa uga, nanging bisa uga ora bisa digunakake kanggo macem-macem alasan: jaringan overloaded, aturan firewall anyar wis dileksanakake, lan liya-liyane. Kanggo ndeleng carane iki ndadekake prabédan, ayo kang ndeleng conto BillingService.

Pola Ketahanan HTTP/REST

Contone, pelanggan bisa tuku e-buku ing situs web perusahaan sampeyan. Kanggo nindakake iki, sampeyan mung nerapake layanan mikro tagihan sing bisa nelpon toko online kanggo ngasilake invoice PDF sing nyata. Saiki, kita bakal nelpon iki kanthi sinkron, liwat HTTP (sanajan luwih apik kanggo nelpon layanan iki kanthi ora sinkron, amarga generasi PDF ora kudu langsung saka sudut pandang pangguna. Kita bakal nggunakake conto sing padha ing sabanjure. bagean lan deleng prabédan).

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

Kanggo ngringkes, ing ngisor iki ana telung kemungkinan asil saka telpon HTTP iki.

• OK: telpon liwat, akun wis kasil digawe.
• DELAY: Telpon liwat, nanging njupuk dawa banget kanggo rampung.
• ERROR. Telpon gagal, sampeyan bisa uga wis ngirim panjalukan sing ora kompatibel, utawa sistem bisa uga ora bisa digunakake.

Program apa wae wis samesthine kanggo nangani kahanan kesalahan, ora mung sukses. Padha ditrapake kanggo microservices. Malah yen sampeyan kudu sijine ing gaweyan ekstra kanggo mesthekake yen kabeh versi tugasaken saka API kompatibel yen sampeyan miwiti karo penyebaran lan rilis microservices individu. Kasus sing menarik kanggo dideleng yaiku kasus tundha. Contone, hard drive microservice responden kebak, lan tinimbang njupuk 50 ms, butuh 10 detik kanggo nanggapi. Iku dadi luwih menarik nalika sampeyan nemu beban tartamtu kayata unresponsiveness saka BillingService wiwit cascade liwat sistem. Minangka conto ilustrasi, mbayangno pawon alon-alon miwiti "blok" kabeh pelayan restoran. Bagean iki temenan ora bisa menehi ringkesan lengkap babagan topik ketahanan microservice, nanging minangka pangeling kanggo pangembang yen iki pancene kudu ditangani lan ora diabaikan sadurunge release pisanan (sing, saka pengalaman, kedadeyan luwih kerep tinimbang ora). nderek). Pustaka populer sing mbantu sampeyan mikir babagan latensi lan toleransi kesalahan yaiku Hystrix Netflix. Gunakake dokumentasi kanggo nyilem luwih jero menyang topik kasebut.

Pola Ketahanan Pesen

Ayo dideleng kanthi cetha babagan komunikasi asinkron. Program BillingService kita saiki bisa katon kaya iki, yen kita nggunakake Spring lan RabbitMQ kanggo olahpesen. Kanggo nggawe akun, saiki kita ngirim pesen menyang broker pesen RabbitMQ, ing ngendi ana sawetara buruh nunggu pesen anyar. Buruh iki nggawe invoice PDF lan dikirim menyang pangguna sing cocog.

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

Kesalahan potensial katon rada beda saiki, amarga sampeyan ora nampa respon OK utawa ERROR langsung kaya sing sampeyan tindakake karo sambungan HTTP sing sinkron. Nanging, kita bisa uga duwe telung skenario potensial sing bisa salah, sing bisa nuwuhake pitakonan ing ngisor iki:

1. Apa pesenku dikirim lan digunakake dening karyawan? Utawa wis ilang? (Panganggo ora nampa invoice).
2. Apa pesenku mung dikirim sepisan? Utawa dikirim luwih saka sepisan lan diproses mung sapisan? (Panganggo bakal nampa macem-macem invoice).
3. Konfigurasi: Saka "Apa aku nggunakake tombol / jeneng rute sing bener kanggo ijol-ijolan" dadi "Apa broker pesenku dikonfigurasi lan dijaga kanthi bener utawa antrian kebak?" (Panganggo ora nampa invoice).

Katrangan rinci babagan saben pola ketahanan microservice asynchronous ora ngluwihi ruang lingkup pandhuan iki. Nanging, ana pratandha ing arah sing bener. Kajaba iku, bakal gumantung ing teknologi olahpesen. Tuladha:

• Yen sampeyan nggunakake implementasi JMS kaya ActiveMQ, sampeyan bisa perdagangan kacepetan kanggo njamin loro-phase (XA) commits.
• Yen sampeyan nggunakake RabbitMQ, waca tutorial iki dhisik, banjur pikirake kanthi teliti babagan konfirmasi, toleransi kesalahan, lan linuwih pesen ing umum.
• Mbok menawa ana wong sing ngerti konfigurasi server Active utawa RabbitMQ, utamane ing kombinasi karo clustering lan Docker (sapa wae? ;))

Kerangka apa sing bakal dadi solusi paling apik kanggo layanan mikro Java?

Ing tangan siji, sampeyan bisa nginstal pilihan banget populer kayata Spring Boot . Iku ndadekake gampang banget kanggo nggawe file .jar, dilengkapi karo server web dibangun ing kaya Tomcat utawa Jetty, lan bisa mbukak cepet lan ing ngendi wae. Becik kanggo mbangun aplikasi microservice. Bubar, sawetara kerangka microservice khusus, Kubernetes utawa GraalVM , muncul, sebagian diilhami dening pemrograman reaktif. Kene sawetara contenders liyane menarik: Quarkus , Micronaut , Vert.x , Helidon . Pungkasane, sampeyan kudu milih dhewe, nanging kita bisa menehi sawetara rekomendasi sing bisa uga ora standar: Kajaba Spring Boot, kabeh kerangka microservices biasane dipasarake kanthi cepet, kanthi wiwitan meh cepet. , panggunaan memori sing sithik, skalabilitas nganti tanpa wates. Materi pemasaran biasane nampilake grafis sing nyengsemake sing nuduhake platform ing jejere Boot Spring raksasa utawa saben liyane. Iki, ing teori, nyisihake saraf pangembang sing ndhukung proyek warisan, sing kadhangkala mbutuhake sawetara menit kanggo mbukak. Utawa pangembang sing makarya ing méga sing pengin miwiti / mungkasi minangka akeh microcontainers sing saiki perlu ing 50 ms. Masalah, Nanging, iki (artificial) Bare metal kaping wiwitan lan kaping redeployment meh ora kontribusi kanggo sukses sakabèhé saka project. Paling ora, pengaruhe kurang saka infrastruktur kerangka sing kuwat, dokumentasi sing kuat, komunitas lan katrampilan pangembang sing kuwat. Dadi luwih apik kanggo ndeleng kanthi cara iki: Yen nganti saiki:

• Sampeyan ngidini ORMs mlaku, ngasilake atusan pitakon kanggo alur kerja sing prasaja.
• Sampeyan butuh gigabyte tanpa wates kanggo mbukak monolit sing cukup kompleks.
• Sampeyan duwe akeh kode lan kerumitan banget (kita ora ngomong babagan wiwitan sing bisa alon kaya Hibernate saiki) saengga aplikasi sampeyan butuh sawetara menit kanggo mbukak.

Yen ngono, banjur nambah masalah mycoservice tambahan (ketahanan jaringan, olahpesen, DevOps, infrastruktur) bakal duwe pengaruh sing luwih gedhe ing proyek sampeyan tinimbang mbukak Hello, donya sing kosong. Lan kanggo redeployments panas sak pembangunan, sampeyan bisa mungkasi karo solusi kaya JRebel utawa DCEVM . Ayo sedhela maneh ngutip Simon Brown : " Yen wong ora bisa mbangun monoliths (cepet lan efisien), dheweke bakal angel mbangun layanan mikro (cepet lan efisien), preduli saka struktur . Dadi pilih kerangka kerja kanthi wicaksana.

Pustaka endi sing paling apik kanggo telpon REST Java sinkron?

Ing sisih teknis tingkat rendah, sampeyan bakal entuk salah sawijining perpustakaan klien HTTP ing ngisor iki: HttpClient asli Jawa (wiwit Java 11), HttpClient Apache , utawa OkHttp . Elinga yen aku ngomong "mbokmenawa" kene amarga ana opsi liyane, wiwit saka klien JAX-RS lawas apik kanggo klien WebSocket modern . Ing kasus apa wae, tren kasebut yaiku ngasilake klien HTTP, adoh saka muter-muter nganggo telpon HTTP dhewe. Kanggo nindakake iki, sampeyan kudu ndeleng proyek OpenFeign lan dokumentasi minangka titik wiwitan kanggo maca luwih lanjut.

Apa makelar paling apik kanggo olahpesen Jawa asinkron?

Paling kamungkinan, sampeyan bakal nemokake ActiveMQ populer (Klasik utawa Artemis) , RabbitMQ utawa Kafka .

• ActiveMQ lan RabbitMQ minangka makelar pesen tradisional sing lengkap. Dheweke melu interaksi "makelar cerdas" lan "pangguna bodho".
• Secara historis, ActiveMQ wis entuk manfaat saka inlining sing gampang (kanggo tes), sing bisa dikurangi nganggo setelan RabbitMQ/Docker/TestContainer.
• Kafka ora bisa diarani makelar "pinter" tradisional. Nanging, iki minangka toko pesen sing relatif "bisu" (file log) sing mbutuhake konsumen sing cerdas kanggo diproses.

Kanggo luwih ngerti kapan nggunakake RabbitMQ (utawa makelar pesen tradisional liyane ing umum) utawa Kafka, deleng postingan Pivotal iki minangka titik wiwitan. Umumé, nalika milih broker olahpesen, coba nglirwakake alasan kinerja buatan. Ana wektu nalika tim lan komunitas online bakal terus-terusan mbantah babagan sepira cepet RabbitMQ lan sepira alon ActiveMQ. Saiki bantahan sing padha digawe babagan RabbitMQ, ujare kerjane alon-alon kanthi 20-30 ewu pesen per detik. Kafka nyathet 100 ewu pesen per detik. Terus terang, bandhingan kasebut kaya mbandhingake anget karo alus. Kajaba iku, ing kaloro kasus kasebut, nilai throughput bisa uga ana ing kisaran sing sithik nganti pertengahan, ucapake, Alibaba Group. Nanging, sampeyan ora mungkin nemoni proyek kanthi skala iki (mayuta-yuta pesen saben menit) ing kasunyatan. Dheweke mesthi ana lan bakal duwe masalah. Ora kaya 99% proyek bisnis Jawa "biasa" liyane. Dadi aja nggatekake fashion lan hype. Pilih kanthi wicaksana.

Pustaka apa sing bisa digunakake kanggo nyoba layanan mikro?

Iku gumantung ing tumpukan Panjenengan. Yen sampeyan duwe ekosistem Spring, luwih becik nggunakake alat khusus kerangka kasebut . Yen JavaEE kaya Arquillian . Sampeyan bisa uga kudu dipikir ing Docker lan perpustakaan Testcontainers sing apik banget , sing mbantu utamane kanthi gampang lan cepet nyiyapake database Oracle kanggo pangembangan lokal utawa tes integrasi. Kanggo nguji kabeh server HTTP, priksa Wiremock . Kanggo nyoba olahpesen asinkron, coba gunakake ActiveMQ utawa RabbitMQ banjur tulis tes nggunakake Awaitility DSL . Kajaba iku, kabeh alat biasa sampeyan digunakake - Junit , TestNG kanggo AssertJ lan Mockito . Elinga yen iki dudu dhaptar lengkap. Yen sampeyan ora nemokake alat favorit ing kene, kirimake ing bagean komentar.

Kepiye ngaktifake logging kanggo kabeh layanan mikro Java?

Log ing kasus microservices minangka topik sing menarik lan rada rumit. Tinimbang duwe file log siji sing bisa ngapusi karo printah kurang utawa grep, sampeyan saiki duwe n file log, lan sampeyan pengin supaya ora kasebar. Fitur ekosistem logging diterangake kanthi apik ing artikel iki (ing basa Inggris). Dadi manawa kanggo maca, lan mbayar manungsa waé menyang bagean Centralized logging saka perspektif microservices . Ing laku, sampeyan bakal nemokake pendekatan sing beda-beda: Administrator sistem nulis skrip tartamtu sing ngumpulake lan nggabungake file log saka server sing beda menyang file log siji lan dilebokake ing server FTP kanggo diundhuh. Running cat / grep / unig / kombinasi urut ing sesi SSH paralel. Iki persis apa sing ditindakake Amazon AWS, lan sampeyan bisa ngandhani manajer sampeyan. Gunakake alat kaya Graylog utawa ELK Stack (Elasticsearch, Logstash, Kibana)

Kepiye carane microservices bisa nemokake saben liyane?

Nganti saiki, kita wis nganggep manawa layanan mikro kita ngerti babagan saben liyane lan ngerti IPS sing cocog. Ayo dadi pirembagan bab konfigurasi statis. Dadi, monolith perbankan kita [ip = 192.168.200.1] ngerti yen kudu ngobrol karo server resiko [ip = 192.168.200.2], sing hardcoded ing file properti. Nanging, sampeyan bisa nggawe luwih dinamis:

• Gunakake server konfigurasi basis awan saka ngendi kabeh layanan mikro narik konfigurasi tinimbang nggunakake file application.properties ing layanan mikro.
• Amarga conto layanan sampeyan bisa ngganti lokasi kanthi dinamis, mula kudu dideleng ing layanan sing ngerti lokasi layanan sampeyan, IP apa, lan cara ngarahake.
• Saiki kabeh wis dinamis, masalah anyar muncul, kayata pemilihan pimpinan otomatis: sapa master sing nggarap tugas tartamtu, supaya ora ngolah kaping pindho, umpamane? Sapa sing ngganti pimpinan nalika gagal? Ing basis apa panggantos njupuk Panggonan?

Ing istilah umum, iki sing diarani orkestrasi microservice lan topik liyane sing ora ana dasar. Perpustakaan kaya Eureka utawa Zookeeper nyoba "ngrampungake" masalah kasebut kanthi nuduhake layanan sing kasedhiya. Ing tangan liyane, padha introduce kerumitan tambahan. Takon sapa wae sing wis nate nginstal ZooKeeper.

Kepiye cara ngatur wewenang lan otentikasi nggunakake layanan mikro Java?

Topik iki uga pantes kanggo crita sing kapisah. Maneh, opsi kalebu saka otentikasi HTTPS dhasar hardcoded kanthi kerangka keamanan khusus kanggo nglakokake instalasi Oauth2 kanthi server wewenang dhewe.

Kepiye carane nggawe manawa kabeh lingkunganku katon padha?

Apa sing bener kanggo panyebaran tanpa layanan mikro uga bener kanggo panyebaran karo siji. Coba kombinasi Docker / Testcontainers lan Scripting / Ansible.

Ora ana pitakonan: sedhela babagan YAML

Ayo lunga saka perpustakaan lan masalah sing gegandhengan sedhela lan deleng cepet ing Yaml. Format file iki digunakake de facto minangka format kanggo "konfigurasi nulis minangka kode." Iki uga digunakake dening alat sing prasaja kaya Ansible lan raksasa kaya Kubernetes. Kanggo nemu lara saka indentasi YAML, coba tulis file Ansible sing prasaja lan deleng sepira sampeyan kudu ngowahi file kasebut sadurunge bisa digunakake kaya sing dikarepake. Lan iki senadyan format didhukung dening kabeh IDE utama! Sawise iku, bali kanggo ngrampungake maca pandhuan iki.

Yaml:
  - is:
    - so
    - great

Kepiye babagan transaksi sing disebarake? Tes kinerja? Topik liyane?

Mungkin ing sawijining dina, ing edisi manual sing bakal teka. Kanggo saiki, iku kabeh. Tetep karo kita!

Masalah Konseptual karo Microservices

Saliyane masalah khusus microservices ing Jawa, ana masalah liyane, umpamane, sing katon ing proyek microservice. Umume ana hubungane karo organisasi, tim lan manajemen.

Frontend lan Backend ora cocog

Frontend lan Backend mismatch minangka masalah sing umum banget ing akeh proyek microservice. Iki artine apa? Mung ing monoliths lawas sing apik, pangembang antarmuka web duwe sumber tartamtu kanggo entuk data. Ing proyèk microservice, gawe ngarep-mburi dumadakan duwe n sumber kanggo njupuk data saka. Bayangake sampeyan nggawe sawetara jinis proyek layanan mikro IoT (Internet of Things) ing Jawa. Contone, sampeyan ngatur mesin geodetik lan tungku industri ing saindenging Eropa. Lan oven iki ngirim nganyari reguler karo suhu lan liya-liyane. Cepet utawa mengko sampeyan pengin nemokake oven ing UI admin, bisa uga nggunakake layanan mikro "panelusur tungku". Gumantung carane ketat mitra backend sampeyan ngetrapake desain sing didhukung domain utawa undang-undang layanan mikro, layanan mikro "golek oven" mung bisa ngasilake ID oven lan dudu data liyane kayata jinis, model, utawa lokasi. Kanggo nindakake iki, pangembang frontend kudu nggawe siji utawa n panggilan tambahan (gumantung saka implementasine paging) ing microservice "entuk data tungku" karo ID sing ditampa saka microservice pisanan. Lan sanajan iki mung conto prasaja, sanajan dijupuk saka proyek nyata (!), malah nduduhake masalah ing ngisor iki: supermarket wis dadi populer banget. Iku amarga karo wong-wong mau sampeyan ora kudu pindhah menyang 10 panggonan beda kanggo tuku sayuran, limun, pizza beku lan kertas jamban. Nanging, sampeyan pindhah menyang sak panggonan, luwih gampang lan luwih cepet. Semono uga kanggo pangembang ngarep lan microservice.

Pangarep-arep Manajemen

Manajemen ana ing kesan sing salah yen saiki kudu nyewa pangembang sing ora ana watese kanggo proyek (overarching), amarga pangembang saiki bisa kerja kanthi mandiri, saben ing layanan mikro dhewe. Mung sawetara karya integrasi sing dibutuhake ing pungkasan (sadurunge sadurunge diluncurake). Ing kasunyatan, pendekatan iki arang banget masalah. Ing paragraf ing ngisor iki kita bakal nyoba nerangake apa sebabe.

"Potongan sing luwih cilik" ora padha karo "potongan sing luwih apik"

Iku bakal dadi kesalahan gedhe kanggo nganggep kode sing dipérang dadi 20 bagean kudu kualitas sing luwih dhuwur tinimbang siji kabèh. Sanajan kita njupuk kualitas saka sudut pandang teknis murni, layanan individu kita isih bisa mbukak 400 pitakon Hibernate kanggo milih pangguna saka database, ngliwati lapisan kode sing ora didukung. Sawise maneh, kita bali menyang kutipan Simon Brown: yen sampeyan gagal mbangun monolith kanthi bener, bakal angel mbangun layanan mikro sing tepat. Asring banget telat kanggo ngomong babagan toleransi kesalahan ing proyek microservice. Dadi, sok-sok medeni ndeleng kepiye layanan mikro ing proyek nyata. Alesan kanggo iki yaiku pangembang Jawa ora tansah siyap sinau toleransi fault, jaringan lan topik liyane sing gegandhengan ing tingkat sing tepat. "Potongan" dhewe luwih cilik, nanging "bagean teknis" luwih gedhe. Mbayangno tim microservices sampeyan dijaluk nulis microservice teknis kanggo mlebu menyang sistem database, kaya iki:

@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;
    }
}

Saiki tim sampeyan bisa mutusake (lan bisa uga ngyakinake para pebisnis) yen kabeh iki gampang banget lan mboseni, tinimbang nulis layanan login, luwih becik nulis layanan mikro UserStateChanged sing migunani banget tanpa ana implikasi bisnis sing nyata lan nyata. Lan amarga sawetara wong saiki nganggep Jawa kaya dinosaurus, ayo nulis microservice UserStateChanged ing Erlang sing modis. Lan ayo nyoba nggunakake wit-witan abang-ireng nang endi wae, amarga Steve Yegge nulis yen sampeyan kudu ngerti ing njero kanggo nglamar Google. Saka integrasi, pangopènan, lan perspektif desain sakabèhé, iki minangka ala kaya nulis lapisan kode spageti ing monolit siji. Conto gawean lan biasa? Iki bener. Nanging, iki bisa kedadeyan ing kasunyatan.

Kurang potongan - kurang pangerten

Banjur pitakonan kasebut kanthi alamiah babagan ngerteni sistem kanthi sakabehe, proses lan karyane, nanging ing wektu sing padha, sampeyan, minangka pangembang, mung tanggung jawab kanggo nggarap microservice sing terisolasi [95: login-101: updateUserProfile]. Selaras karo paragraf sadurunge, nanging gumantung saka organisasi sampeyan, tingkat kepercayaan lan komunikasi, iki bisa nyebabake akeh kebingungan, shrugs, lan nyalahke yen ana gangguan sing ora disengaja ing rantai microservice. Lan ora ana wong sing tanggung jawab kanggo kedadeyan kasebut. Lan iku dudu masalah ora jujur. Nyatane, angel banget kanggo nyambungake bagean sing beda-beda lan ngerti panggonane ing gambar sakabèhé proyek kasebut.

Komunikasi lan layanan

Tingkat komunikasi lan layanan beda-beda gumantung saka ukuran perusahaan. Nanging, hubungan umum katon: luwih akeh, luwih akeh masalah.

• Sing mbukak microservice #47?
• Apa dheweke mung masang versi microservice anyar sing ora kompatibel? Ing endi iki didokumentasikake?
• Aku kudu ngobrol karo sapa kanggo njaluk fitur anyar?
• Sapa sing bakal ndhukung layanan mikro ing Erlang, sawise siji-sijine sing ngerti basa iki ninggalake perusahaan kasebut?
• Kabeh tim microservice ora mung bisa digunakake ing macem-macem basa program, nanging uga ing zona wektu sing beda-beda! Kepiye carane kita koordinasi kabeh iki kanthi bener?

Titik utama yaiku, kaya DevOps, pendekatan lengkap kanggo layanan mikro ing perusahaan gedhe, bisa uga internasional, teka karo akeh masalah komunikasi tambahan. Lan perusahaan kudu nyiapake kanthi serius babagan iki.

kesimpulan

Sawise maca artikel iki, sampeyan bisa uga mikir yen penulis minangka mungsuh sing kuat kanggo layanan mikro. Iki ora kabeh bener - Aku Sejatine nyoba kanggo nyorot titik sing sawetara wong mbayar manungsa waé kanggo ing lomba mad kanggo teknologi anyar.

Microservices utawa monolith?

Nggunakake microservices Java kapan wae, ing ngendi wae iku salah sawijining ekstrem. Liyane dadi kaya atusan modul Maven lawas apik ing monolith a. Tugas sampeyan yaiku golek imbangan sing tepat. Iki utamané bener kanggo proyek anyar. Ora ana sing ngalangi sampeyan njupuk pendekatan "monolitik" sing luwih konservatif lan nggawe modul Maven sing luwih sithik, tinimbang miwiti karo layanan mikro sing siap awan rong puluh.

Microservices ngasilake kerumitan tambahan

Elinga yen luwih akeh layanan mikro sing sampeyan duwe lan DevOps sing kurang kuat (ora, nglakokake sawetara skrip Ansible utawa nyebarke menyang Heroku ora dianggep!), Masalah liyane sing bakal ditindakake mengko ing proses kasebut. Malah mung maca nganti pungkasan bagean pandhuan iki khusus kanggo pitakonan umum babagan microservices Java, iku tugas sing cukup mboseni. Mikir hard babagan ngleksanakake solusi kanggo kabeh masalah infrastruktur iki lan sampeyan bakal dumadakan éling sing iki ora maneh babagan program bisnis (apa sing njaluk mbayar kanggo nindakake) nanging luwih babagan ndandani teknologi liyane ing teknologi liyane. Shiva Prasad Reddy nyimpulake kanthi sampurna ing bloge : "Sampeyan ora ngerti sepira nggegirisi nalika tim mbuwang 70% wektu berjuang karo infrastruktur modern iki lan mung 30% wektu sing isih ana kanggo nindakake logika bisnis sing nyata. ” Siwa Prasad Reddy

Apa worth nggawe microservices Java?

Kanggo mangsuli pitakon iki, aku pengin mungkasi artikel iki kanthi teaser kaya wawancara Google. Yen sampeyan ngerti jawaban kanggo pitakonan iki saka pengalaman, sanajan ora ana hubungane karo microservices, sampeyan bisa uga siyap kanggo pendekatan microservices.

Skenario

Bayangake sampeyan duwe monolit Jawa sing mlaku dhewe ing server khusus Hetzner sing paling cilik . Padha ditrapake kanggo server database, iku uga mlaku ing mesin Hetzner padha . Lan ayo uga nganggep yen monolit Jawa sampeyan bisa nangani alur kerja, ujare registrasi pangguna, lan sampeyan ora nggawe atusan pitakon database saben alur kerja, nanging nomer sing luwih cukup (<10).

Pitakonan

Carane akeh sambungan database kudu monolit Jawa (kolam sambungan) mbukak ing server database? Kok ngono? Pira pangguna aktif bebarengan sing sampeyan pikirake monolit sampeyan bisa (kira-kira) skala?

Wangsulan

Ninggalake jawaban kanggo pitakonan kasebut ing bagean komentar. Aku ngarepake kabeh jawaban. Saiki gawe pikiranmu. Yen sampeyan maca nganti pungkasan, kita matur nuwun banget!