Komunikasi di sisi klien front-end

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Merancang Aplikasi .NET Cloud Native untuk Azure, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Dalam sistem cloud-native, klien front-end (aplikasi seluler, web, dan desktop) memerlukan saluran komunikasi untuk berinteraksi dengan layanan mikro back-end independen.

Apa saja opsinya?

Untuk menjaga hal-hal sederhana, klien front-end dapat langsung berkomunikasi dengan layanan mikro back-end, yang ditunjukkan pada Gambar 4-2.

Gambar 4-2. Mengarahkan klien ke komunikasi layanan

Dengan pendekatan ini, setiap layanan mikro memiliki titik akhir publik yang dapat diakses oleh klien front-end. Di lingkungan produksi, Anda akan menempatkan penyeimbang beban di depan layanan mikro, merutekan lalu lintas sesuai proporsi.

Meskipun mudah diterapkan, komunikasi klien langsung hanya akan dapat diterima untuk aplikasi layanan mikro sederhana. Pola ini mengikat erat klien antarmuka depan dengan layanan ujung belakang inti, membuka pintu untuk banyak masalah, termasuk:

• Ketergantungan klien terhadap perubahan struktur layanan back-end.
• Permukaan serangan yang lebih luas karena layanan back-end inti langsung terekspos.
• Duplikasi keprihatinan lintas sektor di setiap layanan mikro.
• Kode klien yang terlalu kompleks - klien harus melacak beberapa titik akhir dan menangani kegagalan dengan cara yang tangguh.

Sebaliknya, pola desain cloud yang diterima secara luas adalah mengimplementasikan Layanan Gateway API di antara aplikasi antarmuka depan (front-end) dan layanan latar belakang (back-end). Pola ditunjukkan pada Gambar 4-3.

Gambar 4-3. Pola gateway API

Pada gambar sebelumnya, perhatikan bagaimana layanan API Gateway mengabstraksi layanan mikro inti back-end. Diimplementasikan sebagai API web, ia bertindak sebagai proksi terbalik, merutekan lalu lintas masuk ke layanan mikro internal.

Gateway mengisolasi klien dari partisi dan pemfaktoran ulang layanan internal. Jika Anda mengubah layanan back-end, Anda mengakomodasinya di gateway tanpa mengganggu klien. Ini juga merupakan garis pertahanan pertama Anda untuk masalah lintas fungsi, seperti identitas, penyimpanan dalam cache, daya tahan, penggunaan, dan pembatasan. Banyak dari kendala lintas sistem ini dapat dialihkan dari layanan inti back-end ke gateway, sehingga menyederhanakan layanan back-end.

Perhatian harus diberikan untuk menjaga API Gateway tetap sederhana dan cepat. Biasanya, logika bisnis dijaga agar tidak termasuk dalam gateway. Gateway yang kompleks berisiko menjadi hambatan dan akhirnya menjadi monolitik. Sistem yang lebih besar sering mengekspos beberapa GATEWAY API yang disegmentasi oleh jenis klien (fungsionalitas seluler, web, desktop) atau back-end. Pola Backend untuk Frontend memberikan arahan untuk menerapkan beberapa gateway. Pola ditunjukkan pada Gambar 4-4.

Gambar 4-4. Backend untuk pola frontend

Perhatikan pada gambar sebelumnya bagaimana lalu lintas masuk dikirim ke gateway API tertentu - berdasarkan jenis klien: web, seluler, atau aplikasi desktop. Pendekatan ini masuk akal karena kemampuan setiap perangkat berbeda secara signifikan di seluruh faktor bentuk, performa, dan batasan tampilan. Biasanya aplikasi seluler mengekspos lebih sedikit fungsionalitas daripada browser atau aplikasi desktop. Setiap gateway dapat dioptimalkan untuk mencocokkan kemampuan dan fungsionalitas perangkat yang sesuai.

Gateway Sederhana

Untuk memulai, Anda dapat membangun layanan API Gateway Anda sendiri. Pencarian cepat GitHub akan memberikan banyak contoh.

Untuk aplikasi .NET cloud-native sederhana, Anda mungkin mempertimbangkan Ocelot Gateway. Sumber terbuka dan dibuat untuk layanan mikro .NET, ringan, cepat, dapat diskalakan. Seperti HALNYA API Gateway, fungsi utamanya adalah meneruskan permintaan HTTP masuk ke layanan hilir. Selain itu, ini mendukung berbagai kemampuan yang dapat dikonfigurasi dalam alur middleware .NET.

YARP (Satu Lagi Proksi Terbalik) adalah proksi terbalik sumber terbuka lain yang dipimpin oleh tim produk Microsoft. Dapat diunduh sebagai paket NuGet, YARP dicolokkan ke kerangka kerja ASP.NET sebagai middleware dan sangat dapat disesuaikan. Anda akan menemukan YARP yang didokumenkan dengan baik dengan berbagai contoh penggunaan.

Untuk aplikasi cloud-native perusahaan, ada beberapa layanan Azure terkelola yang dapat membantu memulai upaya Anda.

Azure Application Gateway

Untuk persyaratan gateway sederhana, Anda dapat mempertimbangkan Azure Application Gateway. Tersedia sebagai layanan Azure PaaS, layanan ini mencakup fitur gateway dasar seperti perutean URL, penghentian SSL, dan Web Application Firewall. Layanan ini mendukung kemampuan penyeimbangan beban Layer-7 . Dengan Lapisan 7, Anda dapat merutekan permintaan berdasarkan konten aktual pesan HTTP, bukan hanya paket jaringan TCP tingkat rendah.

Sepanjang buku ini, kami mengadvokasi hosting sistem cloud-native di Kubernetes. Orkestrator kontainer, Kubernetes mengotomatiskan penyebaran, penskalaan, dan operasionalitas beban kerja dalam kontainer. Azure Application Gateway dapat dikonfigurasi sebagai gateway API untuk kluster Azure Kubernetes Service .

Pengontrol Ingress Application Gateway memungkinkan Azure Application Gateway untuk bekerja langsung dengan Azure Kubernetes Service. Gambar 4.5 menunjukkan arsitektur.

Gambar 4-5. Pengontrol Masuk Gateway Aplikasi

Kubernetes menyertakan fitur bawaan yang mendukung penyeimbangan beban HTTP (Tingkat 7), yang disebut Ingress. Ingress mendefinisikan serangkaian aturan tentang bagaimana instans layanan mikro di dalam AKS dapat diekspos ke dunia luar. Pada gambar sebelumnya, pengontrol ingress menginterpretasikan aturan ingress yang dikonfigurasi untuk kluster dan secara otomatis mengonfigurasi Azure Application Gateway. Berdasarkan aturan tersebut, Application Gateway merutekan lalu lintas ke layanan mikro yang berjalan di dalam AKS. Pengontrol masuk memantau perubahan pada aturan masuk dan melakukan penyesuaian yang sesuai pada Azure Application Gateway.

Azure API Management

Untuk sistem cloud-native skala sedang hingga besar, Anda dapat mempertimbangkan Azure API Management. Ini adalah layanan berbasis cloud yang tidak hanya menyelesaikan kebutuhan API Gateway Anda, tetapi memberikan pengalaman administratif dan pengembang dengan fitur lengkap. API Management ditampilkan dalam Gambar 4-6.

Gambar 4-6. Azure API Management

Untuk memulai, API Management mengekspos server gateway yang memungkinkan akses terkontrol ke layanan back-end berdasarkan aturan dan kebijakan yang dapat dikonfigurasi. Layanan ini dapat berada di cloud Azure, pusat data lokal Anda, atau cloud publik lainnya. Kunci API dan token JWT menentukan siapa yang dapat melakukan apa. Semua lalu lintas dicatat untuk tujuan analitis.

Untuk pengembang, API Management menawarkan portal pengembang yang menyediakan akses ke layanan, dokumentasi, dan kode sampel untuk memanggilnya. Pengembang dapat menggunakan Swagger/Open API untuk memeriksa titik akhir layanan dan menganalisis penggunaannya. Layanan ini berfungsi di seluruh platform pengembangan utama: .NET, Java, Golang, dan banyak lagi.

Portal penerbit mengekspos dasbor manajemen tempat administrator mengekspos API dan mengelola perilaku mereka. Akses layanan dapat diberikan, kesehatan layanan dipantau, dan telemetri layanan dikumpulkan. Administrator menerapkan kebijakan ke setiap titik akhir untuk memengaruhi perilaku. Kebijakan adalah pernyataan bawaan yang dijalankan secara berurutan untuk setiap panggilan layanan. Kebijakan dikonfigurasikan untuk panggilan masuk, panggilan keluar, atau diaktifkan ketika terjadi kesalahan. Kebijakan dapat diterapkan pada cakupan layanan yang berbeda untuk mengaktifkan pengurutan deterministik saat menggabungkan kebijakan. Produk ini dikirim dengan sejumlah besar kebijakan bawaan.

Berikut adalah contoh bagaimana kebijakan dapat memengaruhi perilaku layanan cloud-native Anda:

• Membatasi akses layanan.
• Menerapkan autentikasi.
• Membatasi panggilan dari satu sumber, jika perlu.
• Aktifkan Cache.
• Memblokir panggilan dari alamat IP tertentu.
• Mengontrol alur layanan.
• Konversi permintaan dari SOAP ke REST atau di antara format data yang berbeda, seperti dari XML ke JSON.

Azure API Management dapat mengekspos layanan back-end yang dihosting di mana saja - di cloud atau pusat data Anda. Untuk layanan warisan yang mungkin Anda ekspos di sistem cloud-native Anda, layanan ini mendukung REST dan SOAP API. Bahkan layanan Azure lainnya dapat diekspos melalui API Management. Anda dapat menempatkan API terkelola di atas layanan pencadangan Azure seperti Azure Service Bus atau Azure Logic Apps. Azure API Management tidak menyertakan dukungan penyeimbangan beban bawaan dan harus digunakan bersama dengan layanan penyeimbangan beban.

Azure API Management tersedia di empat tingkatan yang berbeda:

• Pengembang
• Dasar
• Standar
• Premi

Tingkat Pengembang dimaksudkan untuk beban kerja dan evaluasi non-produksi. Tingkatan lain menawarkan lebih banyak daya, fitur, dan perjanjian tingkat layanan (SLA) yang lebih tinggi secara progresif. Tingkat Premium menyediakan Azure Virtual Network dan dukungan multi-wilayah. Semua tingkatan memiliki harga tetap per jam.

Cloud Azure juga menawarkan tingkat tanpa server untuk Azure API Management. Disebut sebagai tingkat harga konsumsi, layanan ini adalah varian API Management yang dirancang di sekitar model komputasi tanpa server. Tidak seperti tingkat harga "pra-alokasi" yang sebelumnya ditampilkan, tingkat konsumsi menyediakan provisi instan dan harga bayar per tindakan.

Ini memungkinkan fitur API Gateway untuk kasus penggunaan berikut:

• Layanan mikro diimplementasikan menggunakan teknologi tanpa server seperti Azure Functions dan Azure Logic Apps.
• Sumber daya pendukung Azure seperti antrean dan topik di Azure Service Bus, penyimpanan Azure, dan lainnya.
• Layanan mikro di mana lalu lintas memiliki lonjakan besar sesekali tetapi tetap rendah sebagian besar waktu.

Tingkat konsumsi menggunakan komponen API Management layanan dasar yang sama, tetapi menggunakan arsitektur yang sama sekali berbeda berdasarkan sumber daya yang dialokasikan secara dinamis. Ini selaras dengan sempurna dengan model komputasi tanpa server:

• Tidak ada infrastruktur untuk dikelola.
• Tidak ada kapasitas yang tidak dimanfaatkan.
• Ketersediaan tinggi.
• Penskalakan otomatis.
• Biaya didasarkan pada penggunaan aktual.

Tingkatan konsumsi baru adalah pilihan yang tepat untuk sistem cloud-native yang mengekspos sumber daya tanpa server sebagai API.

Komunikasi waktu nyata

Real time, atau push, komunikasi adalah opsi lain untuk aplikasi front-end yang berkomunikasi dengan sistem cloud-native back-end melalui HTTP. Aplikasi, seperti penunjuk harga keuangan, pendidikan online, permainan, dan pembaruan kemajuan pekerjaan, memerlukan respons langsung dari sistem back-end. Dengan komunikasi HTTP normal, tidak ada cara bagi klien untuk mengetahui kapan data baru tersedia. Klien harus terus melakukan polling atau mengirim permintaan ke server. Dengan komunikasi real-time , server dapat mendorong data baru ke klien kapan saja.

Sistem real time sering ditandai oleh aliran data frekuensi tinggi dan sejumlah besar koneksi klien bersamaan. Menerapkan konektivitas real-time secara manual dapat dengan cepat menjadi kompleks, membutuhkan infrastruktur non-sepele untuk memastikan skalabilitas dan pesan yang andal kepada klien yang terhubung. Anda mungkin menemukan diri Anda mengelola instance Azure Redis Cache dan sekumpulan load balancers yang dikonfigurasi dengan sesi permanen untuk keterikatan klien.

Azure SignalR Service adalah layanan Azure yang dikelola sepenuhnya yang menyederhanakan komunikasi real time untuk aplikasi cloud-native Anda. Detail implementasi teknis seperti penyediaan kapasitas, penskalaan, dan koneksi persisten diabstraksi. Mereka ditangani bagi Anda dengan perjanjian tingkat layanan 99.9%. Anda fokus pada fitur aplikasi, bukan pipa infrastruktur.

Setelah diaktifkan, layanan HTTP berbasis cloud dapat mendorong pembaruan konten langsung ke klien yang terhubung, termasuk browser, aplikasi seluler, dan desktop. Klien diperbarui tanpa perlu melakukan polling pada server. Azure SignalR mengabstraksi teknologi transportasi yang menciptakan konektivitas real-time, termasuk WebSockets, Server-Side Events, dan Long Polling. Pengembang berfokus pada pengiriman pesan ke semua atau subset tertentu dari klien yang terhubung.

Gambar 4-7 menunjukkan sekumpulan Klien HTTP yang terhubung ke aplikasi cloud-native dengan Azure SignalR diaktifkan.

Gambar 4-7. Azure SignalR

Keuntungan lain dari Azure SignalR Service hadir dengan menerapkan layanan cloud-native Tanpa Server. Mungkin kode Anda dijalankan sesuai permintaan dengan pemicu Azure Functions. Skenario ini bisa sulit karena kode Anda tidak mempertahankan koneksi panjang dengan klien. Azure SignalR Service dapat menangani situasi ini karena layanan sudah mengelola koneksi untuk Anda.

Azure SignalR Service terintegrasi erat dengan layanan Azure lainnya, seperti Azure SQL Database, Service Bus, atau Redis Cache, membuka banyak kemungkinan untuk aplikasi cloud-native Anda.

SebelumnyaBerikutnya