Menghubungkan dan berkomunikasi dengan layanan di Service Fabric

Dalam Service Fabric, layanan dijalankan di suatu tempat di kluster Service Fabric, biasanya didistribusikan di beberapa VM. Ini dapat dipindahkan dari satu tempat ke tempat lain, baik oleh pemilik layanan, atau secara otomatis oleh Service Fabric. Layanan tidak dikaitkan secara statis dengan komputer atau alamat tertentu.

Aplikasi Service Fabric umumnya terdiri dari berbagai layanan, tempat setiap layanan melakukan tugas khusus. Layanan ini dapat berkomunikasi satu sama lain untuk membentuk fungsi lengkap, seperti mengubah bagian aplikasi web lainnya. Ada juga aplikasi klien yang terhubung dan berkomunikasi dengan layanan. Dokumen ini membahas cara menyiapkan komunikasi dengan dan antara layanan Anda di Service Fabric.

Periksa halaman ini untuk video pelatihan yang juga membahas komunikasi layanan:

Menggunakan protokol Anda sendiri

Service Fabric memudahkan pengelolaan siklus hidup layanan, tetapi tidak membuat keputusan tentang apa yang dilakukan layanan Anda. Ini termasuk komunikasi. Jika layanan Anda dibuka oleh Service Fabric, inilah kesempatan layanan Anda untuk menyiapkan titik akhir untuk permintaan masuk, menggunakan tumpukan protokol atau komunikasi apa pun yang Anda inginkan. Layanan Anda akan mendengarkan alamat IP:port normal menggunakan skema pemberian alamat apa pun, seperti URI. Beberapa replika atau instans layanan dapat berbagi proses host, di mana instans atau replika tersebut harus menggunakan port yang berbeda atau menggunakan mekanisme berbagi port, seperti driver kernel http.sys di Windows. Dalam kedua kasus, tiap instans layanan atau replika dalam proses host harus dapat diatasi secara unik.

Penemuan dan resolusi layanan

Dalam sistem terdistribusi, layanan dapat berpindah dari satu komputer ke komputer lain dari waktu ke waktu. Hal ini dapat terjadi karena berbagai alasan, termasuk penyeimbangan sumber daya, peningkatan versi, failover, perluasan skala. Hal ini berarti bahwa titik akhir layanan menangani perubahan saat layanan dipindahkan ke simpul dengan alamat IP yang berbeda, dan dapat dibuka di port yang berbeda jika layanan tersebut menggunakan port yang dipilih secara dinamis.

Service Fabric menyediakan layanan penemuan dan resolusi yang disebut Layanan Penamaan. Layanan Penamaan mempertahankan tabel yang memetakan instans layanan bernama ke alamat titik akhir yang didengarkan. Semua contoh layanan bernama dalam Kain Layanan memiliki nama unik yang dinyatakan sebagai URI, misalnya, "fabric:/MyApplication/MyService". Nama layanan tidak berubah selama masa pakai layanan, yang dapat berubah hanya alamat titik akhir saat layanan dipindahkan. Hal ini sejalan dengan situs web yang memiliki URL kontan, tetapi alamat IP dapat berubah. Selain itu, seperti halnya DNS di web, yang mengatasi URL situs web ke alamat IP, Service Fabric memiliki registrar yang memetakan nama layanan ke alamat titik akhirnya.

Mengatasi dan menyambungkan ke layanan melibatkan langkah-langkah berikut yang dijalankan dalam satu putaran:

• Atasi: Mendapatkan titik akhir yang telah diterbitkan layanan dari Layanan Penamaan.
• Sambungkan: Menyambungkan ke layanan melalui protokol apa pun yang digunakannya pada titik akhir tersebut.
• Coba lagi: Upaya koneksi mungkin gagal karena sejumlah alasan, misalnya jika layanan telah dipindahkan sejak terakhir kali alamat titik akhir diselesaikan. Dalam hal ini, langkah-langkah penyelesaian dan penyambungan sebelumnya perlu dicoba lagi, dan siklus ini diulang hingga koneksi berhasil.

Menyambungkan ke layanan lain

Layanan yang terhubung satu sama lain dalam kluster umumnya dapat langsung mengakses titik akhir layanan lain karena simpul dalam kluster berada di jaringan lokal yang sama. Untuk mempermudah terhubung antar layanan, Service Fabric menyediakan layanan tambahan yang menggunakan Layanan Penamaan. Layanan DNS dan layanan proksi terbalik.

Layanan DNS

Karena banyak langganan, terutama layanan yang dikemas, dapat memiliki nama URL yang sudah ada, layanan ini dapat diatasi dengan mudah menggunakan protokol DNS standar (bukan protokol Layanan Penamaan), terutama dalam skenario "angkat dan geser" aplikasi. Inilah yang sebenarnya dilakukan oleh layanan DNS. Layanan ini memungkinkan Anda memetakan nama DNS ke nama layanan, sehingga menyelesaikan alamat IP titik akhir.

Seperti yang diperlihatkan dalam diagram berikut, layanan DNS, yang dijalankan dalam kluster Service Fabric, memetakan nama DNS ke nama layanan yang kemudian diselesaikan oleh Layanan Penamaan untuk menampilkan alamat titik akhir yang akan disambungkan. Nama DNS untuk layanan disediakan pada saat pembuatan.

Untuk detail selengkapnya tentang cara menggunakan layanan DNS, lihat artikel layanan DNS di Azure Service Fabric.

Layanan proksi terbalik

Proksi terbalik menangani layanan dalam kluster yang mengekspos titik akhir HTTP (termasuk HTTPS). Proksi terbalik sangat memudahkan panggilan layanan lain dan metodenya dengan memiliki format URI tertentu dan menangani langkah penyelesaian, penyambungan, coba lagi yang diperlukan untuk satu layanan untuk berkomunikasi dengan layanan lain menggunakan Layanan Penamaan. Dengan kata lain, layanan ini menyembunyikan Layanan Penamaan dari Anda saat memanggil layanan lain dengan membuatnya semudah memanggil URL.

Untuk detail selengkapnya tentang cara menggunakan layanan proxy terbalik, lihat artikel Proksi terbalik di Azure Service Fabric.

Koneksi dari klien eksternal

Layanan yang terhubung satu sama lain dalam kluster umumnya dapat langsung mengakses titik akhir layanan lain karena simpul dalam kluster berada di jaringan lokal yang sama. Namun, di beberapa lingkungan, kluster mungkin berada di belakang load balancer yang merutekan lalu lintas masuk melalui rangkaian proksi terbatas. Dalam kasus ini, layanan masih dapat berkomunikasi satu sama lain dan mengatasi alamat menggunakan Layanan Penamaan, tetapi langkah tambahan harus diambil agar klien eksternal dapat terhubung ke layanan.

Service Fabric di Azure

Kluster Service Fabric di Azure ditempatkan di belakang Azure Load Balancer. Semua lalu lintas eksternal ke kluster harus melewati load balancer. Load balancer akan secara otomatis meneruskan lalu lintas masuk di port yang ditentukan ke simpul acak yang memiliki port terbuka yang sama. Azure Load Balancer hanya tahu tentang port yang terbuka simpul, tetapi tidak tahu tentang port yang dibuka oleh layanan individual.

Misalnya, untuk menerima lalu lintas eksternal di port 80, hal-hal berikut harus dikonfigurasi:

1. Tulis layanan yang mendengarkan di port 80. Konfigurasikan port 80 dalam ServiceManifest.xml layanan dan buka listener dalam layanan, misalnya, server web yang dihosting sendiri.

   <Resources>
       <Endpoints>
           <Endpoint Name="WebEndpoint" Protocol="http" Port="80" />
       </Endpoints>
   </Resources>
   

       class HttpCommunicationListener : ICommunicationListener
       {
           ...
   
           public Task<string> OpenAsync(CancellationToken cancellationToken)
           {
               EndpointResourceDescription endpoint =
                   serviceContext.CodePackageActivationContext.GetEndpoint("WebEndpoint");
   
               string uriPrefix = $"{endpoint.Protocol}://+:{endpoint.Port}/myapp/";
   
               this.httpListener = new HttpListener();
               this.httpListener.Prefixes.Add(uriPrefix);
               this.httpListener.Start();
   
               string publishUri = uriPrefix.Replace("+", FabricRuntime.GetNodeContext().IPAddressOrFQDN);
               return Task.FromResult(publishUri);
           }
   
           ...
       }
   
       class WebService : StatelessService
       {
           ...
   
           protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
           {
               return new[] { new ServiceInstanceListener(context => new HttpCommunicationListener(context))};
           }
   
           ...
       }
   

       class HttpCommunicationlistener implements CommunicationListener {
           ...
   
           @Override
           public CompletableFuture<String> openAsync(CancellationToken arg0) {
               EndpointResourceDescription endpoint =
                   this.serviceContext.getCodePackageActivationContext().getEndpoint("WebEndpoint");
               try {
                   HttpServer server = com.sun.net.httpserver.HttpServer.create(new InetSocketAddress(endpoint.getPort()), 0);
                   server.start();
   
                   String publishUri = String.format("http://%s:%d/",
                       this.serviceContext.getNodeContext().getIpAddressOrFQDN(), endpoint.getPort());
                   return CompletableFuture.completedFuture(publishUri);
               } catch (IOException e) {
                   throw new RuntimeException(e);
               }
           }
   
           ...
       }
   
       class WebService extends StatelessService {
           ...
   
           @Override
           protected List<ServiceInstanceListener> createServiceInstanceListeners() {
               <ServiceInstanceListener> listeners = new ArrayList<ServiceInstanceListener>();
               listeners.add(new ServiceInstanceListener((context) -> new HttpCommunicationlistener(context)));
               return listeners;		
           }
   
           ...
       }
   

2. Buat Kluster Service Fabric di Azure dan tentukan port 80 sebagai port titik akhir kustom untuk jenis simpul yang akan menghosting layanan. Jika Anda memiliki lebih dari satu jenis simpul, Anda dapat menyiapkan batasan penempatan pada layanan untuk memastikannya hanya berjalan pada jenis simpul yang memiliki port titik akhir kustom yang terbuka.

   

3. Setelah kluster dibuat, konfigurasikan Azure Load Balancer di Grup Sumber Daya kluster untuk meneruskan lalu lintas pada port 80. Saat membuat kluster melalui portal Microsoft Azure, ini disiapkan secara otomatis untuk setiap port titik akhir kustom yang dikonfigurasi.

   

4. Azure Load Balancer menggunakan pemeriksaan untuk menentukan apakah akan mengirim lalu lintas ke simpul tertentu atau tidak. Pemeriksaan memeriksa titik akhir secara berkala pada setiap simpul untuk menentukan apakah simpul merespons atau tidak. Jika pemeriksaan gagal menerima respons setelah beberapa kali dikonfigurasi, load balancer akan berhenti mengirim lalu lintas ke simpul tersebut. Saat membuat kluster melalui portal Microsoft Azure, pemeriksaan disiapkan secara otomatis untuk setiap port titik akhir kustom yang dikonfigurasi.

   

Perlu diingat bahwa Azure Load Balancer dan pemeriksaan hanya tahu tentang simpul, bukan layanan yang berjalan pada simpul tersebut. Azure Load Balancer akan selalu mengirim lalu lintas ke simpul yang merespons pemeriksaan, jadi perawatan harus dilakukan untuk memastikan layanan tersedia pada simpul yang dapat merespons pemeriksaan.

Reliable Services: Opsi API komunikasi bawaan

Kerangka kerja Reliable Services dikirim dengan beberapa opsi komunikasi bawaan. Keputusan tentang opsi yang paling cocok untuk Anda bergantung pada pilihan model pemrograman, kerangka komunikasi, dan bahasa pemrograman tempat layanan Anda ditulis.

• Tidak ada protokol khusus: Jika Anda belum memiliki pilihan kerangka kerja komunikasi tertentu, tetapi Anda menginginkan peningkatan dan eksekusi yang cepat, opsi yang ideal bagi Anda adalah layanan jarak jauh, yang memungkinkan panggilan prosedur jarak jauh yang kuat untuk Reliable Services dan Reliable Actors. Ini adalah cara yang paling cepat dan mudah untuk mulai menggunakan komunikasi layanan. Remoting layanan mengatasi penanganan alamat layanan, koneksi, operasi coba lagi, dan penanganan kesalahan. Ini tersedia untuk aplikasi C# dan Java.
• HTTP: Untuk komunikasi agnostik bahasa, HTTP menyediakan pilihan standar industri dengan alat dan server HTTP yang tersedia dalam berbagai bahasa, semua didukung oleh Service Fabric. Layanan dapat menggunakan tumpukan HTTP yang tersedia, termasuk ASP.NET Web API untuk aplikasi C#. Klien yang ditulis dalam C# dapat memanfaatkan kelas ICommunicationClient dan ServicePartitionClient, sedangkan untuk Java, gunakan kelas CommunicationClient dan FabricServicePartitionClient, untuk resolusi layanan, koneksi HTTP, dan perulangan coba lagi.
• WCF: Jika Anda memiliki kode yang ada yang menggunakan WCF sebagai kerangka komunikasi, Anda dapat menggunakan WcfCommunicationListener untuk sisi server serta kelas WcfCommunicationClient dan ServicePartitionClient untuk klien. Namun, ini hanya tersedia untuk aplikasi C# pada kluster berbasis Windows. Untuk detail selengkapnya, lihat artikel ini tentang implementasi tumpukan komunikasi berbasis WCF.

Menggunakan protokol kustom dan kerangka komunikasi lainnya

Layanan dapat menggunakan protokol atau kerangka apa pun untuk komunikasi, baik itu protokol biner kustom melalui soket TCP, atau streaming peristiwa melalui Azure Event Hubs atau Azure IoT Hub. Service Fabric menyediakan API komunikasi tempat Anda dapat mencolokkan tumpukan komunikasi Anda, sementara semua pekerjaan untuk penemuan dan penyambungan dipisahkan dar Anda. Lihat artikel ini tentang Model komunikasi Reliable Services untuk mengetahui detail selengkapnya.

Langkah berikutnya

Pelajar lebih lanjut konsep dan API yang tersedia dalam model komunikasi Reliable Services, lalu mulai remoting layanan dengan cepat atau pelajari lebih dalam cara menulis listener komunikasi menggunakan Web API dengan host mandiri OWIN.