Layanan mikro dalam kontainer

Mengembangkan aplikasi server klien telah menghasilkan fokus pada pembangunan aplikasi berjenjang yang menggunakan teknologi tertentu di setiap tingkatan. Aplikasi tersebut sering disebut sebagai monolitik dan dikemas ke perangkat keras yang telah diskalakan sebelumnya untuk beban puncak. Kelemahan utama dari pendekatan pengembangan ini adalah kopling yang ketat antara komponen dalam setiap tingkatan, bahwa komponen individual tidak dapat dengan mudah diskalakan, dan biaya pengujian. Pembaruan sederhana dapat memiliki efek tak terduga pada tingkat lainnya, sehingga perubahan pada komponen aplikasi mengharuskan seluruh tingkatannya untuk diuji ulang dan disebarkan ulang.

Terutama yang menyangkut, di usia cloud, adalah bahwa komponen individu tidak dapat dengan mudah diskalakan. Aplikasi monolitik berisi fungsionalitas khusus domain dan biasanya dibagi dengan lapisan fungsional seperti front-end, logika bisnis, dan penyimpanan data. Gambar di bawah ini menggambarkan bahwa aplikasi monolitik diskalakan dengan mengkloning seluruh aplikasi ke beberapa komputer.

Layanan mikro

Layanan mikro menawarkan pendekatan yang berbeda untuk pengembangan dan penyebaran aplikasi, pendekatan yang cocok untuk persyaratan kelincahan, skala, dan keandalan aplikasi cloud modern. Aplikasi layanan mikro dibagi menjadi komponen independen yang bekerja sama untuk memberikan fungsionalitas aplikasi secara keseluruhan. Istilah layanan mikro menekankan bahwa aplikasi harus terdiri dari layanan yang cukup kecil untuk mencerminkan kekhawatiran tertentu, sehingga setiap layanan mikro mengimplementasikan satu fungsi. Selain itu, setiap layanan mikro memiliki kontrak yang terdefinisi dengan baik di mana layanan mikro lainnya berkomunikasi dan berbagi data. Contoh umum layanan mikro termasuk kelir belanja, pemrosesan inventaris, subsistem pembelian, dan pemrosesan pembayaran.

Layanan mikro dapat diskalakan secara independen dibandingkan dengan aplikasi monolitik raksasa yang menskalakan bersama-sama. Ini berarti bahwa area fungsional tertentu yang membutuhkan lebih banyak daya pemrosesan atau bandwidth jaringan untuk mendukung permintaan dapat diskalakan daripada perlu menskalakan area aplikasi lain. Gambar di bawah ini menggambarkan pendekatan ini, di mana layanan mikro disebarkan dan diskalakan secara independen, membuat instans layanan di seluruh komputer.

Peluasan skala layanan mikro dapat hampir seketika, memungkinkan aplikasi beradaptasi dengan perubahan beban. Misalnya, layanan mikro tunggal dalam fungsionalitas aplikasi yang menghadap web mungkin menjadi satu-satunya layanan mikro yang perlu diskalakan untuk menangani lalu lintas masuk tambahan.

Model klasik untuk skalabilitas aplikasi adalah memiliki tingkat stateless yang seimbang dengan datastore eksternal bersama untuk menyimpan data persisten. Layanan mikro stateful mengelola data persisten mereka sendiri, biasanya menyimpannya secara lokal di server tempat mereka ditempatkan, untuk menghindari overhead akses jaringan dan kompleksitas operasi lintas layanan. Ini memungkinkan pemrosesan data tercepat dan dapat menghilangkan kebutuhan akan sistem penembolokan. Selain itu, layanan mikro stateful yang dapat diskalakan biasanya mempartisi data di antara instans mereka, untuk mengelola ukuran data dan mentransfer throughput di mana satu server dapat mendukung.

Layanan mikro juga mendukung pembaruan independen. Kopling longgar antara layanan mikro ini memberikan evolusi aplikasi yang cepat dan dapat diandalkan. Sifat independen dan terdistribusinya membantu pembaruan bergulir, di mana hanya subset instans dari satu layanan mikro yang akan diperbarui pada waktu tertentu. Oleh karena itu, jika masalah terdeteksi, pembaruan buggy dapat digulung balik, sebelum semua instans diperbarui dengan kode atau konfigurasi yang rusak. Demikian pula, layanan mikro biasanya menggunakan penerapan versi skema, sehingga klien melihat versi yang konsisten saat pembaruan diterapkan, terlepas dari instans layanan mikro mana yang sedang dikomunikasikan.

Oleh karena itu, aplikasi layanan mikro memiliki banyak manfaat daripada aplikasi monolitik:

• Setiap layanan mikro relatif kecil, mudah dikelola dan berkembang.
• Setiap layanan mikro dapat dikembangkan dan disebarkan secara independen dari layanan lain.
• Setiap layanan mikro dapat diskalakan secara independen. Misalnya, layanan katalog atau layanan ke basket belanja mungkin perlu diperluas skalanya lebih dari layanan pemesanan. Oleh karena itu, infrastruktur yang dihasilkan akan lebih efisien menggunakan sumber daya saat penskalaan.
• Setiap layanan mikro mengisolasi masalah apa pun. Misalnya, jika ada masalah dalam layanan, itu hanya berdampak pada layanan tersebut. Layanan lain dapat terus menangani permintaan.
• Setiap layanan mikro dapat menggunakan teknologi terbaru. Karena layanan mikro otonom dan berjalan berdampingan, teknologi dan kerangka kerja terbaru dapat digunakan, daripada dipaksa menggunakan kerangka kerja yang lebih lama yang mungkin digunakan oleh aplikasi monolitik.

Namun, solusi berbasis layanan mikro juga memiliki potensi kelemahan:

• Memilih cara mempartisi aplikasi menjadi layanan mikro bisa menjadi tantangan, karena setiap layanan mikro harus sepenuhnya otonom, end-to-end, termasuk tanggung jawab atas sumber datanya.
• Pengembang harus menerapkan komunikasi antar-layanan, yang menambahkan kompleksitas dan latensi ke aplikasi.
• Transaksi atom antara beberapa layanan mikro biasanya tidak dimungkinkan. Oleh karena itu, persyaratan bisnis harus merangkul konsistensi akhir antara layanan mikro.
• Dalam produksi, ada kompleksitas operasional dalam menyebarkan dan mengelola sistem yang disusupi dari banyak layanan independen.
• Komunikasi klien-ke-layanan mikro langsung dapat menyulitkan untuk merefaktor kontrak layanan mikro. Misalnya, seiring waktu bagaimana sistem dipartisi ke dalam layanan mungkin perlu berubah. Satu layanan mungkin dibagi menjadi dua layanan atau lebih, dan dua layanan mungkin bergabung. Ketika klien berkomunikasi langsung dengan layanan mikro, pekerjaan refaktor ini dapat merusak kompatibilitas dengan aplikasi klien.

Kontainerisasi

Kontainerisasi adalah pendekatan untuk pengembangan perangkat lunak di mana aplikasi dan serangkaian dependensi versinya, ditambah konfigurasi lingkungannya yang diabstraksi sebagai file manifes penyebaran, dikemas bersama-sama sebagai gambar kontainer, diuji sebagai unit, dan disebarkan ke sistem operasi host.

Kontainer adalah lingkungan operasi yang terisolasi, dikontrol sumber daya, dan portabel, di mana aplikasi dapat berjalan tanpa menyentuh sumber daya kontainer lain, atau host. Oleh karena itu, kontainer terlihat dan bertindak seperti komputer fisik yang baru dipasang atau komputer virtual.

Ada banyak kesamaan antara kontainer dan komputer virtual, seperti yang diilustrasikan di bawah ini.

Kontainer menjalankan sistem operasi, memiliki sistem file, dan dapat diakses melalui jaringan seolah-olah itu adalah komputer fisik atau virtual. Namun, teknologi dan konsep yang digunakan oleh kontainer sangat berbeda dari komputer virtual. Komputer virtual mencakup aplikasi, dependensi yang diperlukan, dan sistem operasi tamu lengkap. Kontainer termasuk aplikasi dan dependensinya, tetapi berbagi sistem operasi dengan kontainer lain, berjalan sebagai proses terisolasi pada sistem operasi host (selain dari kontainer Hyper-V yang berjalan di dalam komputer virtual khusus per kontainer). Oleh karena itu, kontainer berbagi sumber daya dan biasanya membutuhkan lebih sedikit sumber daya daripada komputer virtual.

Keuntungan dari pendekatan pengembangan dan penyebaran berorientasi kontainer adalah menghilangkan sebagian besar masalah yang timbul dari pengaturan lingkungan yang tidak konsisten dan masalah yang menyertainya. Selain itu, kontainer mengizinkan fungsionalitas peningkatan skala aplikasi yang cepat dengan membuat instans kontainer baru sesuai kebutuhan.

Konsep utama saat membuat dan bekerja dengan kontainer adalah:

Perusahaan semakin mengadopsi kontainer saat menerapkan aplikasi berbasis layanan mikro, dan Docker telah menjadi implementasi kontainer standar yang telah diadopsi oleh sebagian besar platform perangkat lunak dan vendor cloud.

Aplikasi referensi eShop menggunakan Docker untuk menghosting empat layanan mikro back-end kontainer, seperti yang diilustrasikan dalam diagram di bawah ini.

Arsitektur layanan back-end dalam aplikasi referensi diurai menjadi beberapa sub-sistem otonom dalam bentuk berkolaborasi layanan mikro dan kontainer. Setiap layanan mikro menyediakan satu area fungsionalitas: layanan identitas, layanan katalog, layanan pemesanan, dan layanan ke basket.

Setiap layanan mikro memiliki database sendiri, memungkinkannya untuk sepenuhnya dipisahkan dari layanan mikro lainnya. Jika perlu, konsistensi antara database dari layanan mikro yang berbeda dicapai menggunakan peristiwa tingkat aplikasi. Untuk informasi selengkapnya, lihat Komunikasi antar layanan mikro.

Komunikasi antara klien dan layanan mikro

Aplikasi multi-platform eShop berkomunikasi dengan layanan mikro back-end kontainer menggunakan komunikasi klien-ke-layanan mikro langsung, seperti yang ditunjukkan di bawah ini.

Dengan komunikasi klien-ke-layanan mikro langsung, aplikasi multi-platform membuat permintaan ke setiap layanan mikro langsung melalui titik akhir publiknya, dengan port TCP yang berbeda per layanan mikro. Dalam produksi, titik akhir biasanya akan memetakan ke penyeimbang beban layanan mikro, yang mendistribusikan permintaan di seluruh instans yang tersedia.

Komunikasi klien-ke-layanan mikro langsung dapat memiliki kelemahan saat membangun aplikasi berbasis layanan mikro yang besar dan kompleks, tetapi lebih dari memadai untuk aplikasi kecil. Pertimbangkan untuk menggunakan komunikasi gateway API saat merancang aplikasi berbasis layanan mikro besar dengan puluhan layanan mikro.

Komunikasi antar layanan mikro

Aplikasi berbasis layanan mikro adalah sistem terdistribusi, berpotensi berjalan pada beberapa komputer. Setiap instans layanan biasanya merupakan proses. Oleh karena itu, layanan harus berinteraksi menggunakan protokol komunikasi antarproses, seperti HTTP, TCP, Advanced Message Queuing Protocol (AMQP), atau protokol biner, tergantung pada sifat setiap layanan.

Dua pendekatan umum untuk komunikasi layanan mikro ke layanan mikro adalah komunikasi REST berbasis HTTP saat mengkueri data, dan pesan asinkron ringan saat mengomunikasikan pembaruan di beberapa layanan mikro.

Komunikasi berbasis olahpesan asinkron sangat penting saat menyebarkan perubahan di beberapa layanan mikro. Dengan pendekatan ini, layanan mikro menerbitkan peristiwa ketika sesuatu yang penting terjadi, misalnya, ketika memperbarui entitas bisnis. Layanan mikro lainnya berlangganan peristiwa ini. Kemudian, ketika layanan mikro menerima peristiwa, layanan mikro memperbarui entitas bisnisnya sendiri, yang mungkin, pada gilirannya, menyebabkan lebih banyak peristiwa diterbitkan. Fungsionalitas terbitkan-berlangganan ini biasanya dicapai dengan bus peristiwa.

Bus kejadian memungkinkan komunikasi terbitkan-berlangganan antara layanan mikro tanpa mengharuskan komponen untuk saling mengetahui secara eksplisit, seperti yang ditunjukkan di bawah ini.

Dari perspektif aplikasi, bus peristiwa hanyalah saluran terbitkan-berlangganan yang diekspos melalui antarmuka. Namun, cara bus kejadian diimplementasikan dapat bervariasi. Misalnya, implementasi bus peristiwa dapat menggunakan RabbitMQ, Azure Bus Layanan, atau bus layanan lainnya seperti NServiceBus dan MassTransit. Diagram di bawah ini menunjukkan bagaimana bus peristiwa digunakan dalam aplikasi referensi eShop.

Bus peristiwa eShop, yang diimplementasikan menggunakan RabbitMQ, menyediakan fungsionalitas terbitkan-berlangganan asinkron satu-ke-banyak. Ini berarti bahwa setelah menerbitkan peristiwa, mungkin ada beberapa pelanggan yang mendengarkan peristiwa yang sama. Diagram di bawah ini menggambarkan hubungan ini.

Pendekatan komunikasi satu-ke-banyak ini menggunakan peristiwa untuk menerapkan transaksi bisnis yang mencakup beberapa layanan, memastikan konsistensi akhir antara layanan. Transaksi yang konsisten akhir terdiri dari serangkaian langkah terdistribusi. Oleh karena itu, ketika layanan mikro profil pengguna menerima perintah UpdateUser, layanan mikro memperbarui detail pengguna dalam databasenya dan menerbitkan peristiwa UserUpdated ke bus peristiwa. Layanan mikro keranjang dan layanan mikro pemesanan telah berlangganan untuk menerima acara ini, dan sebagai tanggapan, memperbarui informasi pembeli mereka di database masing-masing.

Ringkasan

Layanan mikro menawarkan pendekatan untuk pengembangan dan penyebaran aplikasi yang cocok dengan persyaratan kelincahan, skala, dan keandalan aplikasi cloud modern. Salah satu keuntungan utama layanan mikro adalah bahwa mereka dapat diskalakan secara independen, yang berarti bahwa area fungsional tertentu dapat diskalakan yang membutuhkan lebih banyak daya pemrosesan atau bandwidth jaringan untuk mendukung permintaan tanpa perlu menskalakan area aplikasi yang tidak mengalami peningkatan permintaan.

Kontainer adalah lingkungan operasi yang terisolasi, dikontrol sumber daya, dan portabel di mana aplikasi dapat berjalan tanpa menyentuh sumber daya kontainer lain atau host. Perusahaan semakin mengadopsi kontainer saat menerapkan aplikasi berbasis layanan mikro, dan Docker telah menjadi implementasi kontainer standar yang telah diadopsi oleh sebagian besar platform perangkat lunak dan vendor cloud.