Apa yang dimaksud dengan Pub/Sub dan Pub/Sub Lite?

description: Memahami cara kerja Pub/Sub dan Pub/Sub Lite serta berbagai istilah yang terkait dengan keduanya

Halaman ini membantu Anda memahami Pub/Sub, alasan bisnis memerlukan Pub/Sub, dan keunggulan Pub/Sub dibandingkan dengan teknologi serupa. Selain itu, pelajari konsep inti Pub/Sub yang mencakup istilah topik, penayang, dan pelanggan.

Pub/Sub adalah layanan pesan asinkron dan skalabel yang memisahkan layanan yang menghasilkan pesan dari layanan yang memproses pesan tersebut.

Pub/Sub memungkinkan layanan berkomunikasi secara asinkron, dengan latensi dalam urutan 100 milidetik.

Pub/Sub digunakan untuk analisis streaming dan pipeline integrasi data guna menyerap dan mendistribusikan data. Pub/Sub sama efektifnya sebagai middleware berorientasi pesan untuk integrasi layanan atau sebagai antrean untuk memparalelkan tugas.

Pub/Sub memungkinkan Anda membuat sistem produsen dan konsumen peristiwa, yang disebut penayang dan pelanggan. Penayang berkomunikasi dengan pelanggan secara asinkron dengan menyiarkan peristiwa, bukan dengan remote procedure call (RPC) sinkron.

Penayang mengirimkan peristiwa ke layanan Pub/Sub, tanpa memperhatikan bagaimana atau kapan peristiwa ini akan diproses. Pub/Sub kemudian mengirimkan peristiwa ke semua layanan yang bereaksi terhadap peristiwa tersebut. Dalam sistem yang berkomunikasi melalui RPC, penayang harus menunggu pelanggan menerima data. Namun, integrasi asinkron di Pub/Sub meningkatkan fleksibilitas dan keandalan sistem secara keseluruhan.

Untuk mulai menggunakan Pub/Sub, lihat Panduan memulai menggunakan Google Cloud konsol. Untuk pengantar yang lebih komprehensif, lihat Membangun sistem pesan Pub/Sub.

Kasus penggunaan umum

  • Penyerapan interaksi pengguna dan peristiwa server. Untuk menggunakan peristiwa interaksi pengguna dari aplikasi pengguna akhir atau peristiwa server dari sistem Anda, Anda dapat meneruskannya ke Pub/Sub. Kemudian, Anda dapat menggunakan alat pemrosesan streaming, seperti Dataflow, yang mengirimkan peristiwa ke database. Contoh database tersebut adalah BigQuery, Bigtable, dan Cloud Storage. Pub/Sub memungkinkan Anda mengumpulkan peristiwa dari banyak klien secara bersamaan.

  • Distribusi peristiwa real-time. Peristiwa, baik mentah maupun yang diproses, dapat disediakan untuk beberapa aplikasi di seluruh tim dan organisasi Anda untuk pemrosesan real-time. Pub/Sub mendukung "bus peristiwa perusahaan" dan pola desain aplikasi berbasis peristiwa. Pub/Sub memungkinkan Anda berintegrasi dengan banyak sistem Google yang mengekspor peristiwa ke Pub/Sub.

  • Mereplikasi data antar-database. Pub/Sub umum digunakan untuk mendistribusikan peristiwa perubahan dari database. Peristiwa ini dapat digunakan untuk membuat tampilan status database dan histori status di BigQuery dan sistem penyimpanan data lainnya.

  • Pemrosesan dan alur kerja paralel. Anda dapat mendistribusikan banyak tugas secara efisien di antara beberapa pekerja dengan menggunakan pesan Pub/Sub untuk terhubung ke Cloud Run functions. Contoh tugas tersebut adalah mengompresi file teks, mengirim notifikasi email, mengevaluasi model AI, dan memformat ulang gambar.

  • Bus peristiwa perusahaan. Anda dapat membuat bus berbagi data real-time di seluruh perusahaan, mendistribusikan peristiwa bisnis, update database, dan peristiwa analisis di seluruh organisasi Anda.

  • Streaming data dari aplikasi, layanan, atau perangkat IoT. Misalnya, aplikasi SaaS dapat memublikasikan feed peristiwa real-time. Atau, sensor perumahan dapat melakukan streaming data ke Pub/Sub untuk digunakan di produk lain Google Cloud melalui pipeline Dataflow.

  • Memuat ulang cache terdistribusi. Misalnya, aplikasi dapat memublikasikan peristiwa pembatalan untuk memperbarui ID objek yang telah berubah.

  • Load balancing untuk keandalan. Misalnya, instance layanan dapat di-deploy di Compute Engine di beberapa zona, tetapi berlangganan ke topik umum. Jika layanan gagal di zona mana pun, layanan lainnya dapat mengambil beban secara otomatis.

Jenis layanan Pub/Sub

Pub/Sub terdiri dari dua layanan:

  • Layanan Pub/Sub. Layanan pesan ini adalah pilihan default untuk sebagian besar pengguna dan aplikasi. Layanan ini menawarkan keandalan tertinggi dan kumpulan integrasi terbesar, serta pengelolaan kapasitas otomatis. Pub/Sub menjamin replikasi sinkron semua data ke setidaknya dua zona dan replikasi upaya terbaik ke zona tambahan ketiga.

  • Layanan Pub/Sub Lite. Layanan pesan terpisah tetapi serupa yang dibuat dengan biaya lebih rendah. Layanan ini menawarkan keandalan yang lebih rendah dibandingkan dengan Pub/Sub. Layanan ini menawarkan penyimpanan topik zonal atau regional. Topik Lite zonal hanya disimpan di satu zona. Topik Lite regional mereplikasi data ke zona kedua secara asinkron. Selain itu, Pub/Sub Lite mengharuskan Anda untuk melakukan pra-penyediaan dan mengelola kapasitas penyimpanan dan throughput. Pertimbangkan Pub/Sub Lite hanya untuk aplikasi yang mencapai biaya rendah yang membenarkan beberapa pekerjaan operasional tambahan dan keandalan yang lebih rendah.

Untuk mengetahui detail selengkapnya tentang perbedaan antara Pub/Sub dan Pub/Sub Lite, lihat Memilih Pub/Sub atau Pub/Sub Lite.

Membandingkan Pub/Sub dengan teknologi pesan lainnya

Pub/Sub menggabungkan skalabilitas horizontal dari Apache Kafka dan Pulsar dengan fitur yang ditemukan di middleware pesan tradisional seperti Apache ActiveMQ dan RabbitMQ. Contoh fitur tersebut adalah antrean pesan yang tidak terkirim dan pemfilteran.

Fitur lain yang diadopsi Pub/Sub dari middleware pesan adalah paralelisme per pesan, bukan pesan berbasis partisi. Pub/Sub "menyewakan" pesan individual ke klien pelanggan, lalu melacak apakah pesan tertentu berhasil diproses.

Sebaliknya, sistem pesan yang dapat diskalakan secara horizontal lainnya menggunakan partisi untuk penskalaan horizontal. Hal ini memaksa pelanggan untuk memproses pesan di setiap partisi secara berurutan dan membatasi jumlah klien serentak ke jumlah partisi. Pemrosesan per pesan memaksimalkan paralelisme aplikasi pelanggan, dan membantu memastikan independensi penayang/pelanggan.

Membandingkan komunikasi layanan ke layanan dan layanan ke klien

Pub/Sub ditujukan untuk komunikasi layanan ke layanan, bukan komunikasi dengan klien pengguna akhir atau IoT. Pola lain didukung dengan lebih baik oleh produk lain:

Anda dapat menggunakan kombinasi layanan ini untuk membangun pola klien -> layanan -> database. Misalnya, lihat tutorial Streaming pesan Pub/Sub melalui WebSockets.

Integrasi

Pub/Sub memiliki banyak integrasi dengan produk lain Google Cloud untuk membuat sistem pesan berfitur lengkap:

  • Pemrosesan streaming dan integrasi data. Didukung oleh Dataflow, termasuk template Dataflow template dan SQL, yang memungkinkan pemrosesan dan integrasi data ke BigQuery dan data lake di Cloud Storage. Template Dataflow untuk memindahkan data dari Pub/Sub ke Cloud Storage, BigQuery, dan produk lainnya tersedia di UI Pub/Sub dan Dataflow di Google Cloud konsol. Integrasi dengan Apache Spark, terutama saat dikelola dengan Managed Service untuk Apache Spark juga tersedia. Komposisi visual pipeline integrasi dan pemrosesan yang berjalan di Spark + Managed Service untuk Apache Spark dapat dilakukan dengan Data Fusion.
  • Pemantauan, Pemberitahuan, dan Logging. Didukung oleh produk Monitoring dan Logging.
  • Autentikasi dan IAM. Pub/Sub mengandalkan autentikasi OAuth standar yang digunakan oleh produk Google Cloud lain dan mendukung IAM terperinci, yang memungkinkan kontrol akses untuk setiap resource.
  • API. Pub/Sub menggunakan teknologi API layanan gRPC dan REST standar beserta library klien untuk beberapa bahasa.
  • Pemicu, notifikasi, dan webhook. Pub/Sub menawarkan pengiriman pesan berbasis push sebagai permintaan POST HTTP ke webhook. Anda dapat menerapkan otomatisasi alur kerja menggunakan Cloud Functions atau produk serverless lainnya.
  • Orkestrasi. Pub/Sub dapat diintegrasikan ke dalam Alur Kerja serverless multi-langkah secara deklaratif. Orkestrasi big data dan analisis sering dilakukan dengan Managed Airflow, yang mendukung pemicu Pub/Sub. Anda juga dapat mengintegrasikan Pub/Sub dengan Application Integration (Pratinjau) yang merupakan solusi Integration-Platform-as-a-Service (iPaaS). Application Integration menyediakan pemicu Pub/Sub untuk memicu atau memulai integrasi.
  • Integration Connectors. (Pratinjau) Konektor ini memungkinkan Anda terhubung ke berbagai sumber data. Dengan konektor, layanan dan aplikasi bisnis pihak ketiga akan diekspos ke integrasi Anda melalui antarmuka standar yang transparan. Google CloudUntuk Pub/Sub, Anda dapat membuat koneksi Pub/Sub untuk digunakan dalam integrasi.

Konsep inti

  • Topik. Resource bernama yang menjadi tujuan pengiriman pesan oleh penayang.
  • Langganan. Resource bernama yang mewakili aliran pesan dari satu topik tertentu, yang akan dikirimkan ke aplikasi yang berlangganan. Untuk mengetahui detail selengkapnya tentang langganan dan semantik pengiriman pesan, lihat the Panduan Pelanggan.
  • Pesan. Kombinasi data dan atribut (opsional) yang dikirim penayang ke topik dan akhirnya dikirimkan ke pelanggan.
  • Atribut pesan. Pasangan nilai kunci yang dapat ditentukan penayang untuk pesan. Misalnya, kunci iana.org/language_tag dan nilai en dapat ditambahkan ke pesan untuk menandainya sebagai dapat dibaca oleh pelanggan yang berbahasa Inggris.
  • Penayang. Aplikasi yang membuat dan mengirim pesan ke satu atau beberapa topik.
  • Pelanggan. Aplikasi dengan langganan ke satu atau beberapa topik untuk menerima pesan darinya.
  • Konfirmasi (atau "ack"). Sinyal yang dikirim oleh pelanggan ke Pub/Sub setelah berhasil menerima pesan. Pesan yang dikonfirmasi akan dihapus dari antrean pesan langganan.
  • Push dan pull. Dua metode pengiriman pesan. Pelanggan menerima pesan dengan Pub/Sub yang mendorong pesan ke endpoint yang dipilih pelanggan, atau dengan pelanggan yang menarik pesan dari layanan.

Hubungan penayang-pelanggan dapat berupa one-to-many (fan-out), many-to-one (fan-in), dan many-to-many, seperti yang ditunjukkan dalam diagram berikut:

Hubungan penayang dengan pelanggan

Diagram berikut mengilustrasikan cara pesan diteruskan dari penayang ke pelanggan. Untuk pengiriman push, konfirmasi bersifat implisit dalam respons terhadap permintaan push, sedangkan untuk pengiriman pull, konfirmasi memerlukan RPC terpisah.

Siklus proses pesan

Langkah berikutnya