Bagikan melalui

Pola API Gateway versus komunikasi langsung klien ke microservices

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Kontainer, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Dalam Kontainer: gambar kecil sampul eBook.

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

Komunikasi langsung antara klien dan layanan mikro

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

Diagram memperlihatkan arsitektur komunikasi klien-ke-layanan mikro.

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

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 yang didasarkan pada kluster, URL tersebut akan disesuaikan dengan penyeimbang muatan yang digunakan dalam kluster, yang selanjutnya mendistribusikan permintaan di seluruh layanan mikro. Di lingkungan produksi, Anda dapat memiliki Pengontrol Pengiriman Aplikasi (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 mengoptimalkan beban kerja host Anda dengan membebaskan penghentian SSL yang intensif menggunakan CPU dan tugas perutean lainnya ke Azure Application Gateway. Bagaimanapun, load balancer dan ADC transparan dari sudut pandang arsitektur aplikasi logis.

Arsitektur komunikasi klien-ke-layanan mikro langsung bisa cukup baik untuk aplikasi berbasis layanan mikro kecil, 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 aplikasi klien dapat meminimalkan jumlah permintaan ke backend dan mengurangi komunikasi yang berlebihan ke beberapa layanan mikro?

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

  • Bagaimana Anda dapat menangani kekhawatiran lintas fungsi seperti otorisasi, transformasi data, dan penanganan permintaan dinamis?

Menerapkan keamanan dan perhatian lintas sektor seperti 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 kepedulian lintas fungsi dalam satu tempat terpusat, seperti API Gateway.

  • Bagaimana 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 Anda dapat membentuk fasad yang khusus dibuat 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 dapat lebih efisien. Anda dapat melakukan fungsionalitas ini dengan menggabungkan data dari beberapa layanan mikro dan mengembalikan satu set data, dan terkadang menghilangkan data apa pun dalam respons yang tidak diperlukan oleh aplikasi seluler. Dan, tentu saja, Anda mungkin mengompresi data tersebut. Sekali lagi, fasad atau API di antara aplikasi seluler dan layanan mikro dapat nyaman untuk skenario ini.

Mengapa mempertimbangkan API Gateway alih-alih komunikasi langsung antara klien dan layanan mikro

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 berkembang 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 tinggi untuk aplikasi klien.

Oleh karena itu, memiliki tingkat menengah atau tingkat tidak langsung (Gateway) dapat nyaman untuk aplikasi berbasis layanan mikro. Jika Anda tidak memiliki API Gateway, aplikasi klien harus mengirim permintaan langsung ke layanan mikro dan yang 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 merefaktor layanan mikro internal, tindakan tersebut berdampak pada pemeliharaan karena menyebabkan perubahan yang mengganggu pada aplikasi klien akibat referensi langsung dari aplikasi klien ke layanan mikro internal. 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 mengakibatkan 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. Semakin kecil permukaan serangan, semakin aman aplikasi Anda.

  • Masalah lintas pemotongan: 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 besar atau kompleks dengan beberapa aplikasi klien, pendekatan yang baik untuk dipertimbangkan dapat menjadi API Gateway. Pola ini adalah layanan yang menyediakan titik masuk tunggal untuk kelompok layanan mikro tertentu. Ini mirip dengan pola Facade 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, mengalihkan permintaan dari klien ke layanan. Ini juga dapat menyediakan berbagai fitur lintas fungsi lainnya seperti autentikasi, penghentian koneksi 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 memperlihatkan API Gateway yang diimplementasikan sebagai layanan kustom.

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 WebHost inti ASP.NET 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 klien dan berbeda. Fakta itu bisa menjadi risiko penting karena layanan API Gateway Anda akan tumbuh dan berkembang berdasarkan banyak persyaratan yang berbeda dari aplikasi klien. Akhirnya, akan menjadi membengkak karena kebutuhan yang berbeda dan dapat secara efektif mirip dengan aplikasi monolitik atau layanan monolitik. Itulah sebabnya sangat disarankan untuk membagi API Gateway dalam beberapa layanan atau beberapa API Gateway yang lebih kecil, satu per jenis faktor formulir aplikasi klien, misalnya.

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

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

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

Diagram memperlihatkan beberapa GATEWAY API kustom.

Gambar 4-13.1. Menggunakan beberapa Gateway API kustom

Gambar 4-13.1 menunjukkan GATEWAY API 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 gateway API yang berbutir halus. Dalam hal ini, batas yang diidentifikasi untuk setiap API Gateway didasarkan murni pada pola "Backend for Frontend" (BFF), sehingga hanya berdasarkan API yang diperlukan per aplikasi klien. Tetapi dalam aplikasi yang lebih besar, Anda juga harus melangkah lebih jauh dan membuat pintu gerbang API lain berdasarkan batasan bisnis sebagai pivot desain kedua.

Fitur utama dalam pola API Gateway

API Gateway dapat menawarkan beberapa fitur. Tergantung 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 pintu gerbang. 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 nyaman saat memodernisasi API monolitik dengan memasang API Gateway di antara API monolitik dan aplikasi klien, maka Anda dapat menambahkan API baru sebagai layanan mikro baru saat masih 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 merefaktor API monolitik menjadi layanan mikro, berkat perutean API Gateway, aplikasi klien tidak akan terpengaruh dengan perubahan URI apa pun.

Untuk informasi selengkapnya, 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 nyaman 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 dan kemudian 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 tinggal, 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 ASP.NET aplikasi web Core MVC), pola ini tidak begitu penting karena latensinya sangat jauh lebih kecil daripada 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 selengkapnya, lihat Pola agregasi gateway.

Pemikiran lintas sektor atau pengalihan gateway. Bergantung pada fitur yang tersedia untuk setiap produk API Gateway, Anda dapat memindahkan fungsionalitas dari layanan mikro individual ke gateway, yang menyederhanakan implementasi setiap layanan mikro dengan mengonsolidasikan isu umum ke dalam satu lapisan. Pendekatan ini sangat nyaman untuk fitur khusus yang dapat kompleks untuk diimplementasikan dengan benar di setiap layanan mikro internal, seperti fungsionalitas berikut:

  • Autentikasi dan otorisasi
  • Integrasi penemuan layanan
  • Penggunaan cache respons
  • Kebijakan pengulangan, pemutus sirkuit, dan QoS
  • Pembatasan laju dan pengendalian kecepatan
  • Penyeimbangan beban
  • Pengelogan, pelacakan, korelasi
  • Transformasi header, kueri string, dan klaim
  • Daftar ip yang diizinkan

Untuk informasi selengkapnya, lihat Pola Pemindahan Beban Gateway.

Menggunakan produk dengan fitur API Gateway

Mungkin ada lebih banyak concern-concern lintas fungsi yang ditawarkan oleh produk API Gateway tergantung pada implementasi masing-masing. Kami 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 penuh tersebut.

Diagram memperlihatkan cara menggunakan Azure API Management sebagai gateway API Anda.

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

Azure API Management memecahkan kebutuhan API Gateway dan Management 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 JENIS API Gateway ini "lebih tipis", yang berarti Bahwa Anda tidak menerapkan kode C# kustom yang dapat berkembang menuju komponen monolitik.

Produk API Gateway biasanya bertindak seperti proksi terbalik untuk komunikasi masuk, di mana Anda juga dapat memfilter API dari layanan mikro internal ditambah menerapkan otorisasi ke API yang diterbitkan dalam 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 dan 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, dan 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. Tetapi untuk aplikasi besar berbasis layanan mikro yang disebarkan ke Microsoft Azure, kami mendorong Anda untuk mengevaluasi Azure API Management sebagai basis untuk API Gateway Anda dalam produksi.

Ocelot

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

Alasan utama untuk 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 Docker Host, Kubernetes, dll. Dan karena didasarkan pada .NET Core, lintas platform memungkinkan Anda untuk menyebarkan di Linux atau Windows.

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

Selain itu, ada banyak produk lain di pasar yang menawarkan fitur Gateway API, seperti Apigee, Kong, MuleSoft, WSO2, dan produk lainnya seperti Linkerd dan Istio untuk fitur pengontrol ingress di 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 mengkumpulkan tingkat tersebut dengan layanan mikro internal. Kopling seperti ini mungkin menimbulkan kesulitan serius untuk aplikasi Anda. Clemens Vaster, arsitek di tim Azure Service Bus, mengacu pada potensi kesulitan ini sebagai "ESB baru" dalam sesi "Olahpesan dan Layanan Mikro" di GOTO 2016.

  • Menggunakan API Gateway layanan mikro menciptakan satu titik kegagalan tunggal tambahan yang mungkin terjadi.

  • API Gateway dapat memperkenalkan peningkatan waktu respons karena panggilan jaringan tambahan. Namun, panggilan ekstra ini biasanya memiliki dampak yang lebih kecil dibandingkan dengan antarmuka klien yang terlalu banyak melakukan komunikasi langsung untuk 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 menyertakan 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 berbutir halus yang menanggapi kebutuhan klien yang berbeda. Anda juga dapat memisahkan API Gateway secara internal ke beberapa area atau lapisan yang dimiliki oleh berbagai tim yang bekerja pada layanan mikro internal.

Sumber daya tambahan

SebelumnyaBerikutnya

  • Last updated on