2

AJ. Evaluasi Metode Konstruksi Layanan Mikro

Dianalisis fitur yang membedakan dan keuntungan dari metode konstruksi mikrolayanan yang dibandingkan dengan metode terkait yang ada dan juga mengevaluasi mereka dalam hal kegunaan ulang.

Analisis komparatif dengan metode terkait. Tabel 2.35 meringkas evaluasi metode konfigurasi mikrolayanan yang ada dan metode konfigurasi mikrolayanan yang diusulkan sesuai dengan kriteria yang disebutkan. Kriteria didefinisikan dengan mengacu pada standar konfigurasi microservice. Microservice didefinisikan untuk beroperasi secara mandiri (kemandirian), komunikasi antarmuka mikrolayanan disertakan (antarmuka), kemampuan bisnis dilakukan, dan elemen data independen disertakan (penyimpanan data).

Penelitian terkait telah menunjukkan bahwa microservice dapat memiliki konfigurasi independen, tetapi tidak dapat dengan jelas dikonfirmasi apakah memiliki logika bisnis tunggal atau apakah itu dapat memiliki logika bisnis tunggal tetapi tidak menjadi konfigurasi independen. Namun, metode yang diusulkan melakukan konfigurasi independen dan logika bisnis tunggal dan diklasifikasikan sebagai 3-tier. Dengan demikian, dapat memiliki kedua elemen antarmuka dan elemen database yang terkait dengan input /output pada saat yang sama.

Evaluasi kinerja. Untuk evaluasi kinerja, diterapkan kode monolitik "sistem transaksi tiket online" dan kode berbasis microservices sesuai dengan metode yang diusulkan, masing-masing, pada host yang sama, seperti diilustrasikan pada Gambar 2.67. Untuk penelitian disertasi, perlu modifikasi system transaksi tiket online untuk antrian pelayanan kekayaan intelektual. Server yang dipakai di data center kampusnya atau server sendiri.

Seperti yang ditunjukkan pada gambar 2.68, waktu eksekusi API diukur setelah penyebaran aplikasi ke setiap lingkungan. diukur 10, 20, 50, 100, 250, 500, dan 1000 iterasi dari masing-masing monolitik dan layanan mikro yang diimplementasikan pada interval kedua 0,1 untuk mengukur nilai maksimum, minimum, dan rata-rata waktu respons untuk panggilan API.

Tabel 2.36 menunjukkan biaya panggilan API untuk implementasi monolitik dan microservice. Waktu eksekusi yang lebih sedikit berarti throughput yang lebih tinggi untuk aplikasi. Seperti yang ditunjukkan pada Tabel 2.36, ketika API Call dibuat, waktu eksekusi API rerata struktur yang dikonversi ke layanan mikro lebih cepat dalam kebanyakan iterasi daripada struktur monolitik. Gambar 2.69 membandingkan total waktu eksekusi rerata API untuk setiap iterasi. Seperti yang ditunjukkan pada Gambar 2.69, dalam kasus monolitik, dapat dilihat bahwa waktu eksekusi meningkat dengan cepat pada 500 iterasi dan seterusnya. Sebaliknya, dalam kasus Layanan mikro berdasarkan metode yang disajikan dalam makalah ini, dapat dilihat bahwa kinerja stabil pada 500 iterasi dan 1000 iterasi. Untuk kasus kantor kekayaan intelektual, tentu iterasi tidak sebanyak itu. Juga tiap iterasi tergantung bobot pelayanan yang sedang diakses, untuk kekayaan hak cipta tentu beda dengan kekayaan paten.

Evaluasi penggunaan kembali. Sebuah aplikasi yang terdiri atas unit microservice dapat secara individual diperbarui tanpa mengetahui struktur internal microservices lain. Hal ini karena layanan mikro memiliki usabilitas tinggi dibandingkan dengan struktur monolitik.

Diukur metrik usabilitas dari layanan mikro dibangun dengan menerapkan metode yang diusulkan dan metode terkait untuk aplikasi monolitik yang sama. Kohesi dan kopling diukur sebagai metrik usabilitas; kohesi tinggi dan nilai kopling rendah menunjukkan reusability tinggi.

Gambar 2.70 menunjukkan hasil penerapan data desain "sistem transaksi tiket online" yang disajikan dalam studi kasus ke metode komposisi microservice berbasis DFD. Area bertitik merupakan layanan mikro yang dikonfigurasi dan terdiri atas total 9 (=8+1) unit microservice yang dikelompokkan ke dalam satu data dan proses.

Pengukuran metrik kegunaan ulang menggunakan metode penghitungan derajat kohesi dan kopling data desain yang dirancang oleh perangkat lunak berorientasi objek; metode penghitungan kohesi adalah sama seperti yang ditunjukkan dalam persamaan (1) dan (2).

S(M) adalah jumlah berat untuk metode M berdasarkan penampilan M dalam kelompok pohon subset. R(M) adalah nilai yang diperoleh dengan membagi nilai sampel dengan jumlah tertimbang dari kelompok atribut yang terhubung dengan metode; memiliki nilai sampel antara nol dan satu. TM adalah jumlah total metode dalam R(M) Kohesion (X) dihitung dengan rerata nilai sampel semua nilai R(M).

Dalam kasus Chen et al., atribut didefinisikan sebagai data, metode didefinisikan sebagai proses yang mengakses data, dan tingkat kohesi diukur. Dalam pendekatan ini, didefinisikan atribut sebagai entitas dan metode sebagai batas, juga didefinisikan kontrol yang mengakses entitas dan mengukur kohesi.

Dalam kasus kantor kekayaan intelektual, sudah ada system transaksi tiket online dari DJKI yang berposisi di URL https://loketvirtual.dgip.go.id/, kemungkinan besar monolitik. Peneliti tinggal merekonstruksi aplikasi tersebut dalam container-based microservices untuk skala Sentra KI.

Tabel 2.37 menunjukkan hasil perhitungan kohesi Layanan mikro dibangun melalui setiap metode konfigurasi. Dalam kasus Chen et al., sembilan kelompok mikrolayanan dibangun. Tentu hal ini berbeda jika dibandingkan Loket Virtual DJKI yang memiliki tujuh layanan dokumen, entah berapa kelompok microservices yang akan dibangun, akan ditemukan setelah dilakukan penelitian di DJKI.

Dalam kasus metode yang diusulkan, lima kelompok dibangun. Relasi dan nilai bobot grup yang terkait dengan grup yang dikonfigurasi dihitung. Masing-masing nilai R(M), yang merupakan hasil dari membagi nilai maksimum jumlah bobot grup dalam kelompok oleh hubungan, ditampilkan dalam Tabel 2.38.

Nilai rata-rata R(M) microservice dibangun melalui setiap metode konfigurasi dihitung. Tingkat kohesi microservice dibangun adalah 0,694, sedangkan mikrolayanan yang dibangun oleh metode yang diusulkan dihitung menjadi 0,823.

Persamaan (3) menunjukkan metode perhitungan untuk mengukur tingkat kopling antara kelas. A, D, dan I mewakili jumlah kelas Association, Dependency, dan relasi Inheritance, masing-masing. Semakin tinggi hubungan, semakin tinggi tingkat kopling antara kelas.

Lebih lanjut, a, b, dan c adalah konstanta non-deterministik, yang harus dipertimbangkan oleh pengembang atau perancang. Dalam kasus data desain monolitik, konstan a adalah 1 untuk koneksi langsung dan 0,5 untuk koneksi tidak langsung. Dalam kasus Chen et al., tingkat kopling antara proses data diukur. Dalam kasus Layanan mikro dibangun dengan menggunakan metode yang diusulkan, tingkat kopling antara entitas dan kontrol diukur.

Jumlah pengukuran gabungan dari desain Chen et al. dihitung sebagai 13,5, sebagaimana dinyatakan dalam tabel 2.39.

Di sisi lain, dalam kasus data desain microservice dibangun menggunakan metode yang diusulkan, sebagai hubungan langsung hubungan ev3-ev6, ev3-cv7, dan ev4-ev8 berubah menjadi koneksi tidak langsung oleh batas baru, itu dihitung sebagai 9,5, seperti yang dinyatakan dalam tabel 2.40.

Oleh karena itu, diukur kohesi dan kopling, yang merupakan faktor usabilitas dari layanan mikro yang dibangun oleh metode penelitian terkait dan metode yang diusulkan. Tabel 2.41 menunjukkan bahwa metode konfigurasi mikrolayanan yang diusulkan memiliki kohesi tinggi dan kopling rendah dan sangat dapat digunakan kembali.

Kesimpulan sementara. Telah disajikan sebuah metode untuk menganalisis data desain aplikasi monolitik dan membangun mereka sebagai unit microservice berbasis kontainer. Metodologi yang diusulkan melibatkan proses: analisis data desain monolitik, ekstraksi microservice, pelaksanaan microservice, dan penyebaran microservice.

Pada tahap analisis data desain monolitik, hal itu dikumpulkan dan diklasifikasikan ke dalam berbagai jenis. Dalam langkah ekstraksi mikrolayanan, grafik dibangun dengan menganalisis kelas dan Asosiasi; kemudian, sebuah microservice unit entitas diturunkan. Pada tahap pelaksanaan mikrolayanan, pelaksanaan layanan mikro dilakukan oleh lapisan. Akhirnya, dalam fase penyebaran microservice, dibuat skrip dukungan penyebaran yang dapat mengumpulkan elemen lingkungan penyebaran dan menyebarkan Layanan mikro di lingkungan kontainer berdasarkan elemen koleksi.

Studi kasus pada setiap langkah dari metode konstruksi mikrolayanan yang diusulkan, "sistem transaksi tiket online," yang merupakan aplikasi monolitik, dikonfigurasi sebagai unit microservice dan didistribusikan dan dioperasikan pada dasar kontainer. Selain itu, dengan membandingkan metode yang diusulkan dengan penelitian terkait dan mengevaluasi usabilitas dari layanan mikro yang dibangun, ditegaskan bahwa layanan mikro yang dikembangkan dalam studi ini lebih unggul dalam hal kegunaan kembali. Hal ini menjadi keyakinan Peneliti disertasi untuk mencoba melakukan hal yang sama pada aplikasi “Loket Virtual DJKI” URL https://loketvirtual.dgip.go.id/ dengan asumsi dia adalah aplikasi monolitik, akan dikonfigurasi unit micro services dengan pengguna adalah sentra kekayaan intelektual.

Jika metode konstruksi mikro yang diusulkan diterapkan pada aplikasi monolitik yang ada, dapat dikonfigurasi sebagai unit microservice berbasis kontainer dengan biaya rendah. Keuntungannya adalah bahwa, di lingkungan kontainer awal, pengguna tidak perlu secara manual menghasilkan skrip template; ia dapat menghasilkan skrip template melalui tabel pemetaan. Oleh karena itu, pengembangan lebih lanjut dari unit microservice di lingkungan komputasi tanpa server diharapkan di masa depan. Hal ini akan dicobakan pada aplikasi monolitik di suatu sentra kekayaan intelektual. Jika unit microservice sudah terbangun di sana. Diharapkan di sentra sejenis di tempat lain dapat memanfaatkan layanan mikro tersebut dengan sedikit penyesuaian.

Secara khusus, penelitian di masa mendatang (termasuk penelitian disertasi ini) akan fokus pada pengembangan alat Monitoring untuk mengelola operasi kontainer yang efisien setelah mendistribusikan Layanan mikro yang dibuat oleh metode yang diusulkan dan meningkatkan kinerja API Gateway untuk memecahkan masalah overhead jaringan antara layanan mikro.

Merancang aplikasi berbasis container dan microservice. Layanan mikro menawarkan manfaat besar tetapi juga meningkatkan tantangan baru yang besar (untuk diteliti). Pola arsitektur microservice adalah pilar mendasar ketika membuat aplikasi berbasis microservice. (Authors, 2020)

Perlu dipelajari konsep dasar tentang containers dan Docker sebagai informasi minimal yang diperlukan untuk memulai dengan containers. Containers adalah enablers dan great fit untuk micro services, meski pun mereka tidak wajib untuk arsitektur microservice dan banyak konsep arsitektur di bagian arsitektur ini dapat diterapkan tanpa kontainer juga.

Aplikasi perusahaan dapat menjadi kompleks dan sering terdiri atas beberapa layanan bukan hanya aplikasi berbasis layanan tunggal. Untuk kasus tersebut, Anda perlu memahami pendekatan arsitektur tambahan, seperti layanan mikro dan pola tertentu Domain-Driven Design (DDD) ditambah konsep orkestrasi container.

Prinsip desain container. Dalam model kontainer, contoh gambar kontainer mewakili satu proses. Dengan mendefinisikan gambar kontainer sebagai batas proses, Anda dapat membuat primitif yang dapat digunakan untuk skala proses atau untuk batch itu.

Ketika Anda merancang gambar container, Anda akan melihat definisi ENTRYPOINT dalam Docker-file. Ini mendefinisikan proses seumur hidup yang mengontrol seumur hidup dari kontainer. Setelah proses selesai, siklus hidup kontainer berakhir. Kontainer mungkin mewakili proses yang berjalan lama seperti server web, tetapi juga dapat mewakili proses jangka pendek seperti pekerjaan batch, yang sebelumnya mungkin telah diimplementasikan sebagai Azure WebJobs. Jika proses gagal, kontainer berakhir, dan orkestrator mengambil alih. Jika pengelola dikonfigurasi untuk menjaga lima contoh berjalan dan satu gagal, pengelola akan membuat contoh kontainer lain untuk mengganti proses gagal. Dalam pekerjaan batch, proses dimulai dengan parameter. Ketika proses selesai, pekerjaan selesai.

Anda mungkin menemukan skenario di mana Anda ingin beberapa proses berjalan dalam satu kontainer. Untuk skenario itu, karena hanya ada satu titik entri per-kontainer, Anda bisa menjalankan skrip dalam kontainer yang meluncurkan program sebanyak yang diperlukan. Sebagai contoh, Anda dapat menggunakan supervisor atau alat serupa untuk mengurus peluncuran beberapa proses di dalam satu kontainer. Namun, meskipun Anda dapat menemukan arsitektur yang memegang beberapa proses per-kontainer, pendekatan itu tidak terlalu umum.