Service Fabric dengan ringkasan Azure API Management

Aplikasi cloud biasanya memerlukan gateway ujung depan untuk menyediakan satu titik masuk bagi pengguna, perangkat, atau aplikasi lainnya. Dalam Service Fabric, gateway dapat menjadi layanan stateless seperti aplikasi ASP.NET Core, atau layanan lain yang dirancang untuk jalan masuk lalu lintas, seperti Event Hubs, IoT Hub, atau Azure API Management.

Artikel ini adalah pengantar untuk menggunakan Azure API Management sebagai gateway ke aplikasi Service Fabric Anda. API Management terintegrasi langsung dengan Service Fabric, memungkinkan Anda menerbitkan API dengan serangkaian aturan perutean yang kaya ke layanan Service Fabric back-end Anda.

Ketersediaan

Penting

Fitur ini tersedia di tingkat Premium dan Pengembang API Management karena dukungan jaringan virtual yang diminta.

Arsitektur

Arsitektur Service Fabric umum menggunakan aplikasi web satu halaman yang melakukan panggilan HTTP ke layanan back-end yang mengekspos API HTTP. Aplikasi sampel memulai Service Fabric menunjukkan contoh arsitektur ini.

Dalam skenario ini, layanan web stateless berfungsi sebagai gateway ke dalam aplikasi Service Fabric. Pendekatan ini mengharuskan Anda menulis layanan web yang dapat memproksi permintaan HTTP ke layanan back-end, seperti yang ditunjukkan pada diagram berikut:

Ketika aplikasi menjadi kompleks, begitu juga gateway yang harus menyajikan API di depan segudang layanan back-end. Azure API Management dirancang untuk menangani API kompleks dengan aturan perutean, kontrol akses, pembatasan tarif, pemantauan, pencatatan peristiwa, dan caching respons dengan pekerjaan minimal di pihak Anda. Azure API Management mendukung penemuan layanan Service Fabric, resolusi partisi, dan pemilihan replika untuk merutekan permintaan secara cerdas langsung ke layanan back-end di Service Fabric sehingga Anda tidak perlu menulis gateway API stateless Anda sendiri.

Dalam skenario ini, UI web masih dilayani melalui layanan web, sementara panggilan API HTTP dikelola dan dirutekan melalui Azure API Management, seperti yang ditunjukkan pada diagram berikut:

Skenario aplikasi

Layanan dalam Service Fabric mungkin stateless atau stateful, dan dapat dipartisi menggunakan salah satu dari tiga skema: singleton, int-64 rang, dan named. Resolusi titik akhir layanan memerlukan identifikasi partisi tertentu dari instans layanan tertentu. Saat menyelesaikan titik akhir layanan, baik nama instans layanan (misalnya, fabric:/myapp/myservice) serta partisi spesifik layanan harus ditentukan, kecuali dalam kasus partisi singleton.

Azure API Management dapat digunakan dengan kombinasi layanan stateless, layanan stateful, dan skema partisi apa pun.

Mengirim lalu lintas ke layanan stateless

Dalam kasus yang paling sederhana, lalu lintas diteruskan ke instans layanan stateless. Untuk mencapai hal ini, operasi API Management berisi kebijakan pemrosesan masuk dengan back-end Service Fabric yang memetakan ke instans layanan stateless tertentu di back-end Service Fabric. Permintaan yang dikirim ke layanan tersebut dikirim ke instans acak layanan.

Contoh

Dalam skenario berikut, aplikasi Service Fabric berisi layanan stateless bernama fabric:/app/fooservice yang mengekspos API HTTP internal. Nama instans layanan terkenal dan dapat dihard-code langsung dalam kebijakan pemrosesan masuk API Management.

Mengirim lalu lintas ke layanan stateful

Mirip dengan skenario layanan stateless, lalu lintas dapat diteruskan ke instans layanan yang stateful. Dalam hal ini, operasi API Management berisi kebijakan pemrosesan masuk dengan back-end Service Fabric yang memetakan permintaan ke partisi tertentu dari instans layanan stateful tertentu. Partisi untuk memetakan setiap permintaan dihitung melalui metode lambda menggunakan beberapa input dari permintaan HTTP yang masuk, seperti nilai di jalur URL. Kebijakan dapat dikonfigurasi untuk mengirim permintaan ke replika utama saja, atau ke replika acak untuk operasi baca.

Contoh

Dalam skenario berikut, aplikasi Service Fabric berisi layanan stateful yang dipartisi bernama fabric:/app/userservice yang mengekspos API HTTP internal. Nama instans layanan terkenal dan dapat dihard-code langsung dalam kebijakan pemrosesan masuk API Management.

Layanan ini dipartisi menggunakan skema partisi Int64 dengan dua partisi dan rentang key yang mencakup Int64.MinValue ke Int64.MaxValue. Kebijakan back-end menghitung key partisi dalam rentang tersebut dengan mengonversi nilai id yang disediakan dalam jalur permintaan URL ke bilangan bulat 64-bit, meskipun algoritme apa pun dapat digunakan di sini untuk menghitung key partisi.

Kirim lalu lintas ke beberapa layanan stateless

Dalam skenario yang lebih canggih, Anda dapat menentukan operasi API Management yang memetakan permintaan ke lebih dari satu instans layanan. Dalam hal ini, setiap operasi berisi kebijakan yang memetakan permintaan ke instans layanan tertentu berdasarkan nilai dari permintaan HTTP masuk, seperti jalur URL atau string kueri, dan dalam kasus layanan stateful, partisi dalam instans layanan.

Untuk mencapai hal ini, operasi API Management berisi kebijakan pemrosesan masuk dengan back-end Service Fabric yang memetakan ke instans layanan stateless di back-end Service Fabric berdasarkan nilai yang diambil dari permintaan HTTP yang masuk. Permintaan ke layanan dikirim ke instans acak layanan.

Contoh

Dalam contoh ini, instans layanan stateless baru dibuat untuk setiap pengguna aplikasi dengan nama yang dihasilkan secara dinamis menggunakan rumus berikut:

• fabric:/app/users/<username>

  Setiap layanan memiliki nama yang unik, tetapi nama-nama tersebut tidak diketahui di muka karena layanan dibuat sebagai respons terhadap input pengguna atau admin dan dengan demikian tidak dapat dikodekan dengan keras ke dalam kebijakan APIM atau aturan perutean. Sebaliknya, nama layanan yang akan dikirim permintaan dihasilkan dalam definisi kebijakan back-end dari nilai name yang disediakan di jalur permintaan URL. Contohnya:

  • Permintaan untuk /api/users/foo dirutekan ke instans layanan fabric:/app/users/foo
  • Permintaan untuk /api/users/bar dirutekan ke instans layanan fabric:/app/users/bar

Kirim lalu lintas ke beberapa layanan stateful

Mirip dengan contoh layanan stateless, operasi API Management dapat memetakan permintaan ke lebih dari satu instans layanan yang stateful, dalam hal ini Anda juga mungkin perlu melakukan resolusi partisi untuk setiap instans layanan yang stateful.

Untuk mencapai hal ini, operasi API Management berisi kebijakan pemrosesan inbound dengan back-end Service Fabric yang memetakan ke instans layanan yang stateful di back-end Service Fabric berdasarkan nilai yang diambil dari permintaan HTTP yang masuk. Selain memetakan permintaan ke instans layanan tertentu, permintaan juga dapat dipetakan ke partisi tertentu dalam instans layanan, dan secara opsional ke replika utama atau replika sekunder acak dalam partisi.

Contoh

Dalam contoh ini, instans layanan stateful baru dibuat untuk setiap pengguna aplikasi dengan nama yang dihasilkan secara dinamis menggunakan rumus berikut:

• fabric:/app/users/<username>

  Setiap layanan memiliki nama yang unik, tetapi nama-nama tersebut tidak diketahui di muka karena layanan dibuat sebagai respons terhadap input pengguna atau admin dan dengan demikian tidak dapat dikodekan dengan keras ke dalam kebijakan APIM atau aturan perutean. Sebaliknya, nama layanan yang akan dikirim permintaan dihasilkan dalam definisi kebijakan back-end dari nilai name yang disediakan jalur permintaan URL. Contohnya:

  • Permintaan untuk /api/users/foo dirutekan ke instans layanan fabric:/app/users/foo
  • Permintaan untuk /api/users/bar dirutekan ke instans layanan fabric:/app/users/bar

Setiap instans layanan juga dipartisi menggunakan skema partisi Int64 dengan dua partisi dan rentang key yang mencakup Int64.MinValue hingga Int64.MaxValue. Kebijakan back-end menghitung key partisi dalam rentang tersebut dengan mengonversi nilai id yang disediakan dalam jalur permintaan URL ke bilangan bulat 64-bit, meskipun algoritme apa pun dapat digunakan di sini untuk menghitung key partisi.

Langkah berikutnya

Ikuti tutorial untuk menyiapkan kluster Service Fabric pertama Anda dengan API Management dan permintaan alur melalui API Management ke layanan Anda.