rasp921484406.files.wordpress.com · Web viewKomputasi tanpa server adalah model eksekusi di mana...
Transcript of rasp921484406.files.wordpress.com · Web viewKomputasi tanpa server adalah model eksekusi di mana...
246
X. 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 microservices 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.
247
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 API
call 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
248
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 platform) 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
(milik sendiri) 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.
249
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 website 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.
250
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 (platform) 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.
251
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.
252
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
253
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
254
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.
255
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
256
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
257
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.77. 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:
258
(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.
Tabel 2.13. UML design data collection and hierarchy mapping.
(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
259
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 edge, spt yang ditunjukkan pada tabel berikut
ini.
Tabel 2.14. Edge representation mengacu ke relasi kelas.
260
(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
261
dapat diturunkan oleh unit mikrolayanan. Presentasi dan
persistensi lapisan vertex dan edge yang tidak langsung terhubung
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, entity
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
262
kelas batas lapisan presentasi. Hal ini karena komunikasi antara layanan
mikro harus dilakukan oleh API [22]. Hal ini membuat batas baru dalam
hubungan entitas kontrol yang disebut secara langsung dan perubahan
desain data dalam hubungan entitas batas kontrol.
Gmb tentang microservice extraction pseudo-code menunjukkan
Pseudo-code dari microservice ekstrak berdasarkan entitas utama utk
memperoleh microservice di unit entitas utama. Elemen input adalah grafik
G, dan elemen output adalah grafik microservice dibangun. Ini mengulangi
utk menentukan entitas utama dari semua kelas kontrol dalam grafik. Jika
kelas kontrol memanggil lebih dari satu entitas, menghitung rasio metode yg
memanggil entitas dan metode kesamaan nama entitas dan menentukan
entitas dengan rasio yang lebih tinggi sbg 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 jml entitas dan lanjutkan dgn konfigurasi mikrolayanan di
unit entitas yg sesuai dengan entitas utama. Entitas yg 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 utk menghubungkan microservice melalui batas yg
dibuat.
263
Gambar 2.78. Microservice extraction pseudocode.
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.
Tabel 2.15. Implement microservice by layer.
264
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.
Gambar 2.79. Contoh implementasi layanan mikro oleh lapisan.
265
(ii) Menerapkan microservice API untuk koneksi: batas yang
dihasilkan diimplementasikan untuk mendukung koneksi API antara
layanan mikro dalam langkah derivasi 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.
Gambar 2.80. Contoh koneksi implementasi API di antara microservice.
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
266
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:
(i) Kumpulkan elemen penyebaran: model spesifikasi skrip template
kunci untuk penyebaran dan manajemen di lingkungan Kubernetes,
yang merupakan lingkungan orkestrasi container. 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.
Gambar 2.81. Outline of template script generation.
267
Gambar 2.82. Kubernetes main template script model.
Tabel 2.16. Description of Kubernetes main template script model.
(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.
268
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 utk komunikasi dengan luar container.
Tabel di bawah ini adalah tabel pemetaan yang memetakan elemen
skrip template yang akan dihasilkan dan elemen koleksi yang didefinisikan
dalam data 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.
269
Tabel 2.17. Template script generation mapping table.
Gambar 2.83. Metode membangkitkan template script.
Studi Kasus. Di sini dicoba adaptasi studi kasus pada proses
rekonstruksi “online ticket transaction system”, diadaptasi ke dalam
270
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.
Gambar 2.84. Material desain UML Class dari system transaksi tiket online.
271
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.18. Tabel pemetaan class-hierarchy system transaksi tiket online.
Menganalisa hubungan antara kelas dan membangun sebuah tepi
yang menunjuk ke arah metode pemanggilan.
272
Gambar 2.85. Graf transisi layanan mikro system transaksi tiket online: (a) Remove edges that do not connect directly by control class; (b) Converted micro service G’(E, V) reconstruction.
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.
273
Gambar 2.86. Entity duplication microservice configuration are in entity units.
“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
274
(TicketViewController) memanggil metode ev3 (EventInfo) dan ev4
(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.
Gambar 2.87. Menentukan entitas utama cv6.
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
275
merupakan nama kelas cv6. Dalam kasus ev3, tingkat dihitung sebagai 0%
karena tidak termasuk "Tiket" dan "transaksi" metode. Akhirnya, metode
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.
276
Gambar 2.88. Hasil konfigurasi layanan mikro dalam unit entitas utama.
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
277
mengubah data desain untuk melakukan komunikasi batas antara layanan
mikro.
Gambar 2.89. Hasil ekstraksi layanan mikro.
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. Dalam studi kasus ini, ExpressJs, yang merupakan modul paket dari
278
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 2.90. Microservice implementation process by tier.
Gambar berikut menunjukkan kode sumber aktual dari microservice
anggota dilaksanakan sesuai dengan lapisan diklasifikasikan. Dalam kasus
API, itu diimplementasikan atas dasar informasi parameter metode input
internal dari kelas batas.
279
Gambar 2.91. Example of member microservice implementation by layer.
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.
280
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.
Gambar 2.92. Implementasi new bv1 dan koneksi API.
281
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.
Gambar 2.93. UML design resources export to XML.
Kami mengekspor data desain penyebaran UML ke file XMI untuk
membuat skrip template Pod UML design resources export to XML.,
ReplicaSet, dan Service sesuai dengan metode yang ditunjukkan pada
Gambar2.51. Sisi kanan layar output Gambar 2.61 adalah hasil dari
282
mengekspor data desain sebagai data XMI. Node dan informasi koneksi
masing-masing didefinisikan sebagai dan nilai tag.
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.
Tabel 2.19. Metode ekstraksi dengan meng-ekstrasi elemen target.
283
Gambar 2.94. Contoh XMI data parsing.
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
284
yang ditandai dengan menunjukkan proses mengekstraksi informasi⑤
koneksi dan membuat skrip templat Layanan.
Gambar 2.95. Result of template script generation by type.
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.
285
Gambar 2.96. Pod (EventPod), ReplicaSet, Service template script generation, and execution result. (a) Mengonfirmasi bahwa semua pods dibangkitkan oleh template script adalah bekerja secara normal. (b) Mengonfirmasi bahwa ReplicaSet dikreasi melalui template script mengatur 5 pods. (c) Mengonfirmasi bahwa service dibangkitkan oleh template script mengandung semua informasi koneksi.
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
paymentpod) diciptakan. Selain itu, dikonfirmasi bahwa semua negara Pod
operasi normal. No. (b) adalah hasil dari mengeksekusi skrip template dari
286
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.
Gambar 2.97. User microservice API call test.
Seperti yang ditunjukkan pada gambar di atas, setelah
mengimplementasikan microservice pengguna dari "sistem transaksi tiket
online," itu didistribusikan ke lingkungan kontainer (userpod). Untuk
memeriksa apakah microservice didistribusikan anggota dieksekusi, kami
mengkonfirmasi respon menggunakan Postman [23], alat tes API.
287
Gambar 2.98. Userpod signup API test result.
Seperti yang ditunjukkan pada gambar, setelah pengujian API,
permintaan dikirim ke userpod dan dikonfirmasi bahwa respon diterima.
Panel kiri gambar 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 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.