265

AG. Pendekatan untuk Merekonstruksi Aplikasi guna Mengembangkan Container-based MicroServices

Layanan mikro adalah jasa skala kecil yang dapat beroperasi secara

mandiri. Sebuah aplikasi yang terdiri atas unit microservice dapat

dikembangkan secara independen sebagai unit layanan, dan dapat

menangani logika individu tanpa terpengaruh oleh layanan lainnya.

Dimungkinkan untuk dengan cepat mendistribusikan Layanan mikro

terkonfigurasi dengan container, dan teknologi orkestrasi kontainer yang

mengelola beberapa kontainer terdistribusi dapat diwujudkan; dengan

demikian, adalah mungkin untuk memperbarui dan mendistribusikan Layanan

mikro secara terpisah.

Oleh karena itu, banyak perusahaan yang bergerak (seharusnya

termasuk Sentra KI) menjauh dari struktur monolitik yang ada dan mencoba

untuk beralih ke microservices. Disajikan sebuah metode untuk

merekonstruksi aplikasi monolitik ke unit microservice berbasis container.

Mikrolayanan unit data diperoleh melalui pengumpulan dan analisis data

desain monolitik. Selain itu, diusulkan sebuah metode untuk menghasilkan

skrip template berdasarkan data desain Deployment sehingga turunan

microservice dan dukungan distribusi dapat diimplementasikan dalam

lingkungan kontainer.

266

Hasil studi kasus yang dilakukan memverifikasi bahwa layanan mikro

berbasis kontainer yang digunakan dalam studi ini bekerja dengan baik.

Untuk pengembangan aplikasi monolitik dan pengembangan layanan mikro

berbasis kontainer, ditegaskan bahwa pengembangan atas dasar layanan

mikro efisien dengan melakukan evaluasi kinerja waktu eksekusi untuk

panggilan API di berbagai iterasi. Layanan mikro dibangun dengan

menggunakan metode yang diusulkan memiliki usabilitas lebih tinggi dari

pada yang dibangun dengan menggunakan metode yang ada.

Komputasi tanpa server adalah model eksekusi di mana aplikasi

dikembangkan dan didistribusikan berdasarkan unit microservice tidak perlu

membangun infrastruktur terpisah dalam lingkungan awan. Saat ini,

perusahaan awan utama menyediakan teknologi komputasi tanpa server,

seperti Amazon AWS Lambda, Microsoft Azure functions, dan Google Cloud

Functions, untuk layanannya. Dengan 2018, komputasi tanpa server menjadi

Layanan Cloud yang berkembang pesat, dengan pertumbuhan yang

dilaporkan sekitar 75 % antara 2017 dan 2018 sesuai dengan "2018 State of

The Cloud Report" dari RightScale.

Sentra Kekayaan Intelektual berawal dari minimal dua orang yang

dipercaya kampus yang menaunginya, tanpa persiapan infrastruktur

pendukungnya, meski pun kampusnya sudah merintis infrastruktur dimaksud,

misalnya data center bagian dari teknologi informasi dan komunikasi yaitu

267

server, internet, intranet, dan lain-lain. Kesimpulannya sentra kekayaan

intelektual sudah memerlukan komputasi tanpa server yang dimilikinya

sendiri karena keterbatasan anggaran. Hal ini bisa diawali dengan mail server

dan web server, berlanjut hingga micro service architecture.

Pengembangan micro service architecture untuk data science dalam

technology and innovation support center (TISC) bisa mengacu pada

pengembangan platform [system] inovasi dan kewirausahaan (innovation

and entrepreneurship system, IES) karena inovasi yang menjadi kekayaan

intelektual (umumnya penemuan teknologi) perlu dikomersialkan dengan

jalan wira-usaha oleh sentra kekayaan intelektual.

Majalah Forbes telah menyarankan bahwa arsitektur tanpa server

akan menjadi salah satu dari sepuluh teknologi catatan selama lima tahun ke

depan sampai 2022, dan muncul sebagai generasi berikutnya paradigma

komputasi awan. Microservices, yang merupakan konsep inti komputasi

tanpa server, adalah layanan berskala kecil yang dapat beroperasi secara

independen. Aplikasi yang terdiri atas layanan mikro adalah kopling longgar

struktur dengan layanan mikro yang berbeda; oleh karena itu, pembaruan

individu mungkin tanpa mengetahui struktur internal aplikasi. Oleh karena itu,

struktur ini memiliki keuntungan yang cepat dikembangkan dan

didistribusikan dibandingkan dengan struktur monolitik yang ada dan sangat

dapat digunakan kembali.

268

Baru-baru ini, teknologi orkestrasi kontainer, seperti Kubernetes,

Docker Swarm, dan Mesosphere, telah muncul untuk mendukung

manajemen distribusi kontainer. Mereka cocok untuk manajemen fleksibel

dari skala besar aplikasi berbasis microservice karena mereka mengaktifkan

batch dan pembuatan kontainer otomatis serta manajemen distribusi

berbagai kontainer.

Karena keuntungan dari layanan mikro dan teknologi orkestrasi

kontainer, banyak perusahaan yang berusaha untuk mengadopsi mereka

sebagai alternatif untuk struktur aplikasi monolitik yang ada dalam rangka

mengembangkan dan mendistribusikan aplikasi berbasis microservice serta

untuk menyebarkan mereka pada dasar container. Penelitian berceritera

tentang cara mengkonfigurasi ulang aplikasi monolitik yang ada ke unit

microservice tetap terbatas.

Ada banyak pertimbangan, seperti ukuran microservice, konfigurasi

API, pemrosesan database, dan keamanan, tergantung pada ukuran layanan

ketika dimaksudkan untuk merekonstruksi struktur monolitik yang rumit

menjadi layanan mikro kecil dan independen. Struktur monolitik yang rumit

misalnya Lembaga Pengembangan Inovasi dan Kewirausahaan (LPIK) di

bawah Wakil Rektor (Bidang) Inovasi dan Kewirausahaan (WRIM) yang

mempunyai tujuan menjadi hub dan fasilitator menjembatani inovasi inventor

dan kewirausahaan untuk dapat berinteraksi dengan industry.

269

Interaksi itu menciptakan nilai (value co-creation) dan komersialisasi

teknologi. Interaksi dituangkan dalam aplikasi awal berbasis web yang

memfasilitasi hubungan antar pemangku kepentingan yang terlibat dalam

aktivitas LPIK secara efektif dan efisien.

Struktur monolitik yang rumit dalam aplikasi itu dibuat berdasarkan

kebutuhan para pengguna yaitu tenant incubator, industry, dan inventor.

Sudah pernah digunakan sudut pandang servis sains mulai dari identifikasi

hingga pengembangan solusi dari permasalahan dalam aplikasi

menggunakan metode pendekatan kualitatif focus group discussion, survey

serta pengolahannya menggunakan strategic assumption surfacing dan

testing (SAST). Hasilnya diperoleh asumsi-asumsi yang paling penting dan

paling pasti dalam pengembangan IES ke depan di sebagai berikut.

No. Asumsi Artinya1 relevansi Informasi yang disediakan pada laman IES harus

relevan.2 akurasi IES harus memiliki tingkat akurasi aplikasi yang

tinggi.3 kostumisasi IES harus menyediakan informasi yang menarik,

dan tampilan yang familiar.4 content Kelengkapan isi dan kualitas informasi web.5 timelines Informasi yang ditampilkan pada laman IES tepat

waktu dan sifatnya mutakhir6 format Mampu memberikan informasi sesuai yang

dibutuhkan.

270

Kualitas berinteraksi dengan pengelola /admin IES melalui forum

kolaborasi, kemudahan dalam menggunakan IES, serta layanan dan

kecepatan dalam menggunakan aplikasi. Beberapa penelitian menyebutkan

bahwa TIK merupakan komponen yang sangat penting dalam

pengembangan inovasi (Corso & Paolucci, 2001; Dewett & Jones, 2001; Xu,

Sharma, & Hackney, 2005).

Salah satu masalah adalah bahwa sulit untuk mengubah unit

microservice karena ukuran microservice tidak tetap. Selain itu, ada

parameter yang perlu didefinisikan secara manual untuk distribusi dan

manajemen berbasis kontainer, seperti nomor manajemen kontainer awal

dan konfigurasi jaringan, bahkan dalam kasus konfigurasi sebagai

microservice.

Mengkonversi aplikasi monolitik yang ada untuk layanan mikro

memerlukan pemahaman mendalam struktur aplikasi monolitik yang ada.

Oleh karena itu, metode untuk memperoleh layanan mikro berdasarkan

arsitektur perangkat lunak atau aliran data telah diusulkan. Berkembang

menjadi lingkungan pengembangan berorientasi objek, yang UML-(Unified

modeling Language-) aplikasi berbasis desain dan pendekatan

pembangunan sedang diadopsi. Ada kebutuhan untuk mengkonversi data

desain UML yang ada ke dalam layanan mikro berdasarkan aplikasi.

271

Untuk mengatasi masalah ini, disajikan metode yang menganalisis

data desain aplikasi monolitik dan merekonstruksi mereka ke dalam kontainer

berbasis microservices. Data desain UML diklasifikasikan dari aplikasi

monolitik dengan hirarki, membangun grafik yang dapat dikonversi menjadi

layanan mikro, dan memperoleh Layanan mikro dari unit entitas.

Berdasarkan Layanan mikro turunan dan data desain penyebaran,

metode untuk secara otomatis menghasilkan skrip template yang dapat

didistribusikan dan dikelola dalam lingkungan orkestrasi container diusulkan.

Selain itu, studi kasus dilakukan untuk memverifikasi validitas metode yang

diusulkan dan microservice dire-organisasi aktual ditunjukkan untuk

dikerahkan dan dieksekusi di lingkungan orkestrasi container. Akhirnya,

melalui perbandingan dan evaluasi, metode yang diusulkan ditunjukkan untuk

menjadi lebih unggul dari metode yang ada dalam hal kegunaan ulang.

Layanan mikro. Rademacher et al. menyelidiki fitur yang

membedakan dari layanan mikro dengan membandingkan konsep layanan

berorientasi arsitektur (SOA) yang ada. Mereka menjelaskan bahwa layanan

mikro lebih independen dari pada SOA dan bahwa ukuran mikro layanan

harus ditetapkan ke unit yang dapat dikembangkan oleh masing-masing tim

pengembangan. Mereka juga menunjukkan bahwa kopling antara layanan

mikro sangat rendah dan bahwa antarmuka sangat abstrak. Konsep

272

antarmuka digunakan dalam metode konstruksi, dan didefinisikan untuk

mendukung komunikasi antara pengguna dan layanan mikro.

Dragoni et al. menyarankan bahwa konfigurasi mikro layanan harus

terdiri atas unit yang membawa kemampuan bisnis tunggal. Jika unit

kemampuan bisnis besar, perlu dibagi menjadi dua atau lebih unit yang lebih

kecil, dan dalam microservices, database didefinisikan sebagai database

jenis terdistribusi daripada dibagi dalam cara terpusat. Didefinisikan

kemampuan bisnis sebagai entitas yang merupakan unit database.

Yu et al. mengusulkan model arsitektur referensi untuk membangun

lingkungan microservice di lingkungan perusahaan. Mereka diklasifikasikan

tiga jenis layanan mikro dalam model arsitektur yang diusulkan.

Antarmukanya terdiri atas: 1) (lapisan) input pengguna, 2) logika bisnis yang

memproses nilai input, dan 3) lapisan persistensi, yang berisi area data.

Diklasifikasi mikrolayanan menjadi presentasi, logika bisnis, dan lapisan

persistensi dengan menggunakan konsep tiga lapisan yang disajikan dalam

studi ini.

Metode konstruksi mikrojasa. Mustafa dan Marx G ́omez

mengusulkan sebuah metode untuk membangun Layanan mikro di

lingkungan runtime. Dalam metode yang diusulkan, setelah mengkonfigurasi

zona waktu yang sama sebagai satu sesi, sesi dipisahkan ketika ada banyak

273

akses dalam sesi tertentu. Namun, itu tidak dikonfirmasi apakah layanan

yang diakses sering jelas melakukan satu kemampuan bisnis.

Mazlami et al. mendefinisikan sebuah microservice sebagai unit

kelompok kelas di mana perubahan terjadi untuk tujuan yang sama. Mereka

membangun sebuah grafik di mana simpul sesuai dengan kelas dan tepi

memiliki berat sesuai dengan tingkat kesamaan perubahan antara kelas;

kemudian, mereka menerapkan algoritma Clustering yang menghilangkan

tepi berbobot rendah. Namun, tidak mungkin untuk memverifikasi jenis

layanan mikro diimplementasikan dibangun dalam penelitian terkait. Selain

itu, tidak mungkin untuk memverifikasi apakah unit kelompok kelas

sebenarnya dilakukan satu logika bisnis.

Chen et al. menganalisis data desain data flow diagram (DFD) untuk

aplikasi monolitik dan mendefinisikan sekelompok fungsi dan data output

sebagai unit microservice tunggal. Pada DFD yang ada, mereka

mendefinisikan aturan untuk setiap langkah dan menghubungkan data yang

terkait dengan fungsi yang melakukan satu kemampuan bisnis. Selain itu,

mereka membangun data DFD yang disempurnakan dan mengekstraksi

mereka ke dalam Layanan mikro. Namun, ketika diterapkan metode ini,

Layanan mikro sepenuhnya independen tidak dikonfigurasi karena data dapat

dikaitkan dengan fungsi lain.

274

Kontainer orkestrasi. Docker adalah sebuah wadah platform

perangkat lunak untuk membangun dan menyebarkan aplikasi dengan cepat

dalam bentuk container. Ini berjalan pada OS host tanpa dialokasikan OS

atau sumber daya terpisah, tidak seperti mesin virtual berbasis hypervisor

khas. Selain itu, aplikasi independen seperti mesin virtual dapat menjalankan

berbagai aplikasi. Docker dapat digunakan secara independen untuk setiap

aplikasi microservice, dan dapat mendorong aplikasi microservice yang

sangat efisien.

Masalah utama dengan Docker adalah bahwa ia tidak memiliki

kemampuan untuk mengelola siklus hidupnya ketika berhadapan dengan

sejumlah besar container. Untuk mengatasi masalah ini, konsep orkestrasi

container yang mendukung manajemen container dan Docker Swarm

dikembangkan. Docker swarm adalah perangkat lunak bersumber terbuka

yang mendukung orkestrasi kontainer di Docker. Klien dapat mengelola

Docker melalui Swarm Manager, dan Swarm Manager mengirimkan perintah

ke Docker daemon untuk menemukan dan menetapkan node yang sesuai

untuk membuat Container.

Kubernetes adalah platform orkestrasi kontainer open-source yang

awalnya dikembangkan oleh Google. Saat ini, vendor awan utama, seperti

AWS, IBM, dan Microsoft, menyediakan layanan awan bersama dengan

Kubernetes, yang menjadi standar de-facto. Struktur Kubernetes dapat dibagi

275

menjadi master dan simpul. Master mengelola beberapa node, dan sebuah

node membuat dan mengeksekusi kontainer aktual. Fungsi manajemen

container kubernetes dicapai melalui skrip template yang ditentukan dalam

format YAML atau JSON. Dalam Kubernetes, unit container adalah Pod yang

dapat dibuat dan dieksekusi dalam bentuk skrip template. ReplicaSet dapat

mengontrol Pod ini. Scheduler dapat mengelola dan memelihara beberapa

Pods menggunakan script template. Akhirnya, ada skrip template layanan

yang mendukung fungsi jaringan, sementara layanan klien jaringan eksternal,

seperti load balancing dan Service Discovery, dapat didukung dengan

menghubungkan container klien eksternal.

Kubernetes menggunakan file YAML yang mendefinisikan status yang

diinginkan untuk menerapkan sebuah aplikasi — misalnya, berapa banyak

port yang ingin diservis — dengan melampirkan label ke berbagai objek,

seperti Pods, ReplicaSets, Services, dan volume, dan melewatinya ke server

API. Dalam mekanisme internal Kubernetes untuk menciptakan Pod baru,

kontroler ReplicaSet disertakan dengan pengontrol Kube memonitor

ReplicaSet dan memeriksa apakah ada Pod yang memenuhi kondisi label

pemilih yang ditetapkan di ReplicaSet. Pod baru dibuat dengan

mengonfigurasi template Pod dan meneruskannya ke server API. Untuk

mendistribusikan Layanan mikro yang dibangun di lingkungan kontainer

276

Kubernetes, diusulkan metode yang secara otomatis menghasilkan file skrip

Pod, ReplicaSet, dan template layanan dari data desain monolitik.

Metode Rekonstruksi Mikro-Layanan Berbasis Kontainer. Proses

merekonstruksi mikrolayanan dengan menganalisis data desain monolitik

diuraikan dalam gambar berikut ini. Untuk merekonstruksi data desain

sebagai layanan mikro, dilakukan kegiatan rinci dalam empat langkah.

Penjelasan untuk setiap langkah adalah sebagai berikut.

Gambar 2.79. Proses rekonstruksi layanan mikro berbasis container.

Analisis data desain monolitik. Pada langkah ini, data desain

monolitik dari target rekonstruksi mikrolayanan dikumpulkan dan dianalisis.

Ini terdiri atas kegiatan berikut:

277

(i) Mengumpulkan data desain monolitik: jenis data desain yang

akan dikumpulkan adalah diagram kelas data desain UML yang

ditentukan oleh pola ECB {entity control boundary}. Tabel berikut

merangkum jenis dan contoh stereotip dalam data desain UML.

Tiga stereotip yang didefinisikan dalam tabel itu dikumpulkan.

(ii) Klasifikasikan Layer 3-tier: kelas yang didefinisikan sebagai

stereotip dikumpulkan dari data desain kelas UML dan

diklasifikasikan dalam hirarki 3-tier. Di sini, 3-tier menyiratkan

presentasi, logika bisnis, dan ketekunan.

(iii) Memetakan layer berdasarkan jenis kelas: hierarki 3-tier

didefinisikan, dan pemetaan hirarkis dilakukan. Stereotip adalah

sebagai berikut: jenis < <Boundary> > adalah lapisan presentasi,

jenis < <Control> > adalah lapisan logika bisnis, dan jenis <

<Entity> > adalah pemetaan untuk lapisan persistensi, seperti

yang ditunjukkan pada tabel di atas.

Ekstrak Microservice. Dalam langkah ekstraksi mikrolayanan, grafik

dibangun berdasarkan informasi kelas yang dikumpulkan dan diklasifikasikan

278

dalam langkah sebelumnya; kemudian, kegiatan berikut dilakukan untuk

memperoleh Layanan mikro dari unit entitas:

(i) Menganalisa hubungan kelas dan membangun Graf: sebuah

Graf yang dibangun terdiri atas simpul yang sesuai dengan sebuah

kelas dan tepi yang mewakili relasi pemanggilan.

(ii) Vertex diklasifikasikan dalam lapisan presentasi sesuai dengan

hubungan pemetaan yang ditunjukkan pada tabel di atas

didefinisikan sebagai simpul batas (dinyatakan sebagai "BV").

Simpul diklasifikasikan dalam Layer logika bisnis didefinisikan

sebagai simpul kontrol (dinyatakan sebagai "CV"). Simpul

diklasifikasikan dalam hirarki persistensi didefinisikan sebagai

simpul entitas (dinyatakan sebagai "EV").

(iii) Selain itu, hubungan panggilan antara kelas dalam data desain

UML diwakili sebagai tepi, seperti yang ditunjukkan pada tabel

berikut ini.

279

(iv) Generalisasi dan realisasi: dalam kaitannya dengan generalisasi

dan realisasi, kelas A adalah kelas induk, dan itu diwariskan atau

diimplementasikan. Oleh karena itu, kelas A mempengaruhi kelas

B dan menyebutnya.

(v) Ketergantungan dan keterkaitan: terkait dengan ketergantungan

dan Asosiasi, panggilan kelas A dan menggunakan objek dan

metode kelas B; dengan demikian, kelas A terpengaruh ketika

kelas B berubah.

(vi) Komposisi dan agregasi: dalam kaitannya dengan komposisi dan

agregasi, kelas A disertakan sebagai bagian dari kelas B;

Karenanya, jika kelas B diubah, kelas A akan terpengaruh.

(vii) Merekonstruksi grafik logika-sentris bisnis: grafik konversi

mikrolayanan direkonstruksi sehingga grafik yang dikonfigurasi

dapat diturunkan oleh unit mikrolayanan. Presentasi dan

persistensi lapisan simpul dan tepi yang tidak langsung terhubung

280

ke simpul dikonfigurasi dalam bisnis lapisan logika dihapus, dan

grafik dikonfigurasi ulang.

(viii) Ekstrak microservice berdasarkan entitas utama: dalam

kegiatan akhir dari langkah derivasi mikrolayanan, unit

microservice yang memiliki satu entitas dibangun. Di sini, entitas

adalah elemen kelas Vertex yang diklasifikasikan dalam lapisan

persistensi. Ini melacak simpul logika bisnis dan lapisan

presentasi yang disebut dalam entitas dan konstruksi itu. Namun,

sebagai kelas kontrol spesifik, yang merupakan simpul dari lapisan

logika bisnis, mungkin disebut oleh banyak kelas entitas, area

konfigurasi dapat tumpang tindih. Untuk mengatasi masalah ini,

satu entitas utama ditentukan untuk kontrol untuk menyelesaikan

redundansi di bidang konfigurasi. Di sini, satu entitas utama untuk

kontrol ditentukan dengan menghitung rasio metode yang

memanggil kelas entitas dan nilai rata-rata kesamaan nama

metode.

Jika entitas utama memanggil entitas lain secara langsung dari sudut

pandang kontrol setelah membangun microservice unit entitas dalam kontrol

entitas yang ditentukan, data desain diubah untuk dipanggil ke entitas melalui

kelas batas lapisan presentasi. Hal ini karena komunikasi antara layanan

mikro harus dilakukan oleh API [22]. Hal ini membuat batas baru dalam

281

hubungan entitas kontrol yang disebut secara langsung dan perubahan

desain data dalam hubungan entitas batas kontrol.

Gambar tentang microservice extraction pseudo-code menunjukkan

Pseudo-code dari microservice ekstrak berdasarkan entitas utama untuk

memperoleh microservice di unit entitas utama. Elemen input adalah grafik

G, dan elemen output adalah grafik microservice dibangun. Ini mengulangi

untuk menentukan entitas utama dari semua kelas kontrol dalam grafik. Jika

kelas kontrol memanggil lebih dari satu entitas, menghitung rasio metode

yang memanggil entitas dan metode kesamaan nama entitas dan

menentukan entitas dengan rasio yang lebih tinggi sebagai entitas utama.

Jika tidak, kelas yang terkait dengan satu entitas akan secara otomatis

menentukan entitas utama yang akan dikaitkan dengan entitas. Ketika entitas

utama ditentukan, iterate sebanyak jumlah entitas dan lanjutkan dengan

konfigurasi mikrolayanan di unit entitas yang sesuai dengan entitas utama.

Entitas yang entitas utama tidak ditentukan dikecualikan dari konfigurasi

microservice. Akhirnya, ketika kontrol terhubung ke entitas atau kelas kontrol

microservice lain, batas baru dibuat dan sambungan diubah untuk

menghubungkan microservice melalui batas yang dibuat.

282

Menerapkan layanan mikro. Pada langkah ini, koneksi API antara

layanan mikro diidentifikasi diimplementasikan sesuai dengan hirarki:

(i) Implementasikan microservice oleh 3-tier: implementasikan

kelas simpul yang diklasifikasi di setiap lapisan seperti yang

ditunjukkan pada Tabel berikut ini. Pengembang dapat

membangun berdasarkan data desain dengan menggunakan alat

pengembangan atau bahasa untuk setiap tingkatan.

283

Misalnya, ketika Layanan mikro dikonfigurasi dengan tiga batas

berikut, satu kontrol, satu entitas, tiga API, satu pengontrol, dan

satu DB diterapkan, seperti yang ditunjukkan pada gambar berikut

ini, untuk setiap lapisan.

284

(ii) Menerapkan microservice API untuk koneksi: batas yang

dihasilkan diimplementasikan untuk mendukung koneksi API antara

layanan mikro dalam langkah deriv vasi mikrolayanan. Sebagai

contoh, seperti yang ditunjukkan pada gambar, ketika dua layanan

mikro terhubung melalui batas (API-CALL1 dan API-CALL2),

sebuah implementasi untuk komunikasi api dilakukan di antara

mereka. Dalam studi kasus yang disajikan dalam Section berikut,

kita membahas proses implementasi untuk setiap lapisan.

285

Terapkan Microservice. Tahap akhir proses rekonstruksi

microservice adalah penyebaran microservice, di mana skrip template yang

dihasilkan yang mendukung penyebaran dan manajemen di lingkungan

orkestrasi kontainer yang didasarkan pada layanan mikro dilaksanakan dan

UML penyebaran data desain. Di sini, desain data mengumpulkan kelas dan

data desain penyebaran, dan microservice mengacu pada microservice yang

diimplementasikan dalam langkah menerapkan Microservice. Script template

utama adalah Pod, ReplicaSet, dan Service, yang merupakan tiga jenis

utama dari skrip template yang berjalan di Kubernetes, platform orkestrasi

kontainer. Proses menghasilkan skrip template berdasarkan data desain dan

informasi microservice ditunjukkan pada Gambar 2.83.

(i) Kumpulkan elemen penyebaran: model spesifikasi skrip template

kunci untuk penyebaran dan manajemen di lingkungan Kubernetes,

yang merupakan lingkungan orkestrasi kontainer, didefinisikan

286

seperti yang ditunjukkan pada gambar 2.84. Info Umum mengacu

pada elemen yang perlu dijelaskan dalam semua jenis skrip

template, dan Pod, ReplicaSet, dan Service adalah jenis skrip

template yang diperlukan untuk mengelola distribusi kontainer.

Deskripsi dari masing-masing jenis diberikan dalam tabel 2.31.

287

(ii) Menghasilkan script template untuk kontainer deployment:

kami memperoleh elemen koleksi dari data desain monolitik untuk

menghasilkan skrip template spesifikasi model elemen.

1] Informasi microservice: informasi microservice mencakup

informasi tentang nama dan nomor layanan mikro yang diekstrak.

2] Data desain kelas: informasi kelas mengumpulkan nama desain

kelas.

3] Data desain Deployment: ini diklasifikasikan ke dalam informasi

node dan koneksi. Informasi node mengumpulkan nama node,

Resource, OS, dan aplikasi untuk membuat Container. Informasi

sambungan mengumpulkan Port eksternal dan internal, protokol,

dan sambungan eksternal IP untuk komunikasi dengan luar

kontainer.

Tabel 2.33 adalah tabel pemetaan yang memetakan elemen skrip template

yang akan dihasilkan dan elemen koleksi yang didefinisikan dalam data

288

desain monolitik. Dalam kasus Pod, skrip dihasilkan oleh elemen pemetaan

yang dikumpulkan dari informasi kelas dan informasi node. ReplicaSet

dihasilkan oleh pemetaan nama desain kelas, jumlah layanan mikro yang

dikonfigurasi, dan informasi node untuk menghasilkan informasi template.

Akhirnya, Layanan menghasilkan skrip dengan memetakan informasi

sambungan yang dikumpulkan dari data desain penyebaran. Sebuah metode

untuk mengumpulkan data desain UML berdasarkan tabel pemetaan dan

pembuatan skrip template ditunjukkan pada gambar. Pertama, data desain

UML dikonversi menjadi format data (.XMI) sehingga mereka dapat diuraikan.

Selanjutnya, elemen yang ditetapkan dalam tabel pemetaan data XMI yang

kedua berubah yang dipilah dikumpulkan. Akhirnya, berdasarkan elemen

koleksi yang diekstrak, jenis skrip template dihasilkan.

289

Studi Kasus. Di sini dicoba adaptasi studi kasus pada proses

rekonstruksi “online ticket transaction system”, diadaptasi ke dalam

lingkungan Sentra Kekayaan Intelektual. Proses rekonstruksi memanfaatkan

data desain UML actual, juga diverifikasi reconfigured microservices

beroperasi dan berjalan baik dalam container orchestration environment.

Studi kasus “online ticket transaction system” adalah system di mana

penjual (jasa, misalnya Sentra KI) dan pengguna (misalnya stake holder

seperti inventor, desainer, author) dapat mendaftar, membuat pertanyaan,

dan menjual acara, jasa, (atau tiket) online.

Gambar berikut menunjukkan data desain UML aplikasi monolitik

“online ticket transaction system”. Berikut dijelaskan ekstraksi microservices

dan deployment of container-based microservices.

290

Gambar 2.86. Material desain UML Class dari system transaksi tiket online.

Studi Kasus Desain Monolitik Analisis Data dan Ekstraksi Microservice

Dalam tahap pertama, fase analisis data desain monolitik, data desain

class UML “online ticket transaction system” dikoleksi. Sebagai hasil

klasifikasi data terkoleksi dengan hirarki: 1) boundary classes, bv [10, kiri], 2)

control classes, cv [8, tengah], 3) entity classes, ev [5, kanan].

Tabel 2.34. Tabel pemetaan class-hierarchy system transaksi tiket online.

291

Menganalisa hubungan antara kelas dan membangun sebuah tepi

yang menunjuk ke arah metode pemanggilan.

Gambar di atas menunjukkan G (E, V) yang terdiri atas sebuah simpul

yang diklasifikasikan berdasarkan tipe kelas dan sebuah tepi sebagai relasi

pemanggilan. Dalam hal ini, membangun kembali bisnis logika-sentris grafik

metode diadopsi untuk merekonstruksi grafik konversi microservice berpusat

pada logika bisnis. Seperti yang ditunjukkan pada gambar tersebut, sebagai

hasil rekonstruksi, kita dapat membangun sebuah grafik konversi G ′ (E, V)

yang mampu derivasi microservice. Berdasarkan pada graph konversi

microservice yang diberikan, derivasi microservice unit entitas utama

dibentuk pada gambar berikut ini.

292

“Online ticket transaction system” terdiri atas lima entities (Member

/user, Report, Event, Ticket, and Payment). Untuk mengonstruksi layanan

mikro unit entitas, Sebagai hasil, ditunjukkan gambar di atas, area konfigurasi

micro service tumpang tindih dalam ev3, ev4, dan ev5.

Untuk mengatasi kasus di mana area konfigurasi microservice

tumpang tindih, satu entitas utama ditentukan per-titik kontrol. Gambar

berikut menunjukkan proses penentuan entitas utama cv6 di antara kelas

cv6, cv7, dan cv8 di mana terjadi tumpang tindih microservice. cv6

(TicketViewController) memanggil metode ev3 (EventInfo) dan ev4

293

(TicketInfo). Oleh karena itu, cv6 harus menentukan entitas utama dari ev3

atau ev4; dihitung dengan menerapkan pemanggilan metode dan kesamaan

nama metode sebagai kriteria keputusan. Tingkat metode pemanggilan

dihitung 25 % karena ev3 memanggil salah satu dari empat metode yang

dimiliki ev3.

Dalam kasus ev4, salah satu dari empat metode yang disebut; oleh

karena itu, sekali lagi, tingkat dihitung sebagai 25%. Kesamaan nama

dihitung pada tingkat 100% karena mencakup metode yang disebut "Ticket"

dalam semua metode ev4 yang disebut "TicketViewController," yang

merupakan nama kelas cv6. Dalam kasus ev3, tingkat dihitung sebagai 0%

karena tidak termasuk "Tiket" dan "transaksi" metode. Akhirnya, metode

294

permintaan dan nama kesamaan nilai perhitungan dirata-ratakan, masing-

masing, dan karenanya, ev3 dihitung sebagai 12,5%, ev4 dihitung sebagai

62,5%, dan ev4 ditentukan sebagai entitas utama.

Seperti cv6, entitas utama ditentukan dengan cara yang sama untuk

cv7 dan cv8, yang memanggil berbagai entitas. Akibatnya, ev4 ditentukan

sebagai entitas utama cv7 dan cv8 serta cv6, dan lima layanan mikro unit

entitas dikonfigurasi tanpa tumpang tindih dengan area konfigurasi, seperti

yang ditunjukkan pada gambar berikut ini.

295

Jika area konfigurasi microservice tidak diduplikasi, tetapi kontrol yang

ada mengakses entitas microservice lainnya (cv6 ⟶ ev3, cv7 ⟶ ev3, dan

cv8 ⟶ ev4), mengubah data desain untuk membuat batas baru dan

memanggil dalam kasus hubungan yang langsung memanggil entitas. Seperti

yang ditunjukkan pada gambar di bawah ini, dalam kasus cv6, cv7, dan cv8,

yang merupakan kontrol microservice yang secara langsung memanggil

entitas microservice lainnya, batas baru (bv1 baru, bv2, bv3) dibuat untuk

mengubah data desain untuk melakukan komunikasi batas antara layanan

mikro.

296

Studi Kasus Implementasi dan Penyebaran Layanan Mikro

Layanan mikro yang dikonfigurasi ulang yang diekstrak di langkah

sebelumnya diterapkan dengan hierarki dan menerapkan api interkoneksi

antara layanan mikro. Gambar berikut ini menunjukkan proses pelaksanaan

layanan mikro anggota di antara layanan mikro yang dikonfigurasi dalam

"sistem transaksi tiket online" sesuai dengan hirarki yang disajikan dalam

tabel 3. Dalam studi kasus ini, ExpressJs, yang merupakan modul paket dari

API node. js, digunakan untuk implementasi API pada layer presentasi.

Pengontrol dari lapisan logika bisnis menggunakan node. js berdasarkan

JavaScript dan MySQL sebagai database lapisan persistensi.

Gambar berikut menunjukkan kode sumber aktual dari microservice

anggota dilaksanakan sesuai dengan lapisan diklasifikasikan. Dalam kasus

297

API, itu diimplementasikan atas dasar informasi parameter metode input

internal dari kelas batas.

Dalam kasus keanggotaan bv1, jalur API diimplementasikan sebagai

"/user/signup," dan parameter input diimplementasikan untuk menerima App

id, App Pass, dan name. Dalam kasus controller, itu diimplementasikan atas

dasar nama dan metode kelas kontrol. Hal ini dibuat dan dipanggil dalam

hubungannya dengan jalur API.

298

Akhirnya, dalam kasus DB, kita menerapkan nama tabel atas dasar

nama kelas entitas dan nama Field sebagai pernyataan SQL berdasarkan

parameter metode. Setelah implementasi oleh lapisan, koneksi API

diimplementasikan antara layanan mikro. Proses pelaksanaan bv1 baru di

antara tiga batas baru yang dihasilkan dalam langkah ekstraksi mikrolayanan

adalah sama seperti yang ditunjukkan pada gambar berikut ini.

299

Bv1 baru diterapkan sehingga cv6 adalah batas yang berisi informasi

untuk memanggil metode EventSelect() cv3, dan bv1 baru diterapkan untuk

memanggil EventSelect() dengan jalur API "/event/EventSelect."

Setelah menerapkan layanan mikro, skrip template dibuat untuk

mendukung manajemen distribusi di Kubernetes, yang merupakan

lingkungan orkestrasi kontainer. Data desain di sisi kiri gambar berikut ini

adalah data desain penyebaran UML dari "sistem transaksi tiket online," yang

terdiri atas dua node dan satu informasi koneksi.

Kami mengekspor data desain penyebaran UML ke file XMI untuk

membuat skrip template Pod, ReplicaSet, dan Service sesuai dengan metode

yang ditunjukkan pada Gambar2.51. Sisi kanan layar output Gambar 2.61

adalah hasil dari mengekspor data desain sebagai data XMI. Node dan

informasi koneksi masing-masing didefinisikan sebagai dan nilai tag.

300

Tag atribut internal didefinisikan sebagai nama, stereotip, jenis, dan

nilai, di mana nama adalah nama dari node atau informasi koneksi, stereotip

adalah jenis elemen desain (OS, Device, dll), jenis adalah milik jenis (RAM,

CPU, dll, untuk perangkat), dan nilai adalah nilai untuk tipe. Sebagai contoh,

DBserver, yang merupakan nama node, memiliki stereotip perangkat, jenis

perangkat CPU, dan nilai RAM dinyatakan sebagai data XMI dengan satu inti

dan 256 MB ditetapkan sebagai nilai. Tabel pemetaan untuk elemen

pengumpulan data XMI berubah didefinisikan dalam tabel berikut ini dan data

XMI dipilah seperti yang ditunjukkan pada gambar berikut ini.

301

Berdasarkan tabel pemetaan nilai yang diekstraksi, skrip templat untuk

setiap jenis dihasilkan seperti yang ditunjukkan pada Gambar berikut ini. Area

yang ditandai dengan menunjukkan proses pembuatan nama skrip templat①

Pod per nama layanan-mikro. Area yang ditunjukkan oleh menunjukkan②

proses menghasilkan nilai replika skrip template ReplicaSet dengan jumlah

layanan microser yang dikonfigurasi. Area bertanda menunjukkan proses③

mengekstraksi informasi diagram kelas dan membuat Pod, ReplicaSet, dan

label skrip templat Layanan. Area yang ditandai dengan menunjukkan④

proses penggalian informasi simpul diagram penyebaran dan membuat

informasi wadah dan templat dari skrip templat Pod dan ReplicaSet. Area

yang ditandai dengan menunjukkan proses mengekstraksi informasi⑤

koneksi dan membuat skrip templat Layanan.

302

Verifikasi mikrolayanan. Kami memverifikasi bahwa file skrip

template yang dihasilkan di bagian “Studi Kasus Implementasi dan

Penyebaran Layanan Mikro” bekerja dengan benar. Untuk verifikasi,

Kubernetes, yang merupakan lingkungan orkestrasi kontainer, dibangun dan

satu master dan dua node didorong ke dalam lingkungan mesin virtual.

Dalam kasus Master, 2 vCPUs dan 4 GB RAM dialokasikan, dan untuk node,

2 vCPUs dan 2 GB RAM dialokasikan. Hasil dari mengeksekusi tiga jenis

skrip template di lingkungan Kubernetes ditunjukkan pada gambar berikut ini.

Di sini, No. (a) adalah layar untuk bertanya tentang semua negara Pod

di lingkungan kontrol Kubernetes. Sebagai hasil dari mengeksekusi skrip

yang dihasilkan, lima Pods (userpod, reportpod, ticketpod, eventpod, dan

303

paymentpod) diciptakan. Selain itu, dikonfirmasi bahwa semua negara Pod

operasi normal. No. (b) adalah hasil dari mengeksekusi skrip template dari

ReplicaSet. Saat ini, lima Pod dikelola melalui pelabelan dan kami dapat

mengonfirmasi bahwa semua Pod berjalan melalui status Pod. No. (c) adalah

hasil dari mengeksekusi script template Service. Dikonfirmasi bahwa lima

Pods dengan label yang terhubung ke setiap titik akhir dengan

mengkonfigurasi protokol, informasi Port, dan IP eksternal. Ketika Layanan

mikro diimplementasikan dikerahkan di lingkungan kubernetes, kami

memverifikasi bahwa mereka bekerja dengan benar.

Seperti yang ditunjukkan pada gambar di atas, setelah

mengimplementasikan microservice pengguna dari "sistem transaksi tiket

online," itu didistribusikan ke lingkungan kontainer (userpod). Untuk

304

memeriksa apakah microservice didistribusikan anggota dieksekusi, kami

mengkonfirmasi respon menggunakan Postman [23], alat tes API.

Seperti yang ditunjukkan pada gambar 2.100, setelah pengujian API,

permintaan dikirim ke userpod dan dikonfirmasi bahwa respon diterima.

Panel kiri gambar 2.100 menunjukkan situasi di mana API signup (user

/signup) dipanggil dari informasi host userpod 10.244.5.2. Untuk mendaftar

keanggotaan, kami mengirim informasi (App id, App Pass, dan nama)

langsung ke pengguna dalam bentuk JSON dan mengkonfirmasi bahwa input

informasi dari userpod diproses. Panel kanan atas gambar 2.100 adalah

perintah untuk query informasi database di dbserver userpod sebelum

panggilan API. Panel kanan bawah adalah layar untuk query informasi

database dbserver dari userpod setelah panggilan API. Sebagai hasil dari

panggilan API, itu dikonfirmasi bahwa input informasi dari database informasi

dari dbserver userpod dihasilkan.