Bagikan melalui

Proksi terbalik di Azure Service Fabric

  • Artikel

Proksi terbalik yang ada di Azure Service Fabric membantu layanan mikro yang berjalan di kluster Service Fabric menemukan dan berkomunikasi dengan layanan lain yang memiliki titik akhir http.

Model komunikasi layanan mikro

Layanan mikro dalam Service Fabric berjalan pada subset node dalam kluster dan dapat bermigrasi di antara node karena berbagai alasan. Akibatnya, titik akhir untuk layanan mikro dapat berubah secara dinamis. Untuk menemukan dan berkomunikasi dengan layanan lain dalam kluster, layanan mikro harus melalui langkah-langkah berikut:

  1. Mengatasi lokasi layanan melalui layanan penamaan.
  2. Menyambungkan ke layanan.
  3. Gabungkan langkah-langkah sebelumnya dalam perulangan yang menerapkan resolusi layanan dan kebijakan percobaan kembali untuk diterapkan pada kegagalan koneksi

Untuk informasi selengkapnya, lihat Menyambungkan dan berkomunikasi dengan layanan.

Berkomunikasi dengan menggunakan proksi terbalik

Reverse proksi adalah layanan yang berjalan pada setiap node dan menangani resolusi titik akhir, coba lagi otomatis, dan kegagalan koneksi lainnya atas nama layanan klien. Proksi terbalik dapat dikonfigurasi untuk menerapkan berbagai kebijakan karena menangani permintaan dari layanan klien. Menggunakan proksi terbalik memungkinkan layanan klien untuk menggunakan pustaka komunikasi HTTP pihak klien dan tidak memerlukan resolusi khusus dan logika percobaan lagi dalam layanan.

Proksi terbalik mengekspos satu atau beberapa titik akhir pada node lokal untuk digunakan layanan klien untuk mengirim permintaan ke layanan lain.

Komunikasi internal

Catatan

Platform yang Didukung

Proksi terbalik di Service Fabric saat ini mendukung platform berikut

  • Windows Cluster: Windows 8 dan yang lebih baru atau Windows Server 2012 dan yang lebih baru
  • Linux Cluster: Proksi Terbalik saat ini tidak tersedia untuk kluster Linux

Menjangkau layanan mikro dari luar kluster

Model komunikasi eksternal default untuk layanan mikro adalah model opt-in di mana setiap layanan tidak dapat diakses langsung dari klien eksternal. Azure Load Balancer, yang merupakan batas jaringan antara layanan mikro dan klien eksternal, melakukan NAT dan meneruskan permintaan eksternal ke IP internal:titik akhir port. Untuk membuat titik akhir layanan mikro yang dapat diakses langsung oleh klien eksternal, Anda harus terlebih dahulu mengonfigurasi Load Balancer untuk meneruskan lalu lintas ke setiap port yang digunakan layanan dalam kluster. Namun, sebagian besar layanan mikro, terutama layanan mikro stateful, tidak berada di semua simpul kluster. Layanan mikro dapat berpindah di antara node pada kegagalan. Dalam kasus seperti itu, Load Balancer tidak dapat secara efektif menentukan lokasi node target replika yang seharusnya meneruskan lalu lintas.

Menjangkau layanan mikro melalui proksi terbalik dari luar kluster

Sebagai ganti dari mengonfigurasi port layanan individual di Load Balancer, Anda dapat mengonfigurasi hanya port proksi terbalik di Load Balancer. Konfigurasi ini memungkinkan klien di luar layanan jangkauan kluster di dalam kluster dengan menggunakan proksi terbalik tanpa konfigurasi tambahan.

Komunikasi eksternal

Peringatan

Saat Anda mengonfigurasi port proksi terbalik di Load Balancer, semua layanan mikro dalam kluster yang mengekspos titik akhir HTTP dapat diatasi dari luar kluster. Ini berarti bahwa layanan mikro yang dimaksudkan untuk menjadi internal dapat ditemukan oleh pengguna jahat yang ditentukan. Ini berpotensi menghadirkan kerentanan serius yang dapat dieksploitasi; misalnya:

  • Pengguna jahat dapat meluncurkan penolakan serangan layanan dengan berulang kali memanggil layanan internal yang tidak memiliki permukaan serangan yang cukup mengeras.
  • Pengguna jahat dapat mengirimkan paket rusak ke layanan internal yang mengakibatkan perilaku yang tidak diinginkan.
  • Layanan yang dimaksudkan untuk bersifat internal dapat mengembalikan informasi privat atau sensitif yang tidak dimaksudkan untuk diekspos ke layanan di luar kluster, sehingga memaparkan informasi sensitif ini kepada pengguna jahat.

Pastikan Anda sepenuhnya memahami dan mengurangi potensi konsekuensi keamanan untuk kluster Anda dan aplikasi yang berjalan padanya, sebelum Anda membuat port proksi terbalik menjadi publik.

Format URI untuk menangani layanan dengan menggunakan proksi terbalik

Proksi terbalik menggunakan format pengidentifikasi sumber daya seragam (URI) tertentu untuk mengidentifikasi partisi layanan yang permintaan masuknya harus diteruskan:

http(s)://<Cluster FQDN | internal IP>:Port/<ServiceInstanceName>/<Suffix path>?PartitionKey=<key>&PartitionKind=<partitionkind>&ListenerName=<listenerName>&TargetReplicaSelector=<targetReplicaSelector>&Timeout=<timeout_in_seconds>

  • http(s): Proksi terbalik dapat dikonfigurasi untuk menerima lalu lintas HTTP atau HTTPS. Untuk penerusan HTTPS, lihat Menyambungkan ke layanan aman dengan proxy terbalik setelah Anda memiliki pengaturan proksi terbalik untuk mendengarkan di HTTPS.

  • Nama domain yang sepenuhnya memenuhi syarat kluster (FQDN) | IP internal: Untuk klien eksternal, Anda dapat mengonfigurasi proksi terbalik sehingga dapat dijangkau melalui domain kluster, seperti mycluster.eastus.cloudapp.azure.com. Secara default, proksi terbalik berjalan pada setiap node. Untuk lalu lintas internal, proksi terbalik dapat dicapai di localhost atau pada IP node internal apa pun, seperti 10.0.0.1.

  • Porta: Ini adalah port, seperti 19081, yang telah ditentukan untuk proksi terbalik.

  • ServiceInstanceName: Ini adalah nama yang sepenuhnya memenuhi syarat dari instans layanan yang disebarkan yang ingin Anda jangkau tanpa skema "fabric:/". Misalnya, untuk mencapai layanan fabric:/myapp/myservice/, Anda akan menggunakan myapp/myservice.

    Nama instans layanan peka huruf besar/kecil. Menggunakan huruf besar/kecil yang berbeda untuk nama instans layanan di URL menyebabkan permintaan gagal dengan 404 (Tidak Ditemukan).

  • Jalur akhiran: Ini adalah jalur URL aktual, seperti myapi/values/add/3, untuk layanan yang ingin Anda sambungkan.

  • PartitionKey: Untuk layanan yang dipartisi, ini adalah kunci partisi komputasi dari partisi yang ingin Anda jangkau. Perhatikan bahwa ini bukan partisi ID GUID. Parameter ini tidak diperlukan untuk layanan yang menggunakan skema partisi database tunggal.

  • PartitionKind: Ini adalah skema partisi layanan. Ini bisa berupa 'Int64Range' atau 'Named'. Parameter ini tidak diperlukan untuk layanan yang menggunakan skema partisi database tunggal.

  • ListenerName Titik akhir dari layanan adalah dari formulir {"Endpoints":{"Listener1":"Endpoint1","Listener2":"Endpoint2" ...}}. Ketika layanan mengekspos beberapa titik akhir, ini mengidentifikasi titik akhir yang harus diteruskan oleh permintaan klien. Ini dapat dihilangkan jika layanan hanya memiliki satu listener.

  • TargetReplicaSelector Ini menentukan bagaimana replika target atau instans harus dipilih.

    • Ketika layanan target mendapatkan status, TargetReplicaSelector dapat berupa salah satu dari berikut: 'PrimaryReplica', 'RandomSecondaryReplica', atau 'RandomReplica'. Ketika parameter ini tidak ditentukan, defaultnya adalah 'PrimaryReplica'.
    • Ketika layanan target tidak berstatus, proksi terbalik memilih instans acak dari partisi layanan untuk meneruskan permintaan.

  • Timeout: Menentukan batas waktu untuk permintaan HTTP yang dibuat oleh proksi terbalik ke layanan atas nama permintaan klien. Nilai defaultnya adalah 120 detik. Ini adalah parameter opsional.

Contoh penggunaan

Sebagai contoh, mari kita ambil layanan fabric:/MyApp/MyService yang membuka listener HTTP pada URL berikut:

http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/

Berikut ini adalah sumber daya untuk layanan tersebut:

  • /index.html
  • /api/users/<userId>

Jika layanan menggunakan skema partisi database tunggal, parameter string kueri PartitionKey dan PartitionKind tidak diperlukan, dan layanan dapat dicapai dengan menggunakan gateway sebagai:

  • Secara eksternal: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
  • Secara internal: http://localhost:19081/MyApp/MyService

Jika layanan menggunakan skema partisi Uniform Int64, parameter string kueri PartitionKey dan PartitionKind harus digunakan untuk mencapai partisi layanan:

  • Secara eksternal: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
  • Secara internal: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range

Untuk menjangkau sumber daya yang diekspos layanan, cukup letakkan jalur sumber daya setelah nama layanan di URL:

  • Secara eksternal: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
  • Secara internal: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range

Gateway kemudian akan meneruskan permintaan ini ke URL layanan:

  • http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/index.html
  • http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/api/users/6

Penanganan khusus untuk layanan berbagi port

Proksi terbalik Service Fabric mencoba menyelesaikan alamat layanan lagi dan mencoba kembali permintaan ketika layanan tidak dapat dijangkau. Umumnya, ketika layanan tidak dapat dicapai, instans layanan atau replika telah pindah ke node yang berbeda sebagai bagian dari siklus hidup normalnya. Ketika ini terjadi, proksi terbalik mungkin menerima kesalahan koneksi jaringan yang menunjukkan bahwa titik akhir tidak lagi terbuka pada alamat yang awalnya diselesaikan.

Namun, replika atau instans layanan dapat berbagi proses host dan mungkin juga berbagi port ketika dihosting oleh server web berbasis http.sys, termasuk:

Dalam situasi ini, kemungkinan server web tersedia dalam proses host dan menanggapi permintaan, tetapi instans atau replika layanan yang diselesaikan tidak lagi tersedia di host. Dalam hal ini, gateway akan menerima respons HTTP 404 dari server web. Dengan demikian, respons HTTP 404 dapat memiliki dua arti yang berbeda:

  • Kasus #1: Alamat layanan sudah benar, tetapi sumber daya yang diminta pengguna tidak ada.
  • Kasus #2: Alamat layanan salah, dan sumber daya yang diminta pengguna mungkin ada pada node yang berbeda.

Kasus pertama adalah HTTP 404 normal, yang dianggap sebagai kesalahan pengguna. Namun, dalam kasus kedua, pengguna telah meminta sumber daya yang memang ada. Proksi terbalik tak bisa menemukannya karena layanan itu sendiri telah dipindah. Proksi terbalik perlu menyelesaikan alamat lagi dan mencoba kembali permintaan.

Oleh karena itu, proksi terbalik membutuhkan cara untuk membedakan antara dua kasus ini. Untuk membuat perbedaan itu, diperlukan petunjuk dari server.

  • Secara default, proksi terbalik mengasumsikan kasus #2 dan mencoba untuk menyelesaikan dan mengeluarkan permintaan lagi.

  • Untuk menunjukkan kasus #1 ke proksi terbalik, layanan harus mengembalikan header respons HTTP berikut:

    X-ServiceFabric : ResourceNotFound

Header respons HTTP ini menunjukkan situasi HTTP 404 normal di mana sumber daya yang diminta tidak ada, dan proksi terbalik tidak akan mencoba untuk menyelesaikan alamat layanan lagi.

Penanganan khusus untuk layanan yang berjalan dalam kontainer

Untuk layanan yang berjalan di dalam kontainer, Anda dapat menggunakan variabel lingkungan, Fabric_NodeIPOrFQDN untuk membangun URL proksi terbalik seperti dalam kode berikut:

    var fqdn = Environment.GetEnvironmentVariable("Fabric_NodeIPOrFQDN");
    var serviceUrl = $"http://{fqdn}:19081/DockerSFApp/UserApiContainer";

Untuk kluster lokal, Fabric_NodeIPOrFQDN diatur ke "localhost" secara default. Mulai kluster lokal dengan parameter -UseMachineName untuk memastikan kontainer dapat mencapai proksi terbalik yang berjalan pada node. Untuk informasi selengkapnya, lihat Mengonfigurasi lingkungan pengembang Anda untuk men-debug kontainer.

Layanan Service Fabric yang berjalan dalam kontainer Docker Compose memerlukan bagian docker-compose.yml Ports khusus http: atau konfigurasi https:. Untuk informasi selengkapnya, lihat Dukungan penyebaran Docker Compose di Azure Service Fabric.

Langkah berikutnya