Pola gateway API versus Komunikasi langsung klien-ke-layanan mikro

  • Artikel

Tip

Konten ini adalah kutipan dari eBook, .NET Microservices Architecture for Containerized .NET Applications, tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis dan dapat dibaca secara offline.

Unduh PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Dalam arsitektur layanan mikro, setiap layanan mikro mengekspos satu set (biasanya) titik akhir secara mendetail. Fakta ini dapat berdampak pada komunikasi klien-ke-layanan mikro, seperti yang dijelaskan di bagian ini.

Komunikasi langsung klien-ke-layanan mikro

Pendekatan yang mungkin adalah dengan menggunakan arsitektur komunikasi klien-ke-layanan mikro langsung. Dalam pendekatan ini, aplikasi klien dapat membuat permintaan langsung ke beberapa layanan mikro, seperti yang ditunjukkan pada Gambar 4-12.

Diagram showing client-to-microservice communication architecture.

Gambar 4-12. Menggunakan arsitektur komunikasi klien-ke-layanan mikro langsung

Dalam pendekatan ini, setiap layanan mikro memiliki titik akhir publik, kadang-kadang dengan port TCP yang berbeda untuk setiap layanan mikro. Contoh URL untuk layanan tertentu bisa menjadi URL berikut di Azure:

http://eshoponcontainers.westus.cloudapp.azure.com:88/

Dalam lingkungan produksi berdasarkan kluster, URL tersebut akan memetakan ke penyeimbang beban yang digunakan dalam kluster, yang pada gilirannya mendistribusikan permintaan di seluruh layanan mikro. Di lingkungan produksi, Anda dapat memiliki Application Delivery Controller (ADC) seperti Azure Application Gateway antara layanan mikro Anda dan Internet. Lapisan ini bertindak sebagai tingkat transparan yang tidak hanya melakukan penyeimbangan beban, tetapi mengamankan layanan Anda dengan menawarkan penghentian SSL. Pendekatan ini meningkatkan beban host Anda dengan membongkar penghentian SSL intensif CPU dan tugas perutean lainnya ke Azure Application Gateway. Bagaimana pun, penyeimbang beban dan ADC transparan dari sudut pandang arsitektur aplikasi logis.

Arsitektur komunikasi klien-ke-layanan mikro langsung bisa cukup baik untuk aplikasi kecil berbasis layanan mikro, terutama jika aplikasi klien adalah aplikasi web sisi server seperti aplikasi MVC ASP.NET. Namun, ketika Anda membangun aplikasi berbasis layanan mikro besar dan kompleks (misalnya, saat menangani puluhan jenis layanan mikro), dan terutama ketika aplikasi klien adalah aplikasi seluler jarak jauh atau aplikasi web SPA, pendekatan tersebut menghadapi beberapa masalah.

Pertimbangkan pertanyaan berikut saat mengembangkan aplikasi besar berdasarkan layanan mikro:

  • Bagaimana cara aplikasi klien dapat meminimalkan jumlah permintaan ke back end dan mengurangi komunikasi yang ramai ke beberapa layanan mikro?

Berinteraksi dengan beberapa layanan mikro untuk membangun satu layar antarmuka pengguna meningkatkan jumlah perjalanan pulang pergi di internet. Pendekatan ini meningkatkan latensi dan kompleksitas di sisi antarmuka pengguna. Idealnya, respons harus diagregasi secara efisien di sisi server. Pendekatan ini mengurangi latensi, karena beberapa bagian data kembali secara paralel dan beberapa antarmuka pengguna dapat segera menampilkan data setelah siap.

  • Bagaimana cara Anda dapat menangani masalah lintas sektoral seperti otorisasi, transformasi data, dan pengiriman permintaan dinamis?

Mengimplementasikan masalah keamanan dan lintas sektoral seperti keamanan dan otorisasi pada setiap layanan mikro dapat memerlukan upaya pengembangan yang signifikan. Pendekatan yang mungkin adalah memiliki layanan tersebut dalam host Docker atau kluster internal untuk membatasi akses langsung ke mereka dari luar, dan untuk menerapkan masalah lintas sektoral tersebut di tempat terpusat, seperti API Gateway.

  • Bagaimana cara aplikasi klien dapat berkomunikasi dengan layanan yang menggunakan protokol yang tidak ramah Internet?

Protokol yang digunakan di sisi server (seperti AMQP atau protokol biner) tidak didukung di aplikasi klien. Oleh karena itu, permintaan harus dilakukan melalui protokol seperti HTTP/HTTPS dan diterjemahkan ke protokol lain setelahnya. Pendekatan man-in-the-middle dapat membantu dalam situasi ini.

  • Bagaimana cara Anda dapat membentuk fasad yang dibuat khusus untuk aplikasi seluler?

API dari beberapa layanan mikro mungkin tidak dirancang dengan baik untuk kebutuhan aplikasi klien yang berbeda. Misalnya, kebutuhan aplikasi seluler mungkin berbeda dari kebutuhan aplikasi web. Untuk aplikasi seluler, Anda mungkin perlu mengoptimalkan lebih jauh sehingga respons data bisa lebih efisien. Anda dapat melakukan fungsionalitas ini dengan menggabungkan data dari beberapa layanan mikro serta mengembalikan satu set data, dan terkadang menghilangkan data apa pun dalam respons yang tidak diperlukan oleh aplikasi seluler. Tentu saja, Anda mungkin juga mengompresi data tersebut. Sekali lagi, fasad atau API antara aplikasi seluler dan layanan mikro dapat sesuai untuk skenario ini.

Alasan mempertimbangkan API Gateway, bukan komunikasi klien-ke-layanan mikro langsung

Dalam arsitektur layanan mikro, aplikasi klien biasanya perlu menggunakan fungsionalitas dari lebih dari satu layanan mikro. Jika konsumsi tersebut dilakukan secara langsung, klien perlu menangani beberapa panggilan ke titik akhir layanan mikro. Apa yang terjadi ketika aplikasi berevolusi dan layanan mikro baru diperkenalkan atau layanan mikro yang ada diperbarui? Jika aplikasi Anda memiliki banyak layanan mikro, menangani begitu banyak titik akhir dari aplikasi klien dapat menjadi mimpi buruk. Karena aplikasi klien akan digabungkan dengan titik akhir internal tersebut, mengembangkan layanan mikro di masa depan dapat menyebabkan dampak yang tinggi bagi aplikasi klien.

Oleh karena itu, memiliki tingkat perantara atau tingkat tidak langsung (Gateway) dapat sesuai untuk aplikasi berbasis layanan mikro. Jika Anda tidak memiliki API Gateway, aplikasi klien harus mengirim permintaan langsung ke layanan mikro dan itu menimbulkan masalah, seperti masalah berikut:

  • Coupling: Tanpa pola API Gateway, aplikasi klien digabungkan ke layanan mikro internal. Aplikasi klien perlu mengetahui bagaimana beberapa area aplikasi diurai dalam layanan mikro. Saat mengembangkan dan memfaktorkan ulang layanan mikro internal, tindakan tersebut memengaruhi pemeliharaan karena menyebabkan perubahan yang mengganggu pada aplikasi klien karena referensi langsung ke layanan mikro internal dari aplikasi klien. Aplikasi klien perlu sering diperbarui, membuat solusi lebih sulit untuk berkembang.

  • Terlalu banyak perjalanan pulang pergi: Satu halaman/layar di aplikasi klien mungkin memerlukan beberapa panggilan ke beberapa layanan. Pendekatan tersebut dapat menyebabkan beberapa perjalanan pulang pergi jaringan antara klien dan server, menambahkan latensi yang signifikan. Agregasi yang ditangani dalam tingkat menengah dapat meningkatkan performa dan pengalaman pengguna untuk aplikasi klien.

  • Masalah keamanan: Tanpa gateway, semua layanan mikro harus diekspos ke "dunia eksternal", membuat permukaan serangan lebih besar daripada jika Anda menyembunyikan layanan mikro internal yang tidak langsung digunakan oleh aplikasi klien. Makin kecil permukaan serangan, makin aman aplikasi Anda.

  • Masalah lintas sektoral: Setiap layanan mikro yang diterbitkan secara publik harus menangani masalah seperti otorisasi dan SSL. Dalam banyak situasi, kekhawatiran tersebut dapat ditangani dalam satu tingkat sehingga layanan mikro internal disederhanakan.

Apa itu pola API Gateway?

Saat Anda merancang dan membangun aplikasi berbasis layanan mikro yang besar atau kompleks dengan beberapa aplikasi klien, pendekatan yang baik untuk dipertimbangkan adalah Gateway API. Pola ini adalah layanan yang menyediakan titik masuk tunggal untuk grup layanan mikro tertentu. Ini mirip dengan pola Fasad dari desain berorientasi objek, tetapi dalam hal ini, ini adalah bagian dari sistem terdistribusi. Pola API Gateway juga terkadang dikenal sebagai "backend untuk frontend" (BFF) karena Anda membangunnya sambil memikirkan kebutuhan aplikasi klien.

Oleh karena itu, gateway API berada di antara aplikasi klien dan layanan mikro. Ini bertindak sebagai proksi terbalik, permintaan perutean dari klien ke layanan. Ini juga dapat menyediakan fitur lintas sektoral lainnya seperti autentikasi, penghentian SSL, dan cache.

Gambar 4-13 menunjukkan bagaimana API Gateway kustom dapat masuk ke dalam arsitektur berbasis layanan mikro yang disederhanakan hanya dengan beberapa layanan mikro.

Diagram showing an API Gateway implemented as a custom service.

Gambar 4-13. Menggunakan API Gateway yang diimplementasikan sebagai layanan kustom

Aplikasi terhubung ke satu titik akhir, API Gateway, yang dikonfigurasi untuk meneruskan permintaan ke layanan mikro individual. Dalam contoh ini, API Gateway akan diimplementasikan sebagai layanan ASP.NET Core WebHost kustom yang berjalan sebagai kontainer.

Penting untuk disorot bahwa dalam diagram tersebut, Anda akan menggunakan satu layanan API Gateway kustom yang menghadap ke beberapa aplikasi dan aplikasi klien yang berbeda. Fakta itu bisa menjadi risiko penting karena layanan API Gateway Anda akan tumbuh dan berkembang berdasarkan banyak persyaratan yang berbeda dari aplikasi klien. Pada akhirnya, itu akan membengkak karena kebutuhan yang berbeda dan secara efektif dapat mirip dengan aplikasi monolitik atau layanan monolitik. Itu sebabnya sangat disarankan untuk membagi API Gateway di beberapa layanan atau beberapa API Gateway yang lebih kecil, satu per jenis faktor bentuk aplikasi klien, misalnya.

Anda harus berhati-hati saat mengimplementasikan pola API Gateway. Biasanya bukan ide yang baik untuk memiliki satu API Gateway yang menggabungkan semua layanan mikro internal aplikasi Anda. Jika ya, ini bertindak sebagai agregator atau orkestrator monolitik dan melanggar otonomi layanan mikro dengan mengompilasi semua layanan mikro.

Oleh karena itu, API Gateway harus dipisahkan berdasarkan batas bisnis dan aplikasi klien serta tidak bertindak sebagai agregator tunggal untuk semua layanan mikro internal.

Saat membagi tingkat API Gateway menjadi beberapa API Gateway, jika aplikasi Anda memiliki beberapa aplikasi klien, yang dapat menjadi pivot utama saat mengidentifikasi beberapa jenis API Gateway, sehingga Anda dapat memiliki fasad yang berbeda untuk kebutuhan setiap aplikasi klien. Kasus ini adalah pola bernama "Backend untuk Frontend" (BFF) tempat setiap API Gateway dapat menyediakan API berbeda yang disesuaikan untuk setiap jenis aplikasi klien, bahkan mungkin didasarkan pada faktor bentuk klien dengan menerapkan kode adaptor tertentu yang di bawahnya memanggil beberapa layanan mikro internal, seperti yang ditunjukkan pada gambar berikut:

Diagram showing multiple custom API Gateways.

Gambar 4-13.1. Menggunakan beberapa API Gateway kustom

Gambar 4-13.1 menunjukkan API Gateway yang dipisahkan oleh jenis klien; satu untuk klien seluler dan satu untuk klien web. Aplikasi web tradisional terhubung ke layanan mikro MVC yang menggunakan API Gateway web. Contohnya menggambarkan arsitektur yang disederhanakan dengan beberapa API Gateway mendetail. Dalam hal ini, batasan yang diidentifikasi untuk setiap API Gateway didasarkan murni pada pola "Backend untuk Frontend" (BFF), karenanya hanya berdasarkan API yang diperlukan per aplikasi klien. Namun, dalam aplikasi yang lebih besar Anda juga harus melaju lebih jauh dan membuat API Gateway lain berdasarkan batas bisnis sebagai pivot desain kedua.

Fitur utama dalam pola API Gateway

API Gateway dapat menawarkan beberapa fitur. Bergantung pada produk yang mungkin menawarkan fitur yang lebih kaya atau lebih sederhana, namun, fitur yang paling penting dan dasar untuk API Gateway apa pun adalah pola desain berikut:

Proksi terbalik atau perutean gateway. API Gateway menawarkan proksi terbalik untuk mengalihkan atau merutekan permintaan (perutean lapisan 7, biasanya permintaan HTTP) ke titik akhir layanan mikro internal. Gateway menyediakan satu titik akhir atau URL untuk aplikasi klien, lalu secara internal memetakan permintaan ke sekelompok layanan mikro internal. Fitur perutean ini membantu memisahkan aplikasi klien dari layanan mikro, tetapi juga cocok saat memodernisasi API monolitik dengan menempatkan API Gateway di antara API monolitik dan aplikasi klien, sehingga Anda dapat menambahkan API baru sebagai layanan mikro baru sambil tetap menggunakan API monolitik warisan hingga dibagi menjadi banyak layanan mikro di masa mendatang. Karena API Gateway, aplikasi klien tidak akan melihat apakah API yang digunakan diimplementasikan sebagai layanan mikro internal atau API monolitik dan yang lebih penting, saat mengembangkan dan memfaktor ulang API monolitik menjadi layanan mikro, berkat perutean API Gateway, aplikasi klien tidak akan terpengaruh dengan perubahan URI apa pun.

Untuk informasi lebih lanjut, lihat Pola perutean gateway.

Meminta agregasi. Sebagai bagian dari pola gateway, Anda dapat menggabungkan beberapa permintaan klien (biasanya permintaan HTTP) yang menargetkan beberapa layanan mikro internal ke dalam satu permintaan klien. Pola ini sangat sesuai ketika halaman/layar klien membutuhkan informasi dari beberapa layanan mikro. Dengan pendekatan ini, aplikasi klien mengirim satu permintaan ke API Gateway yang mengirimkan beberapa permintaan ke layanan mikro internal, lalu menggabungkan hasilnya dan mengirim semuanya kembali ke aplikasi klien. Manfaat utama dan tujuan dari pola desain ini adalah untuk mengurangi obrolan antara aplikasi klien dan API backend, yang sangat penting untuk aplikasi jarak jauh dari pusat data tempat layanan mikro berada, seperti aplikasi seluler atau permintaan yang berasal dari aplikasi SPA yang berasal dari JavaScript di browser jarak jauh klien. Untuk aplikasi web reguler yang melakukan permintaan di lingkungan server (seperti aplikasi web ASP.NET Core MVC), pola ini tidak begitu penting karena latensinya sangat jauh lebih kecil dibandingkan untuk aplikasi klien jarak jauh.

Bergantung pada produk API Gateway yang Anda gunakan, mungkin dapat melakukan agregasi ini. Namun, dalam banyak kasus, lebih fleksibel untuk membuat layanan mikro agregasi di bawah cakupan API Gateway, sehingga Anda menentukan agregasi dalam kode (yaitu, kode C#):

Untuk informasi lebih lanjut, lihat Pola agregasi gateway.

Masalah lintas sektoral atau pembongkaran gateway. Bergantung pada fitur yang ditawarkan oleh setiap produk API Gateway, Anda dapat membongkar fungsionalitas dari layanan mikro individual ke gateway, yang menyederhanakan implementasi setiap layanan mikro dengan mengonsolidasikan masalah lintas sektoral menjadi satu tingkat. Pendekatan ini sangat cocok untuk fitur khusus yang mungkin rumit untuk diterapkan dengan benar di setiap layanan mikro internal, seperti fungsi berikut:

  • Autentikasi dan otorisasi
  • Integrasi penemuan layanan
  • Pembuatan cache respons
  • Kebijakan coba ulang, pemutus sirkuit, dan QoS
  • Pembatasan dan pelambatan laju
  • Penyeimbangan Beban
  • Pengelogan, pelacakan, korelasi
  • Transformasi header, string kueri, dan klaim
  • Daftar IP yang diizinkan

Untuk informasi lebih lanjut, lihat Pola pembongkaran gateway.

Menggunakan produk dengan fitur API Gateway

Ada lebih banyak masalah lintas sektoral yang ditawarkan oleh produk API Gateway, tergantung pada setiap implementasi. Kita akan menjelajahi di sini:

Azure API Management

Azure API Management (seperti yang ditunjukkan pada Gambar 4-14) tidak hanya memecahkan kebutuhan API Gateway Anda, tetapi menyediakan fitur seperti mengumpulkan wawasan dari API Anda. Jika Anda menggunakan solusi manajemen API, API Gateway hanya merupakan komponen dalam solusi manajemen API lengkap tersebut.

Diagram showing how to use Azure API Management as your API gateway.

Gambar 4-14. Menggunakan Azure API Management untuk API Gateway Anda

Azure API Management memecahkan kebutuhan API Gateway dan Manajemen Anda seperti pengelogan, keamanan, pengukuran, dll. Dalam hal ini, saat menggunakan produk seperti Azure API Management, fakta bahwa Anda mungkin memiliki satu API Gateway tidak begitu berisiko karena API Gateway semacam ini "lebih tipis", yang berarti Anda tidak menerapkan kode C# kustom yang dapat berkembang ke arah komponen monolitik.

Produk API Gateway biasanya bertindak seperti proksi terbalik untuk komunikasi masuk, tempat Anda juga dapat memfilter API dari layanan mikro internal ditambah menerapkan otorisasi ke API yang diterbitkan di tingkat tunggal ini.

Wawasan yang tersedia dari sistem API Management membantu Anda mendapatkan pemahaman tentang bagaimana API Anda digunakan dan performanya. Mereka melakukan aktivitas ini dengan memungkinkan Anda melihat laporan analitik mendekati real-time dan mengidentifikasi tren yang mungkin memengaruhi bisnis Anda. Selain itu, Anda dapat memiliki log tentang aktivitas permintaan dan respons untuk analisis online serta offline lebih lanjut.

Dengan Azure API Management, Anda dapat mengamankan API menggunakan kunci, token, dan pemfilteran IP. Fitur-fitur ini memungkinkan Anda memberlakukan kuota dan batas laju yang fleksibel dan terperinci, memodifikasi bentuk dan perilaku API Anda menggunakan kebijakan, serta meningkatkan performa dengan penembolokan respons.

Dalam panduan ini dan aplikasi sampel referensi (eShopOnContainers), arsitektur terbatas pada arsitektur kontainer yang lebih sederhana dan dibuat khusus untuk berfokus pada kontainer biasa tanpa menggunakan produk PaaS seperti Azure API Management. Namun, untuk aplikasi besar berbasis layanan mikro yang disebarkan ke Microsoft Azure, kami mendorong Anda untuk mengevaluasi Azure API Management sebagai dasar untuk API Gateway Anda dalam produksi.

Ocelot

Ocelot adalah API Gateway ringan, direkomendasikan untuk pendekatan yang lebih sederhana. Ocelot adalah API Gateway berbasis .NET Core Sumber Terbuka yang dibuat khusus untuk arsitektur layanan mikro yang membutuhkan titik masuk terpadu ke dalam sistem mereka. Ini ringan, cepat, dan dapat diskalakan serta menyediakan perutean dan autentikasi di antara banyak fitur lainnya.

Alasan utama memilih Ocelot untuk aplikasi referensi eShopOnContainers 2.0 adalah karena Ocelot adalah API Gateway ringan .NET Core yang dapat Anda sebarkan ke lingkungan penyebaran aplikasi yang sama tempat Anda menyebarkan layanan mikro/kontainer, seperti Host Docker, Kubernetes, dll. Karena didasarkan pada .NET Core, lintas platform memungkinkan Anda menyebarkan di Linux atau Windows.

Diagram sebelumnya yang menunjukkan API Gateway kustom yang berjalan dalam kontainer adalah persis bagaimana Anda juga dapat menjalankan Ocelot dalam kontainer dan aplikasi berbasis layanan mikro.

Selain itu, ada banyak produk lain di pasar yang menawarkan fitur API Gateways, seperti Apigee, Kong, MuleSoft, WSO2, dan produk lainnya seperti Linkerd dan Istio untuk fitur pengontrol ingress jala layanan.

Setelah bagian penjelasan arsitektur dan pola awal, bagian berikutnya menjelaskan cara menerapkan API Gateway dengan Ocelot.

Kelemahan pola API Gateway

  • Kelemahan yang paling penting adalah bahwa ketika Anda menerapkan API Gateway, Anda mengumpulkan tingkat tersebut dengan layanan mikro internal. Coupling seperti ini mungkin menimbulkan kesulitan serius untuk aplikasi Anda. Clemens Vaster, arsitek di tim Azure Service Bus, menyebut potensi kesulitan ini sebagai "ESB baru" dalam sesi "Pesan dan Layanan Mikro" di GOTO 2016.

  • Menggunakan API Gateway layanan mikro menciptakan kemungkinan titik kegagalan tunggal tambahan.

  • API Gateway dapat memperkenalkan peningkatan waktu respons karena panggilan jaringan tambahan. Namun, panggilan ekstra ini biasanya memiliki dampak yang lebih kecil daripada memiliki antarmuka klien yang terlalu ramai yang secara langsung memanggil layanan mikro internal.

  • Jika tidak diskalakan dengan benar, API Gateway dapat menjadi hambatan.

  • API Gateway memerlukan biaya pengembangan tambahan dan pemeliharaan di masa mendatang jika mencakup logika kustom dan agregasi data. Pengembang harus memperbarui API Gateway untuk mengekspos setiap titik akhir layanan mikro. Selain itu, perubahan implementasi dalam layanan mikro internal dapat menyebabkan perubahan kode di tingkat API Gateway. Namun, jika API Gateway hanya menerapkan keamanan, pengelogan, dan penerapan versi (seperti saat menggunakan Azure API Management), biaya pengembangan tambahan ini mungkin tidak berlaku.

  • Jika API Gateway dikembangkan oleh satu tim, mungkin ada penyempitan pengembangan. Aspek ini adalah alasan lain mengapa pendekatan yang lebih baik adalah memiliki beberapa API Gateway mendetail yang merespons kebutuhan klien yang berbeda. Anda juga dapat memisahkan API Gateway secara internal ke dalam beberapa area atau lapisan yang dimiliki oleh berbagai tim yang bekerja pada layanan mikro internal.

Sumber daya tambahan

SebelumnyaBerikutnya