304

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.36 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).

305

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.101. Untuk penelitian disertasi, perlu

modifikasi system transaksi tiket online untuk antrian pelayanan kekayaan

intelektual. Server yang dipakai di data center kampusnya atau server sendiri.

306

Seperti yang ditunjukkan pada gambar 2.102, 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.37 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.37, ketika API Call dibuat, waktu eksekusi API rerata struktur yang

dikonversi ke layanan mikro lebih cepat dalam kebanyakan iterasi daripada

struktur monolitik. Gambar 2.103 membandingkan total waktu eksekusi rerata

API untuk setiap iterasi. Seperti yang ditunjukkan pada Gambar 2.103, dalam

kasus monolitik, dapat dilihat bahwa waktu eksekusi meningkat dengan cepat

307

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.

308

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.104 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

309

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.

310

Tabel 2.38 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.

311

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.39.

312

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.

313

Jumlah pengukuran gabungan dari desain Chen et al. dihitung sebagai

13,5, sebagaimana dinyatakan dalam tabel 2.40.

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.41.

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.

314

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

315

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

316

mengelola operasi container 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

317

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.