2

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

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

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.

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 tenan 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 yaitu sebagai berikut.

No.

Asumsi

Artinya

1

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 mutakhir

6

format

Mampu memberikan informasi sesuai yang dibutuhkan.

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 mikro Layanan 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.

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 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 (lapisan) input pengguna, logika bisnis yang memproses nilai input, dan 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 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.

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 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 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.46. 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:

(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 < > adalah lapisan presentasi, jenis < > adalah lapisan logika bisnis, dan jenis < > 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 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.

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

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.

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.

(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 2.48, 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.

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

(i) Kumpulkan elemen penyebaran: model spesifikasi skrip template kunci untuk penyebaran dan manajemen di lingkungan Kubernetes, yang merupakan lingkungan orkestrasi kontainer, didefinisikan seperti yang ditunjukkan pada gambar 2.50. 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.

(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.32 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 2.51. 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.

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.

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

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.

“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 (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 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.

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.

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

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.

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.

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.

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.

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 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 memeriksa apakah microservice didistribusikan anggota dieksekusi, kami mengkonfirmasi respon menggunakan Postman [23], alat tes API.

Seperti yang ditunjukkan pada gambar 2.66, setelah pengujian API, permintaan dikirim ke userpod dan dikonfirmasi bahwa respon diterima. Panel kiri gambar 2.66 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.66 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.