Panduan untuk Layanan Mikro Java. Bagian 3: pertanyaan umum

Terjemahan dan adaptasi Java Microservices: Panduan Praktis . Bagian sebelumnya dari panduan ini:

• dasar-dasar layanan mikro dan arsitekturnya ;
• menerapkan dan menguji layanan mikro .

Mari kita lihat masalah yang melekat pada layanan mikro di Java, dimulai dengan hal-hal abstrak dan diakhiri dengan perpustakaan konkret.

Bagaimana cara membuat layanan mikro Java tangguh?

Ingatlah bahwa saat Anda membuat layanan mikro, pada dasarnya Anda memperdagangkan panggilan metode JVM untuk panggilan HTTP sinkron atau pesan asinkron. Meskipun sebagian besar pemanggilan metode dijamin selesai (kecuali jika JVM dimatikan secara tidak terduga), panggilan jaringan tidak dapat diandalkan secara default. Ini mungkin berhasil, tetapi mungkin tidak berfungsi karena berbagai alasan: jaringan kelebihan beban, aturan firewall baru telah diterapkan, dan seterusnya. Untuk melihat perbedaannya, mari kita lihat contoh BillingService.

Pola Ketahanan HTTP/REST

Katakanlah pelanggan dapat membeli eBook di situs web perusahaan Anda. Untuk melakukan ini, Anda baru saja menerapkan layanan mikro penagihan yang dapat menghubungi toko online Anda untuk menghasilkan faktur PDF yang sebenarnya. Untuk saat ini, kita akan melakukan panggilan ini secara sinkron, melalui HTTP (walaupun lebih masuk akal untuk memanggil layanan ini secara asinkron, karena pembuatan PDF tidak harus seketika dari sudut pandang pengguna. Kita akan menggunakan contoh yang sama pada contoh berikutnya bagian dan lihat perbedaannya).

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

Ringkasnya, berikut tiga kemungkinan hasil dari panggilan HTTP ini.

• OK: panggilan tersambung, akun berhasil dibuat.
• DELAY: Panggilan tersambung, namun butuh waktu terlalu lama untuk diselesaikan.
• KESALAHAN. Panggilan gagal, Anda mungkin mengirimkan permintaan yang tidak kompatibel, atau sistem mungkin tidak berfungsi.

Program apa pun diharapkan dapat menangani situasi kesalahan, bukan hanya situasi yang berhasil. Hal yang sama berlaku untuk layanan mikro. Meskipun Anda perlu melakukan upaya ekstra untuk memastikan bahwa semua versi API yang diterapkan kompatibel setelah Anda memulai penerapan dan rilis layanan mikro individual. Kasus yang menarik untuk dicermati adalah kasus penundaan. Misalnya, hard drive layanan mikro responden sudah penuh, dan bukannya memerlukan waktu 50 ms, dibutuhkan waktu 10 detik untuk merespons. Ini menjadi lebih menarik ketika Anda mengalami beban tertentu sehingga tidak responsifnya Layanan Penagihan Anda mulai mengalir ke seluruh sistem Anda. Sebagai contoh ilustratif, bayangkan sebuah dapur perlahan-lahan memulai “blok” semua pelayan restoran. Bagian ini jelas tidak dapat memberikan gambaran menyeluruh tentang topik ketahanan layanan mikro, namun berfungsi sebagai pengingat bagi pengembang bahwa ini sebenarnya adalah sesuatu yang perlu ditangani dan tidak diabaikan sebelum rilis pertama Anda (yang, berdasarkan pengalaman, lebih sering terjadi daripada tidak). berikut). Pustaka populer yang membantu Anda memikirkan latensi dan toleransi kesalahan adalah Hystrix dari Netflix. Gunakan dokumentasinya untuk mendalami topik ini lebih dalam.

Pola Ketahanan Pesan

Mari kita lihat lebih dekat komunikasi asinkron. Program BillingService kita sekarang mungkin terlihat seperti ini, dengan asumsi kita menggunakan Spring dan RabbitMQ untuk pengiriman pesan. Untuk membuat akun, sekarang kami mengirim pesan ke broker pesan RabbitMQ kami, di mana ada beberapa pekerja menunggu pesan baru. Para pekerja ini membuat faktur PDF dan mengirimkannya ke 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);
        // ...
    }
}

Potensi kesalahan terlihat sedikit berbeda sekarang, karena Anda tidak lagi menerima respons OK atau ERROR langsung seperti yang Anda lakukan dengan koneksi HTTP sinkron. Sebaliknya, kita mungkin mempunyai tiga skenario potensial yang mungkin salah, yang dapat menimbulkan pertanyaan-pertanyaan berikut:

1. Apakah pesan saya terkirim dan digunakan oleh karyawan tersebut? Atau hilang? (Pengguna tidak menerima faktur).
2. Apakah pesan saya hanya terkirim satu kali? Atau dikirimkan lebih dari satu kali dan hanya diproses satu kali? (Pengguna akan menerima beberapa faktur).
3. Konfigurasi: Dari "Apakah saya menggunakan kunci/nama perutean yang benar untuk pertukaran" hingga "Apakah broker pesan saya dikonfigurasi dan dikelola dengan benar atau apakah antreannya penuh?" (Pengguna tidak menerima faktur).

Penjelasan mendetail tentang masing-masing pola ketahanan layanan mikro asinkron berada di luar cakupan panduan ini. Namun, ada tanda-tanda ke arah yang benar. Selain itu, mereka akan bergantung pada teknologi pengiriman pesan. Contoh:

• Jika Anda menggunakan implementasi JMS seperti ActiveMQ, Anda dapat menukar kecepatan dengan jaminan penerapan dua fase (XA).
• Jika Anda menggunakan RabbitMQ, baca panduan ini terlebih dahulu, lalu pikirkan baik-baik tentang konfirmasi, toleransi kesalahan, dan keandalan pesan secara umum.
• Mungkin seseorang berpengalaman dalam mengkonfigurasi server Aktif atau RabbitMQ, terutama dalam kombinasi dengan clustering dan Docker (siapa saja? ;))

Kerangka kerja mana yang menjadi solusi terbaik untuk layanan mikro Java?

Di satu sisi, Anda dapat menginstal opsi yang sangat populer seperti Spring Boot . Ini membuatnya sangat mudah untuk membuat file .jar, dilengkapi dengan server web bawaan seperti Tomcat atau Jetty, dan dapat dijalankan dengan cepat dan di mana saja. Ideal untuk membangun aplikasi layanan mikro. Baru-baru ini, beberapa kerangka layanan mikro khusus, Kubernetes atau GraalVM , muncul, sebagian terinspirasi oleh pemrograman reaktif. Berikut beberapa pesaing yang lebih menarik: Quarkus , Micronaut , Vert.x , Helidon . Pada akhirnya, Anda harus memilih sendiri, tetapi kami dapat memberi Anda beberapa rekomendasi yang mungkin tidak sepenuhnya standar: Dengan pengecualian Spring Boot, semua kerangka layanan mikro biasanya dipasarkan dengan sangat cepat, dengan startup yang hampir seketika. , penggunaan memori rendah, skalabilitas hingga tak terbatas. Materi pemasaran biasanya menampilkan grafik mengesankan yang memamerkan platform di sebelah raksasa Spring Boot atau satu sama lain. Secara teori, hal ini membuat para pengembang yang mendukung proyek lama tidak perlu khawatir, yang terkadang membutuhkan waktu beberapa menit untuk dimuat. Atau pengembang yang bekerja di cloud yang ingin memulai/menghentikan mikrokontainer sebanyak yang mereka butuhkan saat ini dalam waktu 50 ms. Namun permasalahannya adalah waktu start-up (buatan) bare metal dan waktu pemindahan tidak memberikan kontribusi terhadap keberhasilan proyek secara keseluruhan. Setidaknya pengaruhnya tidak sebesar infrastruktur kerangka kerja yang kuat, dokumentasi yang kuat, komunitas, dan keterampilan pengembang yang kuat. Jadi lebih baik melihatnya seperti ini: Jika sejauh ini:

• Anda membiarkan ORM Anda merajalela, menghasilkan ratusan kueri untuk alur kerja sederhana.
• Anda memerlukan gigabyte yang tak ada habisnya untuk menjalankan monolit Anda yang cukup rumit.
• Anda memiliki begitu banyak kode dan kompleksitasnya sangat tinggi (kita tidak sedang membicarakan kemungkinan permulaan yang lambat seperti Hibernate sekarang) sehingga aplikasi Anda memerlukan waktu beberapa menit untuk dimuat.

Jika hal ini terjadi, maka menambahkan masalah mycoservice tambahan (ketahanan jaringan, perpesanan, DevOps, infrastruktur) akan memiliki dampak yang jauh lebih besar pada proyek Anda daripada memuat Hello, world yang kosong. Dan untuk hot redeployment selama pengembangan, Anda mungkin mendapatkan solusi seperti JRebel atau DCEVM . Mari luangkan waktu sejenak untuk mengutip lagi Simon Brown : “ Jika orang tidak dapat membangun monolit (cepat dan efisien), mereka akan kesulitan membangun layanan mikro (cepat dan efisien), apa pun strukturnya .” Jadi pilihlah kerangka kerja Anda dengan bijak.

Pustaka mana yang terbaik untuk panggilan Java REST yang disinkronkan?

Di sisi teknis tingkat rendah, Anda mungkin akan mendapatkan salah satu pustaka klien HTTP berikut: HttpClient asli Java (sejak Java 11), HttpClient Apache , atau OkHttp . Perhatikan bahwa saya mengatakan "mungkin" di sini karena ada opsi lain, mulai dari klien JAX-RS lama yang bagus hingga klien WebSocket modern . Bagaimanapun, trennya adalah menghasilkan klien HTTP, tidak lagi mengutak-atik panggilan HTTP sendiri. Untuk melakukan ini, Anda perlu melihat proyek OpenFeign dan dokumentasinya sebagai titik awal untuk membaca lebih lanjut.

Apa broker terbaik untuk perpesanan Java asinkron?

Kemungkinan besar, Anda akan menemukan ActiveMQ (Klasik atau Artemis) , RabbitMQ atau Kafka yang populer .

• ActiveMQ dan RabbitMQ adalah perantara pesan tradisional yang lengkap. Mereka melibatkan interaksi “broker pintar” dan “pengguna bodoh”.
• Secara historis, ActiveMQ memiliki keunggulan inlining yang mudah (untuk pengujian), yang dapat dikurangi dengan pengaturan RabbitMQ/Docker/TestContainer.
• Kafka tidak bisa disebut sebagai broker tradisional yang “pintar”. Sebaliknya, ini adalah penyimpanan pesan (file log) yang relatif "bodoh" yang memerlukan konsumen cerdas untuk memprosesnya.

Untuk lebih memahami kapan harus menggunakan RabbitMQ (atau broker pesan tradisional lainnya secara umum) atau Kafka, lihat postingan penting ini sebagai titik awal. Secara umum, ketika memilih broker perpesanan, cobalah untuk mengabaikan alasan kinerja yang dibuat-buat. Ada suatu masa ketika tim dan komunitas online terus-menerus berdebat tentang seberapa cepat RabbitMQ dan betapa lambatnya ActiveMQ. Sekarang argumen yang sama dibuat mengenai RabbitMQ, mereka mengatakan ia bekerja lambat dengan 20-30 ribu pesan per detik. Kafka mencatat 100 ribu pesan per detik. Sejujurnya, perbandingan seperti itu seperti membandingkan hangat dengan lembut. Selain itu, dalam kedua kasus tersebut, nilai throughput mungkin berada pada kisaran rendah hingga menengah, misalnya, Grup Alibaba. Namun, kecil kemungkinan Anda akan menemukan proyek sebesar ini (jutaan pesan per menit) di dunia nyata. Mereka pasti ada dan mereka akan mendapat masalah. Berbeda dengan 99% proyek bisnis Java “biasa” lainnya. Jadi jangan terlalu memperhatikan fashion dan hype. Pilihlah dengan bijak.

Pustaka apa yang dapat saya gunakan untuk menguji layanan mikro?

Itu tergantung pada tumpukan Anda. Jika Anda menerapkan ekosistem Spring, sebaiknya gunakan alat khusus kerangka kerja tersebut . Jika JavaEE seperti Arquillian . Mungkin ada baiknya melihat Docker dan perpustakaan Testcontainers yang sangat bagus , yang membantu khususnya dengan mudah dan cepat menyiapkan database Oracle untuk pengembangan lokal atau pengujian integrasi. Untuk pengujian tiruan seluruh server HTTP, lihat Wiremock . Untuk menguji perpesanan asinkron, coba terapkan ActiveMQ atau RabbitMQ lalu tulis pengujian menggunakan Awaitility DSL . Selain itu, semua alat yang biasa Anda gunakan - Junit , TestNG untuk AssertJ dan Mockito . Harap dicatat bahwa ini bukanlah daftar lengkap. Jika Anda tidak menemukan alat favorit Anda di sini, silakan posting di bagian komentar.

Bagaimana cara mengaktifkan logging untuk semua layanan mikro Java?

Pencatatan log dalam kasus layanan mikro adalah topik yang menarik dan agak rumit. Alih-alih memiliki satu file log yang dapat Anda manipulasi dengan perintah less atau grep, Anda sekarang memiliki n file log, dan Anda ingin file tersebut tidak terlalu tersebar. Ciri-ciri ekosistem penebangan dijelaskan dengan baik dalam artikel ini (dalam bahasa Inggris). Pastikan untuk membacanya, dan perhatikan bagian Logging terpusat dari perspektif layanan mikro . Dalam praktiknya, Anda akan menemukan pendekatan yang berbeda: Administrator sistem menulis skrip tertentu yang mengumpulkan dan menggabungkan file log dari server berbeda ke dalam satu file log dan meletakkannya di server FTP untuk diunduh. Menjalankan kombinasi cat/grep/unig/sort dalam sesi SSH paralel. Inilah yang dilakukan Amazon AWS, dan Anda dapat memberi tahu manajer Anda. Gunakan alat seperti Graylog atau ELK Stack (Elasticsearch, Logstash, Kibana)

Bagaimana layanan mikro saya dapat menemukan satu sama lain?

Hingga saat ini, kami berasumsi bahwa layanan mikro kami mengetahui satu sama lain dan mengetahui IPS yang sesuai. Mari kita bicara tentang konfigurasi statis. Jadi, monolit perbankan kita [ip = 192.168.200.1] mengetahui bahwa ia perlu berkomunikasi dengan server risiko [ip = 192.168.200.2], yang di-hardcode di file properti. Namun, Anda dapat menjadikannya lebih dinamis:

• Gunakan server konfigurasi berbasis cloud tempat semua layanan mikro mengambil konfigurasinya alih-alih menyebarkan file application.properties pada layanan mikronya.
• Karena instans layanan Anda dapat mengubah lokasinya secara dinamis, ada baiknya melihat layanan yang mengetahui di mana layanan Anda berada, apa IP-nya, dan bagaimana merutekannya.
• Kini, karena semuanya dinamis, muncul permasalahan baru, seperti otomatis terpilihnya seorang pemimpin: siapa master yang mengerjakan tugas tertentu, agar tidak diproses dua kali, misalnya? Siapa yang menggantikan pemimpin ketika ia gagal? Atas dasar apa penggantian itu dilakukan?

Secara umum, inilah yang disebut orkestrasi layanan mikro dan merupakan topik tanpa dasar lainnya. Perpustakaan seperti Eureka atau Zookeeper mencoba "memecahkan" masalah ini dengan menunjukkan layanan mana yang tersedia. Di sisi lain, hal ini menimbulkan kompleksitas tambahan. Tanyakan siapa saja yang pernah menginstal ZooKeeper.

Bagaimana cara mengatur otorisasi dan otentikasi menggunakan layanan mikro Java?

Topik ini juga layak mendapat cerita tersendiri. Sekali lagi, pilihannya berkisar dari otentikasi HTTPS dasar yang dikodekan dengan kerangka kerja keamanan khusus hingga menjalankan instalasi Oauth2 dengan server otorisasinya sendiri.

Bagaimana cara memastikan bahwa semua lingkungan saya terlihat sama?

Apa yang berlaku untuk penerapan tanpa layanan mikro juga berlaku untuk penerapan dengan layanan mikro. Coba kombinasi Docker/Testcontainers dan Scripting/Ansible.

Tidak ada pertanyaan: secara singkat tentang YAML

Mari sejenak menjauh dari perpustakaan dan masalah terkait dan melihat sekilas Yaml. Format file ini secara de facto digunakan sebagai format untuk “menulis konfigurasi sebagai kode”. Ini juga digunakan oleh alat sederhana seperti Ansible dan raksasa seperti Kubernetes. Untuk merasakan kesulitan lekukan YAML, cobalah menulis file Ansible sederhana dan lihat seberapa banyak Anda harus mengedit file tersebut sebelum berfungsi seperti yang diharapkan. Meskipun formatnya didukung oleh semua IDE utama! Setelah itu, kembalilah untuk menyelesaikan membaca panduan ini.

Yaml:
  - is:
    - so
    - great

Bagaimana dengan transaksi terdistribusi? Pengujian kinerja? Topik lainnya?

Mungkin suatu hari nanti, di edisi manual yang akan datang. Untuk saat ini, itu saja. Tetaplah bersama kami!

Masalah Konseptual dengan Layanan Mikro

Selain masalah khusus layanan mikro di Java, ada masalah lain, misalnya, yang muncul di proyek layanan mikro mana pun. Mereka sebagian besar berhubungan dengan organisasi, tim dan manajemen.

Ketidakcocokan Frontend dan Backend

Ketidakcocokan Frontend dan Backend adalah masalah yang sangat umum di banyak proyek layanan mikro. Apa artinya? Hanya saja di monolit lama yang bagus, pengembang antarmuka web memiliki satu sumber khusus untuk memperoleh data. Dalam proyek layanan mikro, pengembang front-end tiba-tiba memiliki n sumber untuk memperoleh data. Bayangkan Anda membuat semacam proyek layanan mikro IoT (Internet of Things) di Java. Katakanlah Anda mengelola mesin geodetik dan tungku industri di seluruh Eropa. Dan oven ini mengirimi Anda pembaruan rutin mengenai suhunya dan sejenisnya. Cepat atau lambat Anda mungkin ingin menemukan oven di UI admin, mungkin menggunakan layanan mikro "pencarian tungku". Bergantung pada seberapa ketat rekan backend Anda menerapkan undang-undang desain berbasis domain atau layanan mikro, layanan mikro “temukan oven” hanya dapat mengembalikan ID oven dan bukan data lain seperti jenis, model, atau lokasi. Untuk melakukan hal ini, pengembang frontend perlu melakukan satu atau n panggilan tambahan (bergantung pada implementasi paging) di layanan mikro “dapatkan data tungku” dengan ID yang mereka terima dari layanan mikro pertama. Meskipun ini hanya contoh sederhana, meskipun diambil dari proyek nyata (!), hal ini menunjukkan masalah berikut: supermarket telah menjadi sangat populer. Itu karena dengan mereka Anda tidak perlu pergi ke 10 tempat berbeda untuk membeli sayuran, limun, pizza beku, dan tisu toilet. Sebaliknya, Anda pergi ke satu tempat saja, lebih mudah dan cepat. Hal yang sama berlaku untuk pengembang front-end dan layanan mikro.

Harapan Manajemen

Manajemen mempunyai kesan yang salah bahwa mereka sekarang perlu mempekerjakan pengembang dalam jumlah tak terbatas untuk sebuah proyek (yang menyeluruh), karena pengembang sekarang dapat bekerja sepenuhnya secara independen satu sama lain, masing-masing menggunakan layanan mikro mereka sendiri. Hanya diperlukan sedikit upaya integrasi di bagian paling akhir (sesaat sebelum peluncuran). Faktanya, pendekatan ini sangat problematis. Dalam paragraf berikut kami akan mencoba menjelaskan alasannya.

“Potongan yang lebih kecil” tidak sama dengan “potongan yang lebih baik”

Merupakan kesalahan besar jika berasumsi bahwa kode yang dibagi menjadi 20 bagian akan memiliki kualitas yang lebih tinggi daripada satu bagian utuh. Bahkan jika kami mengambil kualitas dari sudut pandang teknis semata, layanan individual kami mungkin masih menjalankan 400 kueri Hibernate untuk memilih pengguna dari database, melintasi lapisan kode yang tidak didukung. Sekali lagi, kita kembali ke kutipan Simon Brown: jika Anda gagal membangun monolit dengan benar, akan sulit membangun layanan mikro yang tepat. Seringkali sangat terlambat untuk membicarakan toleransi kesalahan dalam proyek layanan mikro. Sedemikian rupa sehingga terkadang menakutkan untuk melihat cara kerja layanan mikro di proyek nyata. Alasannya adalah pengembang Java tidak selalu siap mempelajari toleransi kesalahan, jaringan, dan topik terkait lainnya pada tingkat yang tepat. “Bagian” itu sendiri lebih kecil, tetapi “bagian teknis” lebih besar. Bayangkan tim layanan mikro Anda diminta untuk menulis layanan mikro teknis untuk masuk ke sistem database, 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;
    }
}

Sekarang tim Anda mungkin memutuskan (dan mungkin bahkan meyakinkan pebisnis) bahwa ini semua terlalu sederhana dan membosankan, daripada menulis layanan login, lebih baik menulis layanan mikro UserStateChanged yang sangat berguna tanpa implikasi bisnis yang nyata dan nyata. Dan karena beberapa orang saat ini memperlakukan Java seperti dinosaurus, mari kita tulis layanan mikro UserStateChanged di Erlang yang modis. Dan mari kita coba menggunakan pohon merah-hitam di suatu tempat, karena Steve Yegge menulis bahwa Anda harus mengetahuinya luar dalam untuk dapat diterapkan ke Google. Dari perspektif integrasi, pemeliharaan, dan desain secara keseluruhan, ini sama buruknya dengan menulis lapisan kode spageti di dalam satu monolit. Contoh yang dibuat-buat dan biasa? Ini benar. Namun, hal ini bisa terjadi dalam kenyataan.

Lebih sedikit bagian berarti lebih sedikit pemahaman

Maka secara alami muncul pertanyaan tentang memahami sistem secara keseluruhan, proses dan alur kerjanya, tetapi pada saat yang sama Anda, sebagai pengembang, hanya bertanggung jawab untuk mengerjakan layanan mikro terisolasi Anda [95: login-101: updateUserProfile]. Hal ini selaras dengan paragraf sebelumnya, namun bergantung pada organisasi Anda, tingkat kepercayaan, dan komunikasi, hal ini dapat menyebabkan banyak kebingungan, sikap acuh tak acuh, dan menyalahkan jika terjadi kerusakan yang tidak disengaja pada rantai layanan mikro. Dan tidak ada orang yang mau bertanggung jawab penuh atas apa yang terjadi. Dan ini sama sekali bukan soal ketidakjujuran. Faktanya, sangat sulit untuk menghubungkan bagian-bagian yang berbeda dan memahami tempatnya dalam gambaran keseluruhan proyek.

Komunikasi dan layanan

Tingkat komunikasi dan layanan sangat bervariasi tergantung pada ukuran perusahaan. Namun, hubungan umumnya jelas: semakin banyak, semakin bermasalah.

• Siapa yang menjalankan layanan mikro #47?
• Apakah mereka baru saja menerapkan versi layanan mikro baru yang tidak kompatibel? Di mana hal ini didokumentasikan?
• Siapa yang perlu saya ajak bicara untuk meminta fitur baru?
• Siapa yang akan mendukung layanan mikro di Erlang, setelah satu-satunya orang yang mengetahui bahasa ini meninggalkan perusahaan?
• Semua tim layanan mikro kami bekerja tidak hanya dalam bahasa pemrograman yang berbeda, tetapi juga di zona waktu yang berbeda! Bagaimana kita mengoordinasikan semua ini dengan benar?

Poin utamanya adalah, seperti halnya DevOps, pendekatan menyeluruh terhadap layanan mikro di perusahaan besar, bahkan mungkin internasional, menimbulkan banyak masalah komunikasi tambahan. Dan perusahaan harus serius mempersiapkan hal ini.

kesimpulan

Setelah membaca artikel ini, Anda mungkin berpikir bahwa penulisnya adalah penentang keras layanan mikro. Ini tidak sepenuhnya benar - pada dasarnya saya mencoba menyoroti poin-poin yang hanya sedikit orang perhatikan dalam perlombaan gila-gilaan untuk mendapatkan teknologi baru.

Layanan mikro atau monolit?

Menggunakan layanan mikro Java kapan saja, di mana saja adalah salah satu hal yang ekstrem. Yang lainnya ternyata seperti ratusan modul Maven tua yang bagus dalam sebuah monolit. Tugas Anda adalah menemukan keseimbangan yang tepat. Hal ini terutama berlaku untuk proyek-proyek baru. Tidak ada yang dapat menghentikan Anda untuk mengambil pendekatan “monolitik” yang lebih konservatif dan membuat lebih sedikit modul Maven yang bagus, daripada memulai dengan dua puluh layanan mikro yang siap untuk cloud.

Layanan mikro menghasilkan kompleksitas tambahan

Perlu diingat bahwa semakin banyak layanan mikro yang Anda miliki dan semakin lemah DevOps yang Anda miliki (tidak, menjalankan beberapa skrip Ansible atau menerapkan ke Heroku tidak dihitung!), semakin banyak masalah yang akan Anda hadapi nantinya dalam proses tersebut. Bahkan hanya membaca sampai akhir bagian panduan yang didedikasikan untuk pertanyaan umum tentang layanan mikro Java ini adalah tugas yang cukup membosankan. Pikirkan baik-baik tentang penerapan solusi untuk semua masalah infrastruktur ini dan Anda akan tiba-tiba menyadari bahwa yang terpenting bukan lagi tentang pemrograman bisnis (untuk melakukan apa Anda dibayar) melainkan tentang memperbaiki lebih banyak teknologi pada lebih banyak teknologi. Shiva Prasad Reddy merangkumnya dengan sempurna di blognya : “Anda tidak tahu betapa buruknya ketika sebuah tim menghabiskan 70% waktunya berjuang dengan infrastruktur modern ini dan hanya 30% waktunya tersisa untuk melakukan logika bisnis yang sebenarnya. Siwa Prasad Reddy

Apakah layak membuat layanan mikro Java?

Untuk menjawab pertanyaan ini, saya ingin mengakhiri artikel ini dengan teaser mirip wawancara Google. Jika Anda mengetahui jawaban atas pertanyaan ini berdasarkan pengalaman, meskipun tampaknya tidak ada hubungannya dengan layanan mikro, Anda mungkin siap untuk pendekatan layanan mikro.

Skenario

Bayangkan Anda memiliki monolit Java yang berjalan sendiri di server khusus Hetzner terkecil . Hal yang sama berlaku untuk server database Anda, server ini juga berjalan pada mesin Hetzner yang serupa . Dan asumsikan juga bahwa monolit Java Anda dapat menangani alur kerja, misalnya pendaftaran pengguna, dan Anda tidak membuat ratusan kueri database per alur kerja, namun jumlah yang lebih masuk akal (<10).

Pertanyaan

Berapa banyak koneksi basis data yang harus dibuka monolit Java (kumpulan koneksi) di server basis data Anda? Mengapa demikian? Menurut Anda, berapa banyak pengguna aktif secara bersamaan yang dapat (kurang-lebih) ditingkatkan oleh monolit Anda?

Menjawab

Tinggalkan jawaban Anda atas pertanyaan-pertanyaan ini di bagian komentar. Saya menantikan semua jawabannya. Sekarang ambil keputusan. Jika Anda membaca sampai akhir, kami sangat berterima kasih kepada Anda!