Melanjutkan studi tentang topik layanan mikro , kami memutuskan untuk menawarkan terjemahan artikel tentang pengujian MOA (aplikasi berorientasi layanan mikro). Baru-baru ini, kami telah membahas topik pengujian , tetapi untuk layanan mikro, pengujian unit biasa saja tidak cukup, Anda juga perlu mempertimbangkan aspek-aspek yang terkait dengan CI / CD dan hal-hal lain yang akan dibahas dalam artikel ini.
Layanan mikro adalah gaya baru arsitektur perangkat lunak yang digunakan dalam pembuatan sistem terdistribusi dan semakin banyak diterapkan di perusahaan yang beroperasi di Web, termasuk yang terbesar. Misalnya, Netflix dan Amazon telah mengadopsi arsitektur layanan mikro untuk mempercepat peluncuran produk perangkat lunak secara signifikan. Pada saat yang sama, sistem monolitik yang lebih tua tidak dapat menskalakan dengan kecepatan yang dapat memenuhi tantangan modern.
Tetapi manfaat yang dapat dibawa oleh arsitektur layanan mikro hanya sebaik praktik terbaik untuk mendukungnya dapat diuji. Saat merancang pengujian untuk memvalidasi sistem layanan mikro, di mana kecepatan rilis dapat digambarkan secepat kilat, diperlukan pemikiran inovatif, baik di tingkat mikro maupun makro.
Selanjutnya, kita akan menjelajahi tiga jenis aplikasi berorientasi layanan mikro, membahas beberapa tantangan yang perlu Anda tangani untuk mengujinya, dan berbicara tentang bagaimana pengujian ditulis untuk sepenuhnya menghargai manfaat layanan mikro.
Secara singkat tentang layanan mikro
Sebelum kita membahas beberapa seluk-beluk mendesain tes untuk layanan mikro, mari kita lihat apa itu layanan mikro. Microservice adalah komponen perangkat lunak terperinci yang telah diberi definisi semantik yang jelas; namun, layanan mikro membawa kumpulan datanya sendiri dan tidak bergantung pada struktur data dan sumber data lain. Setiap layanan mikro memiliki siklus penerapannya sendiri, jadi setelah perubahan dilakukan pada layanan mikro, Anda dapat melepaskannya tanpa mengganggu pekerjaan layanan mikro lain dalam cakupan aplikasi yang menjalankan layanan mikro ini.
Keuntungan layanan mikro dibandingkan aplikasi monolitik
Juga, mari kita lihat apa yang bukan layanan mikro. Gambar berikut menunjukkan contoh aplikasi monolitik biasa.
Angka: 1: Arsitektur aplikasi monolitik biasanya memiliki kohesi komponen yang kuat
Komponen Pelanggan, Produk, Pesanan, dan (Komentar) dapat dianggap sebagai sekumpulan kelas yang ditulis dalam bahasa berorientasi objek seperti Java atau C #, di mana pelanggan adalah larik objek yang sesuai dengan pelanggan, produk - larik objek yang sesuai dengan produk, dll. Objek pelanggan dapat menggunakan objek pelanggan dan objek produk. Atau, karena fakta bahwa semua komponen aplikasi monolitik mengakses database yang sama, objek pesanan dapat mengakses database secara langsung dan mendapatkan semua informasi tentang produk dan pesanan yang diperlukan untuk menyelesaikan tugas. Akses langsung ke database tidak hanya mungkin - dan seberapa besar kontradiksi dengan semangat pemrograman berorientasi objek berdasarkan pemetaan relasional objek ORM - tetapi juga aktif digunakan, terutama di area di mana ada permintaan tinggi untuk fitur siap pakai pada tanggal yang disepakati, tidak peduli berapa biayanya.
Hasilnya adalah sistem yang berpasangan erat, terkadang rapuh, di mana merilis versi baru aplikasi memerlukan koordinasi yang signifikan di antara semua tim pengembangan yang terlibat dalam pengembangan sistem tersebut. Karena kopling yang kuat, seluruh siklus rilis tidak dapat berjalan lebih cepat daripada pekerjaan yang paling lambat dalam menegosiasikan ulang sebuah dependensi. Dengan kata lain, jika sudah waktunya untuk memperbarui aplikasi dan menambahkan fitur baru oleh pelanggan dan fitur baru oleh produk ke dalamnya, maka rilis tidak akan berlangsung hingga kedua fitur ini siap. Jika perlu satu hari untuk membuat pembaruan produk dan tiga minggu untuk membuat pelanggan berubah, maka rilis akan dilakukan tidak lebih awal dari tiga minggu. Selain itu, yang semakin memperburuk situasi, selama rilis, mungkin perlu tidak hanya untuk mengoordinasikan kode baru mengenai pelanggan dan barang,tetapi juga membuat perubahan pada skema database, dan ini juga harus dikelola selama proses rilis.
Merilis perubahan ke database adalah pekerjaan yang sangat rumit. Selalu ada risiko efek samping yang tidak diinginkan saat mengubah struktur database. Ingatlah bahwa jika ada komponen yang dapat mengakses database, maka ia akan mengaksesnya, dan bahkan melakukan operasi pada data yang tidak berada dalam cakupan komponen ini. "Manipulasi di luar area" seperti itu dapat menyebabkan kegagalan komponen lain, dan kegagalan semacam itu dapat luput dari perhatian hingga terjadi bencana. Terkadang potensi bahaya dapat ditemukan di kode hingga kode ini dirilis ke dalam produksi. Sayangnya, ini selalu terjadi.
Beberapa perusahaan bersedia bertahan dengan siklus rilis lambat yang biasa digunakan untuk bekerja dengan aplikasi monolitik. Namun, jika kita berbicara tentang perusahaan yang menyediakan dukungan untuk ratusan ribu pengguna, dan pada saat yang sama harus memelihara ribuan komponen dalam bentuk kerja, maka langkah "tidak lebih cepat daripada rilis komponen paling akhir" tidak dapat diterima .
Aplikasi berorientasi layanan mikro
Dalam aplikasi berorientasi layanan mikro (MOA), setiap komponen fungsional diuraikan menjadi unit sekecil mungkin dengan fungsionalitas yang diucapkan (dalam batas yang wajar). Dalam hal ini, setiap komponen fungsional tersebut diatur sebagai layanan mikro. Setiap perusahaan memiliki bagasi kode warisannya sendiri, serta budaya perusahaan yang harus dipegang teguh, sehingga tidak mungkin untuk menulis "seperti catatan" bagaimana tepatnya dekomposisi harus dilakukan.
Ketika berbicara tentang penguraian aplikasi monolitik di MOA, kunci untuk diingat adalah bahwa yang terbaik adalah musuh kebaikan. Pastikan bahwa setiap layanan mikro disusun sesuai dengan definisi semantiknya, bahwa layanan mikro memiliki datanya dan siklus rilisnya sendiri. Kedalaman implementasi tergantung pada kemampuan perusahaan, berdasarkan waktu yang tersedia, pengalaman karyawan, dan sumber daya yang tersedia. Beberapa layanan mikro mungkin hanya memiliki satu fungsi, yang lain mungkin memiliki banyak fungsi.
Ada tiga jenis MOA : sinkron , asinkron, dan hibrid .
Aplikasi berorientasi layanan mikro sinkron
Gambar 2 menunjukkan MOA sinkron. Komunikasi antar-layanan adalah prinsip respons-permintaan yang khas dari interaksi HTTP di web.
Gambar 2: Aplikasi Berorientasi Layanan Mikro Berdasarkan Komunikasi Antar Layanan Sinkron
Setiap layanan mikro tersegmentasi di belakang server HTTP, yang memungkinkan akses ke logika layanan mikro ini. Sebuah layanan mikro tertentu hanya mengetahui area tanggung jawabnya sendiri; ia mungkin juga mengetahui antarmuka untuk berinteraksi dengan layanan mikro lain, tetapi ia tidak dapat melihat logika internal layanan lain. Selain itu, layanan mikro hanya mengetahui datanya sendiri. Penyimpanan data layanan mikro lain tidak dikenalnya dan tidak tersedia untuknya. Tidak mungkin untuk "membajak" data layanan mikro lain dengan langsung mengakses gudang data untuk itu. Satu-satunya cara untuk mendapatkan data dari layanan mikro dan mentransfer data baru ke sana adalah dengan berinteraksi dengannya melalui antarmuka publik.
Di antara keuntungan MOA sinkron adalah kemandiriannya. Misalnya, layanan mikro Pelanggan yang ditunjukkan di atas dapat diperbarui kapan saja sesuai. Tidak ada ketergantungan eksternal yang perlu disesuaikan dengan ini. Selama layanan mikro tidak mengubah antarmuka publiknya, serta struktur data yang ingin dikonsumsi dari permintaan dan pengembalian sebagai respons, risiko kerusakan seluruh arsitektur MOA minimal.
Pada dasarnya, arsitektur MOA sedemikian rupa sehingga mempertahankan integritas strukturalnya sendiri. Karena layanan mikro itu sendiri membawa datanya sendiri, pekerjaannya tidak memengaruhi penyimpanan data layanan lain. Karena layanan mikro direpresentasikan sebagai sekumpulan URL HTTP dan struktur data terkait, yang dibangun berdasarkan prinsip respons-permintaan, batas antarmuka layanan mikro ditentukan dengan jelas.
MOA sinkron menjadi semakin populer. Banyak antarmuka MOA sinkron yang didasarkan pada paradigma REST, sebuah gaya yang telah ada sejak tahun 2000di tahun ini. Tapi, untuk semua popularitasnya, MOA memiliki kekurangan: kecepatan rendah. Konsumen layanan mikro sinkron tidak akan pernah berjalan lebih cepat daripada layanan mikro ini yang dapat menangani permintaan dan tanggapan. Ini bisa menjadi penghambat utama, terutama saat berhadapan dengan layanan mikro, yang prosesnya membutuhkan waktu lama untuk dijalankan. Contohnya adalah layanan analitik kompleks yang mengkonsumsi dan memproses terabyte data. Beberapa pelanggan akan setuju untuk duduk dan menunggu beberapa menit berturut-turut sampai layanan ditutup. Akan lebih mudah untuk memberi tahu layanan mikro pekerjaan apa yang perlu dilakukan dan kemudian diberi tahu ketika hasilnya sudah siap.
Dalam situasi seperti ini, akan lebih mudah untuk mengambil pendekatan asinkron untuk mendesain layanan mikro.
Aplikasi berorientasi layanan mikro asinkron
Gambar 3 di bawah ini menunjukkan implementasi MOA asynchronous, di mana komunikasi layanan-ke-layanan disediakan dengan bertukar pesan antara pihak-pihak yang terlibat. Biasanya, interaksi ini disebut “api dan lupakan”.
Gambar 3: Arsitektur MOA asinkron didasarkan pada perpesanan.
Dalam arsitektur MOA asinkron, pesan dapat dibuat secara acak, atau sebagai respons terhadap peristiwa tertentu. Misalnya, ketika (seperti yang ditunjukkan pada gambar di atas) pesanan dibuat di layanan mikro Pesanan, layanan ini dapat menerbitkan acara
orders_created
dan menempatkannya dalam antrian pesan pendamping ., yang mendengarkan layanan mikro lain, penagihan (tidak ditampilkan dalam gambar) dan menerima pesan masuk. Layanan mikro penagihan mengambil pesan informasi pesanan dan memprosesnya dengan cara yang relevan dari perspektif penagihan.
Keuntungan dari pendekatan asinkron untuk merancang aplikasi berorientasi layanan mikro adalah tidak ada hambatan dalam sistem seperti itu dan, oleh karena itu, sangat efisien. Kerugiannya adalah bahwa sistem seperti itu sangat sulit dibuat dan kemudian dikelola.
Untuk sistem asinkron skala besar seperti Uber, itu normal untuk memproses ribuan pesan per detik. Men-debug sistem seperti itu sulit karena alur kerjanya tidak memiliki lintasan yang jelas. Ini bukan tentang melakukan satu tindakan terlebih dahulu dan kemudian melakukan tindakan lainnya; logika dipicu tergantung pada pesan yang diterima, yaitu, apa pun bisa terjadi kapan saja.
Ini harus diingat saat mengembangkan strategi pengujian. Misalnya, sistem asinkron tidak praktis, yang kinerjanya bergantung pada permintaan dan waktu respons, karena tidak akan pernah ada korespondensi satu-ke-satu "satu permintaan-satu respons".
Aplikasi berorientasi layanan mikro hybrid
Pendekatan seimbang untuk mengimplementasikan aplikasi berorientasi layanan mikro adalah hibrid. Layanan secara bersamaan sinkron, yaitu, komunikasi respons-permintaan langsung didukung di antara mereka, dan pada saat yang sama tidak sinkron; artinya, beberapa pesan dibuat sehubungan dengan atau sebagai hasil dari perpesanan sinkron.
Gambar 4 mengilustrasikan pola komunikasi yang digunakan dalam pendekatan hybrid untuk aplikasi berorientasi layanan mikro. Layanan mikro Pelanggan direpresentasikan sebagai URL yang terkait dengan server HTTP dan sebagai antrian di perantara pesan.
Gambar 4: Pendekatan hybrid untuk merancang aplikasi berorientasi layanan mikro yang menggunakan opsi komunikasi sinkron dan asinkron antara layanan dan konsumen.
Anda dapat menambahkan klien ke layanan mikro menggunakan komunikasi respons permintaan HTTP standar. Permintaan diterima dan diproses, kemudian tanggapan dibuat. Namun, sebelum tanggapan dibuat, pesan dengan informasi tentang klien baru diterbitkan ke antrian pesan pendamping sehingga layanan lain yang tertarik dapat menggunakannya. Informasi yang dikirim ke antrian pesan bisa sama dengan yang dihasilkan dalam respons HTTP, atau sedikit berbeda, sesuai kebijaksanaan layanan mikro. Itu semua tergantung pada bagaimana layanan mikro dirancang dan perjanjian QoS yang harus diberlakukan oleh layanan mikro.
GraphQLAdalah teknologi API yang mendukung komunikasi sinkron dan asinkron antara konsumen dan layanan. Pelajari lebih lanjut tentang teknik ini dan langganan GraphQL di sini .
Ciri terpenting dari pendekatan hibrida adalah bahwa ia menggabungkan keunggulan dari dua pendekatan lainnya. Namun ada kerugian yang menyertai, khususnya, potensi hambatan yang mengurangi kinerja, dan kompleksitas tambahan yang terkait dengan kebutuhan untuk mendukung dua jenis antarmuka yang berbeda secara fundamental yang digunakan oleh layanan mikro "masuk" dan "keluar".
Kesulitan muncul saat mendesain pengujian untuk layanan mikro
Dalam hal pengujian aplikasi semacam itu, hal pertama yang harus diingat adalah bahwa sangat jarang satu layanan mikro dapat digunakan bersama oleh beberapa MOA. Biasanya, layanan mikro adalah salah satu dari banyak layanan di domain tertentu dalam aplikasi. Keunggulan pendekatan berorientasi layanan mikro untuk desain arsitektur aplikasi adalah transfer kode yang lebih cepat ke dan dari produksi. Netflix, misalnya, memiliki lebih dari 4.000 penerapan per hari .) Tingkat rilis ini tidak mungkin dilakukan dalam lingkungan aplikasi monolitik tradisional.
Juga harus diingat bahwa pengujian Kementan harus dilakukan di tingkat mikro dan makro.
Pengujian tingkat mikro
Di tingkat mikro, setiap layanan harus diuji secara menyeluruh dalam area tanggung jawabnya. Menurut beberapa interpretasi, suatu fungsi dianggap sebagai batas layanan mikro.
Melampaui pengujian unit tradisional
Disarankan untuk memberi perhatian khusus pada fungsi dalam layanan mikro, mengingat semakin populernya paradigma tanpa server , yang menurutnya layanan mikro hanya boleh disajikan sebagai fungsi tunggal. Tetapi banyak penguji yang berlatih cenderung membatasi diri pada pengujian unit saat bekerja dengan layanan mikro. Meskipun pengujian unit biasanya mencakup satu fungsi yang berfungsi di lingkungan pengujian yang sangat terbatas, layanan mikro dirancang untuk melayani audiens di seluruh web. Oleh karena itu, kondisi pengujian haruslah ekstrim.
Misalnya, sebagai bagian dari pengujian tingkat mikro yang baik, Anda dapat menjalankan seratus ribu contoh layanan mikro pada saat yang sama dan melihat bagaimana perilakunya pada skala tersebut. Tidaklah cukup hanya menguji satu fungsi pada satu waktu dengan menerapkan pengujian unit tunggal padanya. Anda perlu menjalankan pengujian semacam itu pada ribuan contoh fungsi pada saat yang sama, dengan mempertimbangkan indikator lingkungan hosting tempat Anda harus bekerja.
Uji unit penerapan Anda
Bersamaan dengan pengujian fungsionalitas layanan mikro, Anda juga perlu berhati-hati dalam menguji unit penerapan tempat layanan mikro dirilis. Biasanya, layanan mikro di-deploy sebagai container sebagai bagian dari teknologi orkestrasi seperti Kubernetes atau Docker Swarm . Aspek penting dari orkestrasi container adalah memastikan ketahanan jangka panjang dari layanan mikro.
Dipercaya bahwa layanan mikro dapat gagal karena berbagai alasan, baik karena kegagalan host maupun karena kesalahan dalam layanan mikro itu sendiri. Sangat normal bahwa selama pengoperasian ribuan kontainer secara bersamaan, terjadi beberapa jenis kerusakan saat ini. Pentingnya pengujian adalah bahwa jalan keluar yang benar dari layanan mikro dari game tidak kalah pentingnya dengan fungsinya yang benar. Tes tingkat mikro memastikan bahwa layanan mikro akan hidup kembali dengan rapi dan mati dengan rapi, di semua skala sistem.
Pastikan bahwa semua yang terjadi pada Anda benar-benar dicatat
Pengujian juga harus memastikan bahwa semua peristiwa penting yang terjadi di layanan mikro dicatat dengan benar - dan yang sama pentingnya, entri log ini dapat dipahami. Dalam dunia layanan mikro, logging sangat penting, terutama untuk MOA asinkron di mana tidak ada eksekusi perilaku yang berurutan. Seringkali, hanya data log yang akan membantu Anda memahami apa yang terjadi dalam aplikasi.
Pengujian makro
Apakah MOA itu sinkron, asinkron, atau hibrid, itu ditampilkan mode pengujian yang ketat. Saat menguji layanan mikro di tingkat makro, Anda perlu memastikan bahwa ada dua aspek yang memuaskan: komunikasi antar-layanan dan proses penerapan.
Memastikan komunikasi antar layanan yang cerdas
Microservices secara definisi tidak tergantung satu sama lain. Mereka menentukan apa yang harus dilakukan berdasarkan informasi yang mereka terima, sehingga keakuratan komunikasi antar-layanan sangat penting untuk operasi holistik dari aplikasi yang berorientasi pada layanan mikro.
Menyediakan komunikasi antar-layanan berarti memastikan bahwa informasi yang benar datang ke mana ia harus pergi dan kemana perginya. Tes harus dapat melacak bagaimana pesan dipertukarkan dan bagaimana mereka diproses. Hal ini berlaku untuk komunikasi respons permintaan HTTP dan pertukaran pesan asinkron yang disebarkan melalui perantara pesan. Pengujian harus membantu memastikan bahwa format pesan didukung untuk memastikan jalur sistem yang positif., dan pesan dengan format yang salah ditolak, dan dengan penjelasan yang memadai (dan tidak hanya dengan kesalahan "pesan buruk").
Menguji Integrasi Berkelanjutan dan Penerapan Berkelanjutan
Proses integrasi berkelanjutan dan penerapan berkelanjutan (CI / CD) yang terorganisir dengan baik sangat penting dalam paradigma pengembangan perangkat lunak apa pun, tetapi dalam hal aplikasi layanan mikro, proses CI / CD yang efisien, akurat, dan cepat sangat penting. MOA dapat direvisi dengan kecepatan ratusan pembaruan setiap hari, sehingga layanan mikro tunggal yang terlambat dibangun dapat menjadi penghambat dan memperlambat seluruh proses rilis.
Cara terbaik untuk bermain aman adalah dengan memberikan pengujian pipeline CI / CD dengan prioritas yang sama seperti mode pengujian tingkat tinggi lainnya. Mengidentifikasi dan memperbaiki masalah seperti layanan mikro build yang lambat karena artefak dalam kode, penyediaan waktu proses yang lambat di mana layanan mikro dihosting, dan peningkatan lambat dari layanan mikro yang sudah diterapkan merupakan prasyarat untuk pipeline CI / CD yang sehat. Bahkan jika layanan mikro serumit pesawat ulang-alik, itu akan sedikit berguna jika Anda tidak dapat dengan cepat menyebarkan dan menyebarkan unit operasional.
Kesimpulan
Layanan mikro adalah wildcard yang sebenarnya. Aplikasi berorientasi layanan mikro memberikan fleksibilitas dan kecepatan yang diperlukan untuk menghadirkan fitur-fitur baru secara online dengan kecepatan yang hampir secepat kilat. Perusahaan besar yang mendukung jutaan pengguna telah mempelajarinya hari ini, tetapi setiap hari semakin banyak perusahaan yang mengadopsi gaya arsitektur ini saat aplikasi mereka mencapai skala seluruh web.
Sementara banyak perusahaan yang secara serius mencoba untuk memasukkan semangat arsitektur berorientasi layanan mikro ke dalam proses pengembangan mereka, MOA ini sering diuji menggunakan praktik yang awalnya ditujukan untuk aplikasi monolitik. Ini adalah pendekatan cupet.
Sebaliknya, perusahaan harus mempelajari teknik pengujian modern yang dirancang untuk memastikan independensi layanan mikro dan kelincahan aplikasi yang menggunakan layanan mikro ini. Saat tim pengembangan dan penguji berhasil menyinkronkan prinsip di balik perancangan aplikasi layanan mikro, seluruh perusahaan dapat lebih mengandalkan kekuatan layanan mikro.