Panduan untuk Perkhidmatan Mikro Java. Bahagian 3: soalan am

Terjemahan dan penyesuaian Java Microservices: A Practical Guide . Bahagian panduan sebelumnya:

• asas perkhidmatan mikro dan seni binanya ;
• menggunakan dan menguji perkhidmatan mikro .

Mari kita lihat masalah yang wujud dalam perkhidmatan mikro di Jawa, bermula dengan perkara abstrak dan berakhir dengan perpustakaan konkrit.

Bagaimana untuk menjadikan perkhidmatan mikro Java berdaya tahan?

Ingat bahawa apabila anda mencipta perkhidmatan mikro, anda pada asasnya memperdagangkan panggilan kaedah JVM untuk panggilan HTTP segerak atau pemesejan tak segerak. Walaupun panggilan kaedah kebanyakannya dijamin untuk diselesaikan (kecuali penutupan JVM yang tidak dijangka), panggilan rangkaian tidak boleh dipercayai secara lalai. Ia mungkin berfungsi, tetapi ia mungkin tidak berfungsi atas pelbagai sebab: rangkaian terlampau beban, peraturan tembok api baharu telah dilaksanakan, dan sebagainya. Untuk melihat cara ini membuat perubahan, mari lihat contoh BillingService.

Corak Ketahanan HTTP/REST

Katakan pelanggan boleh membeli e-buku di tapak web syarikat anda. Untuk melakukan ini, anda baru sahaja melaksanakan perkhidmatan mikro pengebilan yang boleh menghubungi kedai dalam talian anda untuk menjana invois PDF sebenar. Buat masa ini, kami akan membuat panggilan ini secara serentak, melalui HTTP (walaupun lebih masuk akal untuk memanggil perkhidmatan ini secara tidak segerak, kerana penjanaan PDF tidak perlu serta-merta dari perspektif pengguna. Kami akan menggunakan contoh yang sama dalam seterusnya bahagian dan lihat perbezaannya).

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

Untuk meringkaskan, berikut ialah tiga kemungkinan hasil panggilan HTTP ini.

• OK: panggilan dibuat, akaun berjaya dibuat.
• KELEWATAN: Panggilan telah diteruskan, tetapi ia mengambil masa terlalu lama untuk diselesaikan.
• RALAT. Panggilan gagal, anda mungkin telah menghantar permintaan yang tidak serasi, atau sistem mungkin tidak berfungsi.

Mana-mana program dijangka dapat mengendalikan situasi ralat, bukan hanya yang berjaya. Perkara yang sama berlaku untuk perkhidmatan mikro. Walaupun anda perlu berusaha lebih untuk memastikan bahawa semua versi API yang digunakan adalah serasi sebaik sahaja anda bermula dengan penggunaan dan keluaran perkhidmatan mikro individu. Kes yang menarik untuk dilihat ialah kes kelewatan. Contohnya, pemacu keras perkhidmatan mikro responden penuh, dan bukannya mengambil 50 ms, ia mengambil masa 10 saat untuk bertindak balas. Ia menjadi lebih menarik apabila anda mengalami beban tertentu sehingga ketidakresponsifan Perkhidmatan Bil anda mula mengalir melalui sistem anda. Sebagai contoh ilustrasi, bayangkan dapur perlahan-lahan memulakan "blok" semua pelayan restoran. Bahagian ini jelas sekali tidak dapat memberikan gambaran menyeluruh tentang topik ketahanan perkhidmatan mikro, tetapi ia berfungsi sebagai peringatan kepada pembangun bahawa ini sebenarnya sesuatu yang perlu ditangani dan tidak diabaikan sebelum keluaran pertama anda (yang, dari pengalaman, berlaku lebih kerap daripada tidak). berikut). Pustaka popular yang membantu anda berfikir tentang kependaman dan toleransi kesalahan ialah Hystrix Netflix. Gunakan dokumentasinya untuk menyelami topik dengan lebih mendalam.

Corak Ketahanan Pemesejan

Mari kita lihat lebih dekat pada komunikasi tak segerak. Program BillingService kami kini mungkin kelihatan seperti ini, dengan andaian kami menggunakan Spring dan RabbitMQ untuk pemesejan. Untuk membuat akaun, kami kini menghantar mesej kepada broker mesej RabbitMQ kami, di mana terdapat beberapa pekerja menunggu mesej baharu. Pekerja ini membuat invois PDF dan menghantarnya kepada pengguna yang sesuai.

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

Ralat berpotensi kelihatan sedikit berbeza sekarang, kerana anda tidak lagi menerima jawapan OK atau ERROR serta-merta seperti yang anda lakukan dengan sambungan HTTP segerak. Sebaliknya, kami mungkin mempunyai tiga kemungkinan senario yang boleh menjadi salah, yang boleh menimbulkan soalan berikut:

1. Adakah mesej saya dihantar dan digunakan oleh pekerja? Atau adakah ia hilang? (Pengguna tidak menerima invois).
2. Adakah mesej saya hanya dihantar sekali? Atau dihantar lebih daripada sekali dan diproses sekali sahaja? (Pengguna akan menerima berbilang invois).
3. Konfigurasi: Daripada "Adakah saya menggunakan kekunci/nama penghalaan yang betul untuk pertukaran" kepada "Adakah broker mesej saya dikonfigurasikan dan diselenggara dengan betul atau adakah baris gilirnya penuh?" (Pengguna tidak menerima invois).

Penerangan terperinci bagi setiap corak ketahanan perkhidmatan mikro tak segerak individu adalah di luar skop panduan ini. Walau bagaimanapun, terdapat tanda-tanda ke arah yang betul. Selain itu, mereka akan bergantung pada teknologi pemesejan. Contoh:

• Jika anda menggunakan pelaksanaan JMS seperti ActiveMQ, anda boleh menukar kelajuan untuk jaminan komitmen dua fasa (XA).
• Jika anda menggunakan RabbitMQ, baca tutorial ini dahulu, dan kemudian fikirkan dengan teliti tentang pengesahan, toleransi kesalahan dan kebolehpercayaan mesej secara umum.
• Mungkin seseorang mahir dalam mengkonfigurasi pelayan Aktif atau RabbitMQ, terutamanya dalam kombinasi dengan pengelompokan dan Docker (sesiapa sahaja? ;))

Rangka kerja manakah yang akan menjadi penyelesaian terbaik untuk perkhidmatan mikro Java?

Di satu pihak, anda boleh memasang pilihan yang sangat popular seperti Spring Boot . Ia menjadikannya sangat mudah untuk mencipta fail .jar, dilengkapi dengan pelayan web terbina dalam seperti Tomcat atau Jetty, dan boleh dijalankan dengan cepat dan di mana-mana sahaja. Ideal untuk membina aplikasi perkhidmatan mikro. Baru-baru ini, beberapa rangka kerja perkhidmatan mikro khusus, Kubernetes atau GraalVM , muncul, sebahagiannya diilhamkan oleh pengaturcaraan reaktif. Berikut ialah beberapa lagi pesaing yang menarik: Quarkus , Micronaut , Vert.x , Helidon . Pada akhirnya, anda perlu memilih sendiri, tetapi kami boleh memberikan anda beberapa cadangan yang mungkin tidak sepenuhnya standard: Dengan pengecualian Spring Boot, semua rangka kerja perkhidmatan mikro biasanya dipasarkan dengan sangat pantas, dengan permulaan yang hampir serta-merta , penggunaan memori yang rendah, kebolehskalaan kepada infiniti. Bahan pemasaran biasanya menampilkan grafik yang mengagumkan yang mempamerkan platform bersebelahan dengan Spring Boot raksasa atau antara satu sama lain. Ini, secara teorinya, melepaskan kegelisahan pembangun yang menyokong projek warisan, yang kadangkala mengambil masa beberapa minit untuk dimuatkan. Atau pembangun yang bekerja di awan yang ingin memulakan/menghentikan seberapa banyak bekas mikro yang mereka perlukan dalam masa 50 ms. Masalahnya, bagaimanapun, ialah masa permulaan logam kosong (tiruan) ini dan masa penempatan semula hampir tidak menyumbang kepada kejayaan keseluruhan projek. Sekurang-kurangnya mereka mempengaruhi kurang daripada infrastruktur rangka kerja yang kukuh, dokumentasi yang kukuh, komuniti dan kemahiran pembangun yang kukuh. Jadi lebih baik untuk melihatnya dengan cara ini: Jika setakat ini:

• Anda membiarkan ORM anda berleluasa, menghasilkan ratusan pertanyaan untuk aliran kerja mudah.
• Anda memerlukan gigabait yang tidak berkesudahan untuk menjalankan monolit sederhana kompleks anda.
• Anda mempunyai begitu banyak kod dan kerumitannya sangat tinggi (kami tidak bercakap tentang permulaan yang berpotensi perlahan seperti Hibernate sekarang) sehingga aplikasi anda mengambil masa beberapa minit untuk dimuatkan.

Jika ini berlaku, maka menambah isu mycoservice tambahan (ketahanan rangkaian, pemesejan, DevOps, infrastruktur) akan memberi kesan yang lebih besar pada projek anda daripada memuatkan Hello, dunia yang kosong. Dan untuk penempatan semula panas semasa pembangunan, anda mungkin mendapat penyelesaian seperti JRebel atau DCEVM . Mari luangkan sedikit masa untuk memetik Simon Brown sekali lagi : " Jika orang tidak dapat membina monolit (pantas dan cekap), mereka akan menghadapi kesukaran membina perkhidmatan mikro (pantas dan cekap), tanpa mengira strukturnya ." Jadi pilih rangka kerja anda dengan bijak.

Perpustakaan manakah yang terbaik untuk panggilan Java REST segerak?

Dari segi teknikal peringkat rendah, anda mungkin akan mendapat salah satu daripada perpustakaan klien HTTP berikut: HttpClient asli Java (sejak Java 11), HttpClient Apache atau OkHttp . Ambil perhatian bahawa saya menyebut "mungkin" di sini kerana terdapat pilihan lain, daripada pelanggan JAX-RS lama yang baik kepada pelanggan WebSocket moden . Walau apa pun, trendnya adalah ke arah menjana klien HTTP, menjauhkan diri daripada bermain-main dengan panggilan HTTP sendiri. Untuk melakukan ini, anda perlu melihat projek OpenFeign dan dokumentasinya sebagai titik permulaan untuk bacaan selanjutnya.

Apakah broker terbaik untuk pemesejan Java tak segerak?

Kemungkinan besar, anda akan menemui ActiveMQ (Classic atau Artemis) yang popular , RabbitMQ atau Kafka .

• ActiveMQ dan RabbitMQ ialah broker mesej tradisional yang lengkap. Mereka melibatkan interaksi "broker pintar" dan "pengguna bodoh".
• Dari segi sejarah, ActiveMQ telah mendapat manfaat sebaris mudah (untuk ujian), yang boleh dikurangkan dengan tetapan RabbitMQ/Docker/TestContainer.
• Kafka tidak boleh dipanggil broker tradisional "pintar". Sebaliknya, ia adalah kedai mesej (fail log) yang agak "bodoh" yang memerlukan pengguna pintar untuk memproses.

Untuk lebih memahami masa untuk menggunakan RabbitMQ (atau broker mesej tradisional lain secara umum) atau Kafka, lihat siaran Pivotal ini sebagai titik permulaan. Secara umum, apabila memilih broker pemesejan, cuba abaikan sebab prestasi buatan. Ada masanya pasukan dan komuniti dalam talian akan sentiasa berhujah tentang seberapa pantas RabbitMQ dan betapa perlahan ActiveMQ. Sekarang hujah yang sama dibuat mengenai RabbitMQ, mereka mengatakan ia berfungsi dengan perlahan dengan 20-30 ribu mesej sesaat. Kafka merekodkan 100 ribu mesej sesaat. Terus terang, perbandingan seperti itu seperti membandingkan hangat dengan lembut. Selain itu, dalam kedua-dua kes, nilai pemprosesan mungkin berada dalam julat rendah hingga pertengahan, katakan, Kumpulan Alibaba. Walau bagaimanapun, anda tidak mungkin menemui projek skala ini (berjuta-juta mesej seminit) dalam realiti. Mereka pasti wujud dan mereka akan menghadapi masalah. Tidak seperti 99% projek perniagaan Java "biasa" yang lain. Oleh itu, jangan hiraukan fesyen dan gembar-gembur. Pilih dengan bijak.

Apakah perpustakaan yang boleh saya gunakan untuk menguji perkhidmatan mikro?

Ia bergantung pada timbunan anda. Jika anda mempunyai ekosistem Spring digunakan, adalah bijak untuk menggunakan alatan khusus rangka kerja . Jika JavaEE adalah seperti Arquillian . Mungkin berbaloi untuk melihat Docker dan pustaka Testcontainers yang sangat bagus , yang membantu khususnya untuk menyediakan pangkalan data Oracle dengan mudah dan cepat untuk pembangunan tempatan atau ujian integrasi. Untuk menguji olok-olok seluruh pelayan HTTP, lihat Wiremock . Untuk menguji pemesejan tak segerak, cuba laksanakan ActiveMQ atau RabbitMQ dan kemudian tulis ujian menggunakan Awaitility DSL . Selain itu, semua alatan biasa anda digunakan - Junit , TestNG untuk AssertJ dan Mockito . Sila ambil perhatian bahawa ini bukan senarai lengkap. Jika anda tidak menemui alat kegemaran anda di sini, sila siarkan di bahagian komen.

Bagaimana untuk membolehkan pengelogan untuk semua perkhidmatan mikro Java?

Log masuk kes perkhidmatan mikro adalah topik yang menarik dan agak rumit. Daripada mempunyai satu fail log yang anda boleh manipulasi dengan arahan yang kurang atau grep, anda kini mempunyai n fail log, dan anda mahu mereka tidak terlalu berselerak. Ciri-ciri ekosistem pembalakan diterangkan dengan baik dalam artikel ini (dalam bahasa Inggeris). Pastikan anda membacanya dan perhatikan bahagian Pengelogan berpusat dari perspektif perkhidmatan mikro . Dalam amalan, anda akan menemui pendekatan yang berbeza: Pentadbir sistem menulis skrip tertentu yang mengumpul dan menggabungkan fail log daripada pelayan berbeza ke dalam satu fail log dan meletakkannya pada pelayan FTP untuk dimuat turun. Menjalankan kombinasi kucing/grep/unig/isih dalam sesi SSH selari. Inilah yang dilakukan oleh Amazon AWS, dan anda boleh memberitahu pengurus anda. Gunakan alat seperti Graylog atau ELK Stack (Elasticsearch, Logstash, Kibana)

Bagaimanakah perkhidmatan mikro saya mencari antara satu sama lain?

Sehingga kini, kami menganggap bahawa perkhidmatan mikro kami tahu tentang satu sama lain dan mengetahui IPS yang sepadan. Mari kita bercakap tentang konfigurasi statik. Jadi, monolit perbankan kami [ip = 192.168.200.1] tahu bahawa ia perlu bercakap dengan pelayan risiko [ip = 192.168.200.2], yang dikodkan keras dalam fail sifat. Walau bagaimanapun, anda boleh menjadikan perkara lebih dinamik:

• Gunakan pelayan konfigurasi berasaskan awan dari mana semua perkhidmatan mikro menarik konfigurasi mereka dan bukannya menggunakan fail application.properties pada perkhidmatan mikro mereka.
• Memandangkan tika perkhidmatan anda boleh menukar lokasinya secara dinamik, adalah wajar melihat perkhidmatan yang mengetahui tempat perkhidmatan anda berada, IP mereka dan cara menghalakannya.
• Sekarang segala-galanya dinamik, masalah baru timbul, seperti pemilihan pemimpin secara automatik: siapakah tuan yang mengerjakan tugas tertentu supaya tidak memprosesnya dua kali, misalnya? Siapa yang menggantikan pemimpin apabila dia gagal? Atas dasar apakah penggantian berlaku?

Secara umum, inilah yang dipanggil orkestrasi perkhidmatan mikro dan ia adalah satu lagi topik yang tidak berpenghujung. Perpustakaan seperti Eureka atau Zookeeper cuba "menyelesaikan" masalah ini dengan menunjukkan perkhidmatan yang tersedia. Sebaliknya, mereka memperkenalkan kerumitan tambahan. Tanya sesiapa yang pernah memasang ZooKeeper.

Bagaimana untuk mengatur kebenaran dan pengesahan menggunakan perkhidmatan mikro Java?

Topik ini juga layak untuk cerita yang berasingan. Sekali lagi, pilihan terdiri daripada pengesahan HTTPS asas berkod keras dengan rangka kerja keselamatan tersuai kepada menjalankan pemasangan Oauth2 dengan pelayan kebenarannya sendiri.

Bagaimanakah saya boleh memastikan bahawa semua persekitaran saya kelihatan sama?

Perkara yang benar untuk penempatan tanpa perkhidmatan mikro juga benar untuk penggunaan dengan satu. Cuba gabungan Docker/Testcontainers dan Scripting/Ansible.

Tiada soalan: secara ringkas tentang YAML

Mari kita menjauhkan diri dari perpustakaan dan isu-isu yang berkaitan untuk seketika dan lihat sebentar di Yaml. Format fail ini digunakan secara de facto sebagai format untuk "konfigurasi penulisan sebagai kod." Ia juga digunakan oleh alat mudah seperti Ansible dan gergasi seperti Kubernetes. Untuk mengalami kesakitan lekukan YAML, cuba tulis fail Ansible yang mudah dan lihat berapa banyak anda perlu mengedit fail sebelum ia berfungsi seperti yang diharapkan. Dan ini walaupun formatnya disokong oleh semua IDE utama! Selepas itu, kembali untuk menghabiskan membaca panduan ini.

Yaml:
  - is:
    - so
    - great

Bagaimana pula dengan transaksi yang diedarkan? Ujian prestasi? Topik lain?

Mungkin suatu hari nanti, dalam edisi manual yang akan datang. Buat masa ini, itu sahaja. Kekal bersama kami!

Isu Konseptual dengan Microservices

Selain masalah khusus perkhidmatan mikro di Jawa, terdapat masalah lain, katakan, masalah yang muncul dalam mana-mana projek perkhidmatan mikro. Mereka berkaitan kebanyakannya dengan organisasi, pasukan dan pengurusan.

Bahagian hadapan dan bahagian belakang tidak sepadan

Ketakpadanan Frontend dan Backend ialah masalah yang sangat biasa dalam banyak projek perkhidmatan mikro. Apakah maksudnya? Hanya itu dalam monolit lama yang baik, pembangun antara muka web mempunyai satu sumber khusus untuk mendapatkan data. Dalam projek perkhidmatan mikro, pembangun bahagian hadapan tiba-tiba mempunyai n sumber untuk mendapatkan data daripadanya. Bayangkan anda sedang mencipta beberapa jenis projek perkhidmatan mikro IoT (Internet of Things) di Jawa. Katakan anda menguruskan mesin geodetik dan relau industri di seluruh Eropah. Dan ketuhar ini menghantar anda kemas kini tetap dengan suhunya dan seumpamanya. Lambat laun anda mungkin mahu mencari ketuhar dalam UI pentadbir, mungkin menggunakan perkhidmatan mikro "carian relau". Bergantung pada sejauh mana ketat rakan sejawat belakang anda menggunakan reka bentuk dipacu domain atau undang-undang perkhidmatan mikro, perkhidmatan mikro "cari ketuhar" hanya boleh mengembalikan ID ketuhar dan bukan data lain seperti jenis, model atau lokasi. Untuk melakukan ini, pembangun bahagian hadapan perlu membuat satu atau n panggilan tambahan (bergantung pada pelaksanaan halaman) dalam perkhidmatan mikro "dapatkan data relau" dengan ID yang mereka terima daripada perkhidmatan mikro pertama. Dan walaupun ini hanyalah contoh mudah, walaupun diambil dari projek sebenar (!), malah ia menunjukkan masalah berikut: pasar raya telah menjadi sangat popular. Itu kerana dengan mereka anda tidak perlu pergi ke 10 tempat berbeza untuk membeli sayur-sayuran, air limau, piza beku dan kertas tandas. Sebaliknya, anda pergi ke satu tempat. Ia lebih mudah dan cepat. Perkara yang sama berlaku untuk pembangun bahagian hadapan dan perkhidmatan mikro.

Jangkaan Pengurusan

Pengurusan berada di bawah tanggapan yang silap bahawa mereka kini perlu mengupah pembangun yang tidak terhingga untuk projek (menyeluruh), kerana pembangun kini boleh bekerja sepenuhnya secara bebas antara satu sama lain, masing-masing menggunakan perkhidmatan mikro mereka sendiri. Hanya sedikit kerja penyepaduan diperlukan pada penghujung (sejurus sebelum pelancaran). Malah, pendekatan ini sangat bermasalah. Dalam perenggan berikut kami akan cuba menerangkan sebabnya.

"Kepingan yang lebih kecil" tidak sama dengan "kepingan yang lebih baik"

Adalah satu kesilapan besar untuk menganggap bahawa kod yang dibahagikan kepada 20 bahagian semestinya mempunyai kualiti yang lebih tinggi daripada satu bahagian keseluruhan. Walaupun kami mengambil kualiti dari sudut teknikal semata-mata, perkhidmatan individu kami mungkin masih menjalankan 400 pertanyaan Hibernate untuk memilih pengguna daripada pangkalan data, merentasi lapisan kod yang tidak disokong. Sekali lagi, kami kembali kepada petikan Simon Brown: jika anda gagal membina monolit dengan betul, sukar untuk membina perkhidmatan mikro yang betul. Selalunya terlalu lewat untuk bercakap tentang toleransi kesalahan dalam projek perkhidmatan mikro. Sehingga kadangkala menakutkan untuk melihat cara perkhidmatan mikro berfungsi dalam projek sebenar. Sebabnya ialah pembangun Java tidak sentiasa bersedia untuk mengkaji toleransi kesalahan, rangkaian dan topik berkaitan lain pada tahap yang sepatutnya. "Kepingan" itu sendiri lebih kecil, tetapi "bahagian teknikal" lebih besar. Bayangkan pasukan perkhidmatan mikro anda diminta untuk menulis perkhidmatan mikro teknikal untuk log masuk ke sistem pangkalan data, seperti ini:

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

Kini pasukan anda mungkin memutuskan (dan mungkin juga meyakinkan ahli perniagaan) bahawa ini terlalu mudah dan membosankan, daripada menulis perkhidmatan log masuk, adalah lebih baik untuk menulis perkhidmatan mikro UserStateChanged yang benar-benar berguna tanpa sebarang implikasi perniagaan yang nyata dan ketara. Dan memandangkan sesetengah orang pada masa ini menganggap Java seperti dinosaur, mari tulis perkhidmatan mikro UserStateChanged kami dalam Erlang yang bergaya. Dan mari cuba gunakan pokok merah-hitam di suatu tempat, kerana Steve Yegge menulis bahawa anda perlu mengenalinya dari dalam untuk memohon kepada Google. Dari perspektif penyepaduan, penyelenggaraan dan reka bentuk keseluruhan, ini sama buruknya dengan menulis lapisan kod spageti dalam satu monolit. Contoh tiruan dan biasa? Ini adalah benar. Walau bagaimanapun, ini boleh berlaku dalam realiti.

Lebih sedikit kepingan - kurang pemahaman

Kemudian persoalan timbul secara semula jadi tentang memahami sistem secara keseluruhan, proses dan aliran kerjanya, tetapi pada masa yang sama anda, sebagai pembangun, hanya bertanggungjawab untuk mengusahakan perkhidmatan mikro terpencil anda [95: login-101: updateUserProfile]. Ia selaras dengan perenggan sebelumnya, tetapi bergantung pada organisasi anda, tahap kepercayaan dan komunikasi, ini boleh membawa kepada banyak kekeliruan, mengangkat bahu dan menyalahkan jika terdapat kerosakan yang tidak disengajakan dalam rantaian perkhidmatan mikro. Dan tidak ada sesiapa yang akan bertanggungjawab sepenuhnya atas apa yang berlaku. Dan ia bukan soal ketidakjujuran. Malah, sangat sukar untuk menyambung bahagian yang berbeza dan memahami tempatnya dalam gambaran keseluruhan projek.

Komunikasi dan perkhidmatan

Tahap komunikasi dan perkhidmatan sangat bergantung pada saiz syarikat. Walau bagaimanapun, hubungan umum adalah jelas: semakin banyak, semakin bermasalah.

• Siapa yang menjalankan perkhidmatan mikro #47?
• Adakah mereka hanya menggunakan versi perkhidmatan mikro yang baharu dan tidak serasi? Di manakah ini didokumenkan?
• Dengan siapa saya perlu bercakap untuk meminta ciri baharu?
• Siapa yang akan menyokong perkhidmatan mikro itu di Erlang, selepas satu-satunya yang tahu bahasa ini meninggalkan syarikat itu?
• Semua pasukan perkhidmatan mikro kami bekerja bukan sahaja dalam bahasa pengaturcaraan yang berbeza, tetapi juga dalam zon waktu yang berbeza! Bagaimanakah kita menyelaraskan semua ini dengan betul?

Perkara utama ialah, seperti DevOps, pendekatan menyeluruh terhadap perkhidmatan mikro dalam sebuah syarikat besar, mungkin juga antarabangsa, datang dengan banyak masalah komunikasi tambahan. Dan syarikat mesti serius bersedia untuk ini.

kesimpulan

Selepas membaca artikel ini, anda mungkin berfikir bahawa pengarang adalah penentang kuat perkhidmatan mikro. Ini tidak sepenuhnya benar - saya pada asasnya cuba menyerlahkan perkara yang tidak ramai orang beri perhatian dalam perlumbaan gila untuk teknologi baharu.

Perkhidmatan mikro atau monolit?

Menggunakan perkhidmatan mikro Java pada bila-bila masa, di mana sahaja adalah satu keterlaluan. Yang lain ternyata seperti beratus-ratus modul Maven lama yang bagus dalam monolit. Tugas anda adalah untuk mencari keseimbangan yang betul. Ini benar terutamanya untuk projek baharu. Tiada apa-apa yang menghalang anda daripada mengambil pendekatan yang lebih konservatif, "monolitik" dan mencipta modul Maven yang lebih sedikit, dan bukannya bermula dengan dua puluh perkhidmatan mikro sedia awan.

Perkhidmatan mikro menjana kerumitan tambahan

Perlu diingat bahawa lebih banyak perkhidmatan mikro yang anda miliki dan DevOps yang kurang berkuasa yang anda miliki (tidak, menjalankan beberapa skrip Ansible atau menggunakan Heroku tidak dikira!), semakin banyak masalah yang anda akan hadapi kemudian dalam proses. Walaupun hanya membaca hingga ke penghujung bahagian panduan ini khusus untuk soalan umum tentang perkhidmatan mikro Java adalah tugas yang membosankan. Fikirkan bersungguh-sungguh tentang melaksanakan penyelesaian kepada semua masalah infrastruktur ini dan anda akan tiba-tiba menyedari bahawa ia bukan lagi mengenai pengaturcaraan perniagaan (apa yang anda dibayar untuk lakukan) tetapi lebih kepada membetulkan lebih banyak teknologi pada lebih banyak teknologi. Shiva Prasad Reddy merumuskannya dengan sempurna dalam blognya : "Anda tidak tahu betapa dahsyatnya apabila pasukan menghabiskan 70% masa bergelut dengan infrastruktur moden ini dan hanya 30% masa yang tinggal untuk melakukan logik perniagaan sebenar. ” Shiva Prasad Reddy

Adakah berbaloi untuk mencipta perkhidmatan mikro Java?

Untuk menjawab soalan ini, saya ingin mengakhiri artikel ini dengan penggoda seperti temu bual Google yang sangat nakal. Jika anda mengetahui jawapan kepada soalan ini daripada pengalaman, walaupun ia nampaknya tidak ada kaitan dengan perkhidmatan mikro, anda mungkin bersedia untuk pendekatan perkhidmatan mikro.

Senario

Bayangkan anda mempunyai monolit Java yang berjalan bersendirian pada pelayan khusus Hetzner terkecil . Perkara yang sama berlaku untuk pelayan pangkalan data anda, ia juga berjalan pada mesin Hetzner yang serupa . Dan mari kita anggap juga bahawa monolit Java anda boleh mengendalikan aliran kerja, katakan pendaftaran pengguna, dan anda tidak mencipta ratusan pertanyaan pangkalan data bagi setiap aliran kerja, tetapi nombor yang lebih munasabah (<10).

soalan

Berapa banyak sambungan pangkalan data perlu dibuka monolit Java (kolam sambungan) pada pelayan pangkalan data anda? Kenapa begitu? Berapa ramai pengguna aktif serentak yang anda fikir monolit anda boleh (kira-kira) skala?

Jawab

Tinggalkan jawapan anda untuk soalan-soalan ini di bahagian komen. Saya menantikan semua jawapan. Sekarang buat keputusan. Jika anda membaca sehingga akhir, kami sangat berterima kasih kepada anda!